Can Irssi be used to access this matrix thing?
If not, is there some nice matrix command line client in the Debian repos?
Or maybe someone could just make an IRC server which is a bridge to matrix?
There are also Matrix-IRC bridges that already exist: https://matrix.org/bridges/#irc
Yup. I haven't tried it myself and I think there are different ways to set that up but this could be a start (I think this is more targeted towards bridging matrix and IRC, which may or may not be what you want): https://matrix.org/bridges/#irc
> If not, is there some nice matrix command line client in the Debian repos?
Not sure what's in the mainline debian repos but there are some decent CLI clients, yes: https://matrix.org/clients/
If you're OK with weechat you can use that already :)
IMO matrix is already mature to be an IRC killer (caveat federated/decentralized identities, if that's something you require but arguably IRC doesn't have that either).
There is the gomuks client (https://github.com/tulir/gomuks) for the command line. I'm not sure about the Debian package, though.
Also, https://techcrunch.com/2020/09/30/element-acquires-gitter-to... is a pretty massive deep-dive into the migration, and The Changelog did a big podcast covering off all the details on both the GitLab/Gitter and Element/Matrix side: https://changelog.com/podcast/414
We're running a decent sized gitlab+mattermost instance now, we're using mattermost guests to pull in collaborators from upstream. It would be overall a lot easier if we were using something like matrix where it's federated and we can bring people in to our homeserver without having to make accounts for them.
Impedance mismatches are inevitable, but we obviously don’t want Matrix to crap over native experiences on IRC or elsewhere. So: give us specifics and we’ll fix as best we can.
Wonder what existing Gitter users think about this?
And if they don't like it, they can always go spin up their own Gitter instance and maintain it, bridged into Matrix - it's FOSS after all :D
It's a nice bonus that I'll no longer be dependent on Gitter's somewhat buggy Web UI.
(That said, I am somewhat sceptical about whether we'll see any reasonable results in a reasonable amount of time - GitLab promised Gitter rooms for GitLab projects as well when they acquired it, and I'm not even sure if that ever saw the light of day.)
As Element we are if nothing else highly financially motivated to get Gitter bridged into Matrix, so we can run it via our normal Matrix server backend farm rather than keep an entirely parallel deployment running of Gitter infrastructure. We also want to stick to our word :)
For me, one shortcoming of gitter is that it has always been tertiary in my pool of chat services. The more tertiary services are accessible through matrix the better, that way I'm less likely to miss notifications.
I don't think there are big downsides, I can't think of anything in the core gitter chat that I would miss when switching to matrix.
> In practice, the way this is happening is that Element (the company founded by the Matrix core team to fund Matrix development) is acquiring Gitter from GitLab, with a combined Gitter and Element dev team focusing on giving Gitter a new life in Matrix!
There is also another blogpost from the elements side https://element.io/blog/gitter-is-joining-element/
Others (e.g. Rocket.Chat) have had a go at natively speaking Matrix but it's hard to be the first to do so unless both sides of the bridge are prioritising it and focusing on making it a success - and an obvious way of getting aligned is if you are on the same team. So when the opportunity came up for Gitter to move from GitLab to Element, it was a no-brainer way to ensure a successful native bridge for Gitter into Matrix. But we'd probably have got around to it anyway... it'd just have had a lower chance of success.
As another datapoint: Gitter was already looking (independently) at using Element to replace their native mobile apps, which otherwise they were having to deprecate (https://gitlab.com/gitlab-org/gitter/webapp/-/issues/2281).
Edit: another relevant link: https://blog.gitter.im/2020/09/30/gitter-element-acquisition...
Depends on your point of view. I'd not heard of Matrix before, and don't really care.
To me, it's more interesting that GitLab is selling off Gitter.
"Only email me when I'm mentioned" actually emails you for every message instead.
Gitter of it's own accord federating with matrix would be a watershed moment of a competitor laying down it's arms for the greater good, a détente in capitalism, and a really good sign for the future of all things Federated.
Element acquiring Gitter is normal M&A, normal business. It's still good for Matrix and good for Gitter users, and we're still cheering you on, but it's not quite that same watershed moment.
> In practice, the way this is happening is that Element (the company founded by the Matrix core team to fund Matrix development) is acquiring Gitter from GitLab.
Sidenote, i love how i can pay Element and support Matrix/Element.
Particularly for the situation you described - small, family chats - I'd recommend Signal over Element / Matrix.
If a Riot contributor is reading this comment, go try Keybase out while you still can, there are things it does well.
With good UX, easy encryption, the option to self host if you feel so inclined, I haven't found anything to complain about.
The only UX feature I miss is threads to help organize bigger discussions better.
There are some other matrix clients, like Pattle, which hide much of the complexity and give a more familiar UX to other messaging apps.
1. What happened to "ChatOps" and why is GitLab divesting in this space?
2. Who contacted whom? What are some details of the acquisition process and negotiations?
3. What does this mean at a practical sense for existing Gitter users?
4. What's going to happen in the next 6, 12, and 18 months?
2. GitLab contacted Matrix.
I think 3. and 4. have answers in https://matrix.org/blog/2020/09/30/welcoming-gitter-to-matri...
Look at what happened HipChat, Stride, etc.
That being said the bridge is very flaky. Sometimes my messages would not get delivered and attachment such as schreenshots never work either. For the most part it's quite functional though!
Also, I think that matrix ecosystem will grow from this move.
Soon https://element.io will have that full access. Now is a good time to check your Gitlab access grants: https://gitlab.com/profile/applications
[1] "Support restricting OAuth tokens to specific projects and groups " https://gitlab.com/gitlab-org/gitlab/-/issues/22115
With only as many rights as necessary, of course. No app needs full account access, all the time. Make the various parts differently authenticated layers.
I don't know the exact details and can't speak for others, but I suspect GitLab realised that chat(ops) tools are hard to sell and our time is better spent elsewhere. It's a shame though, having Gitter/chat directly integrated in a project (properly, not using e.g. an iframe) would've been pretty cool.
- Improving iOS and Android apps. At least in the iOS case, the experience is abysmal (the web interface is similarly so)
- Replacement of the matrix-appservice-gitter bridge. I've used the Matrix <-> Gitter bridge for some time now but there's much left to be desired, such as proper edit and deletion of messages to and from the services.
Overall, it's great to see less future fragmentation in the chat systems developers use, reminds me of the XKCD comic[0] and a modification showing the matrix.org bridges[1]
Although I was well aware of Matrix for years, that particular intention behind it somehow never got through to me.
Or Gitter.
That is correct - in 2017 https://about.gitlab.com/blog/2017/03/15/gitter-acquisition/. But as announced today, Gitter will be going to Matrix going forward.
The long term plan folding gitter.im features into Element and Gitter users will migrate to using Element and Matrix.
Gitter, on the other hand, is fairly straightforward. The biggest issues with it are that they chose to go with the "has a GitLab/GitHub/Twitter account and must use it to sign in" antipattern as the barrier to entry, and that the web client's layout at half-width 1080p is unfathomably bad. Like, clearly-no-one-has-ever-tested-their-responsive-layout-rules bad.
Once threads will be implemented, I am sure matrix will grow a lot more, especially inside enterprises.
I hope the merge will help with that. Best of luck both teams.
(Disclaimer: ShipReq dev here)
Just a few days ago I considered setting up a Gitter-bridge for my Marrix-instance, but decided that it was both too involved and not well-enough integrated to be worth it.
This is really good news!
