Gitter is joining Matrix | Hacker News Reader

Gitter is joining Matrix

matrix.org

701 pointsBubuIIC116 comments

From the Matrix side, we're ridiculously happy to have the opportunity to defragment developer chat a bit, and get folks on Gitter natively talking to folks elsewhere on Matrix (including bridged to IRC, Slack, Discord or whatever). The fragmentation of FOSS development chat into proprietary silos a few years back was incredibly depressing, and this is our attempt to put right what once went wrong :) Happy to try to answer any questions from the Matrix side!

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

From the GitLab side we're very happy with the new home for Gitter. Chat is very useful but using multiple incompatible technologies has lead to fragmentation and silos. For example external developers being on Gitter when the organization behind the project is on Slack. Matrix is a great way to solve that and we hope Gitter will contribute to the success of it.

can you comment on the vision that gitlab as a product would have in the future for integration with gitter/matrix?

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.

That sounds like a great use case and we would welcome Matrix support in GitLab. Adding this isn't on our company roadmap so it would have to be a contribution. See https://gitlab.com/gitlab-org/gitlab/-/issues/22996 for a related but not quite the same suggestion.

Oh, right, please get rid of mattermost and replace it with matrix/gitter

One of the best features of Gitter is that it can be embedded on webpages which reduces a lot of friction for public communities. Please keep that feature and perhaps, even replicate it in Matrix. This can be a unique value prop for both over the proprietary ones. Plus, it enriches the Web as opposed to moving all things into app silos.

For sure. Matrix is sprouting this too (there was a GSoC project this summer for it, and the Hydrogen Matrix client is also properly embeddable, unlike Element) - but with Gitter becoming a Matrix client we could do so from that side too!

The Matrix to IRC bridge (for at least freenode and OFTC) has a number of suboptimal behaviours on the IRC side, it would be great if you could improve the experience for folks not using Matrix.

We’re aware of folks objecting that messages longer than 3 lines get autopastebinned, and that replies are a bit jarring on IRC. Or do you have something else in mind?

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.

The reply issue is pretty hard to solve, since sometimes the extra text is useful, sometimes it isn't. Perhaps if there has been N minutes or X lines of chat since the message being replied to, then include the extra text, otherwise don't. The template should be changed to something like this though:

    <foo[m]> bar: re "hello about something longis...", hello!
    <foo[m]> bar: re "short hello", hello!

Those are the main ones, a few more:

Image uploads could probably just post a link to the image instead using /me uploaded an image: foo.png (123KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/....... >

Directing a message at a specific person on the channel sometimes posts their full Matrix URL on the IRC side, rather than just using their IRC nick:

    <foo[m]> [bar](https://matrix.to/#/@bar:matrix.org): hello

Directing a message at a specific person on the channel sometimes posts their full name on the IRC side, rather than using their IRC nick:

    <foo[m]> Bar Baz: hello

Matrix <> IRC splits seem to occur more often than IRC netsplits.

> Directing a message at a specific person on the channel sometimes posts their full Matrix URL on the IRC side, rather than just using their IRC nick:

    <foo[m]> [bar](https://matrix.to/#/@bar:matrix.org): hello

This one is a client-side bug, not a bridge bug.

> Directing a message at a specific person on the channel sometimes posts their full name on the IRC side, rather than using their IRC nick:

    <foo[m]> Bar Baz: hello

This should only be a thing when mentioning non-IRC users. Is this actually a problem?

> This one is a client-side bug, not a bridge bug.

Hmm, in IRC clients or Matrix ones? Which clients?

> This should only be a thing when mentioning non-IRC users. Is this actually a problem?

Yes, because it makes it harder to follow the conversation from the IRC side because the full name from the Matrix side isn't available on the IRC side and even if it were present in the IRC "real name" field, it would still be hard to map from real names to IRC nicks, which is why IRC users never address each other using their real names, only their nicks.

Don't know if you have access to the Gitter side but as of now, the blog post is 404ing https://blog.gitter.im/gitter-element-acquisition/

The correct URL is https://blog.gitter.im/2020/09/30/gitter-element-acquisition...

oops, Ghost fail; fixed now :)

It is not obvious from the title but Element is actually acquiring Gitter. Quote from the article:

> 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/

Well, the main news is that Gitter is going to natively join Matrix. We've been talking about doing this for a few years, but it never got to the top of the todo list on either side - plus frankly we're breaking new ground by making a large existing network natively speak Matrix (complete with incorporating room archives, etc).

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...

> Well, the main news is that Gitter is going to natively join Matrix.

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.

Meanwhile, I had not heard of Gitter until just this moment. But I have been migrating my presence to Matrix, and the Matrix clients are pretty good, approaching par with Signal, which has been pretty good.

Please, please fix the years-old notification bug where you can't turn off email notifications for every single comment without leaving the channel.

"Only email me when I'm mentioned" actually emails you for every message instead.

If you use the "Announcements" settings, you will see this behavior but is also described in the notification modal as an oddity. This is tracked by https://gitlab.com/gitlab-org/gitter/webapp/-/issues/1205 which is a huge pain in our notifications that I want to address.

If you use the "Mute" notification setting, you will only get emails for messages the mention you which sounds like you're after.

Fantastic, thanks for that! Must be new.

On Gitter? Element gets this right at least, so once we move Gitter over to being entirely Matrix backed it should be ok.

I'm really excited about this too, but I'm afraid it does matter.

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.

I love this move, since I'm trying to move to Matrix as my primary chat where possible. Even more so since some of the mentioned features are sorely needed in Element, like threads.

But Gitlab is a for-profit company.

I don't see this as Gitter laying down arms, but rather as Gitlab not being able to monetize Gitter enough to justify keeping it in the company. They probably sold it for a very reasonable amount.

Right. The point is, if a competitor who was a for-profit company was willing to federate with Element, as a first-party contributor not just reluctantly "I guess you can use our integration API's for that and we won't stop you... yet" -- that would be watershed moment in hopes of federation/integration instead of silos being a thing.

That is indeed not what happened. It's just an acquisition. It does not actually give us hope that there's more momentum towards competitors being willing to play together in federation, that's not what happened.

Not sure why the one who made that point is getting downvoted, I think it's an interesting observation. That the press release arguably kind of intentionally tries to hand wave over a bit.

The Matrix.org blog post isn’t really me trying to wave a hand over it - it’s just that the Element, Gitter and GitLab (https://about.gitlab.com/blog/2020/09/30/gitter-moves-to-ele...) and Changelog stories fixate on it being an acquisition, and I wanted to dwell on the impact for Matrix.

The reality is that bridging a big existing network is a significant undertaking and nobody has done it before (other than possibly Matrix.org and Freenode, but it’s not like Freenode is letting us talk TS6; we come in as clients). So the acquisition is basically a catalyst to break this impasse. We’re hoping that Rocket.Chat, Mattermost, Teams, Slack, Discord will watch what we do and copy it with more confidence to join the network. At least that’s the dream :)

Slack and Discord need their walled gardens to justify their current state, but low-growth things like Mattermost should federate with little to loose.

My most-realistic dream is for Freenode to be Matrix by default with the IRC interface just for clients.

> ...We’re hoping that Rocket.Chat, Mattermost, Teams, Slack, Discord will watch what we do and copy it with more confidence to join the network...

Admittedly, I'm a fan of the matrix protocol and the Element client...but i have friends still living on slackland, etc. If what you're hoping for would really would happen, well that would be so awesome!

Fair!

We are in agreement.

Talk about burying the lead. That wasn’t mentioned in the matrix blog post at all. Only that Gitter would be using matrix natively. Doesn’t matter either way but weird to not mention it.

The lede is that Gitter is going to natively federate with Matrix. The fact Element bought Gitter is there in the matrix blog post:

> 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.

Additional topics discussed in our just-released conversation[1] with GitLab and Element leads:

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?

[1]: https://changelog.com/podcast/414

1. ChatOps is still a feature of GitLab https://docs.gitlab.com/ee/ci/chatops/ and supports multiple chat platforms. GitLab doesn't need to own the chat to make chatops work.

2. GitLab contacted Matrix.

I think 3. and 4. have answers in https://matrix.org/blog/2020/09/30/welcoming-gitter-to-matri...

I believe that grandparent wanted us to listen to the interview (:

I'd be happy with a transcript. Much faster to read than listen.

Is there a transcript?

there is now: https://changelog.com/podcast/414

Nice, thanks.

"ChatOps" almost invariably means Slack. That's why GitLab is divesting in that space.

Look at what happened HipChat, Stride, etc.

If you granted Gitter access to Gitlab, you granted it full read access to everything in your Gitlab account. This is because Gitlab does not yet support restricted access grants [1].

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

Absolutely - at Element we categorically have zero desire to have access to anything in your GL accounts. On the other hand, for the same reason, we’re not going to exploit that :/

But the responsible thing to do here is to _throw all that data away_, and force everyone to explicitly grant gitter access to their account again.

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.

Dissenting opinion: Element UI/Matrix UX is not good. It's as unwieldy/hostile/frustrating as IRC, maybe more.

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.

> Our plan is instead to merge Gitter’s features into Element (or next generations of Element) itself and then - if and only if Element has achieved parity with Gitter based on the above list - we expect to upgrade the deployment on gitter.im to a Gitter-customised version of Element. The inevitable side-effect is that we’ll be adding new features to Element rather than Gitter going forwards.

Wonder what existing Gitter users think about this?

Hopefully they'll be happy that Gitter will sprout all Matrix's funky features like E2EE, VoIP, Widgets, Read receipts, Reactions, a bajillion clients/bots/bridges, the open standard API itself... and as long as Element-branded-as-Gitter looks and performs and smells enough like Gitter, and the community & rooms are still there, all will be well.

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

Using it mostly out of necessity (a project I'm involved in uses it for communication), but I'm mostly enthusiastic about no longer having that annoying Matrixbot - there were always a number of Matrix users, and the implementation was incredibly confusing.

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.)

> That said, I am somewhat sceptical about whether we'll see any reasonable results in a reasonable amount of time

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 :)

I'm rooting for you!

I don't think Gitter development was very active, before or after their acquisition by GitLab. It has been pretty much the same since 2016. It being folded into another tool felt inevitable to me.

I'm hyped for this; RustPython uses gitter as its main communication platform for developers and contributors, and while it's certainly worked quite well for us so far, I was slightly worried the slow pace of development and the deprecation of mobile apps. It seemed (to me, at least, and I don't follow the gitter changelogs or anything - edit: just looked at them now, so yeah, what follows is pretty unfounded. Anyway,) like gitter was sorta becoming a ghost ship, still running along smoothly but not much was happening at the helm -- this also might be because I mainly use the Android app, which is deprecated, so I see very few updates to gitter if any. Anyway, yeah, I think this is a great direction to go for gitter, if only so I'll have an updated mobile app :)

I am ecstatic. The Element Android client is quite good and getting better, and I'd love to be able to access gitter from that.

I'm happy about it.

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.

I'm massively rooting for this. I really wanted to use Gitter as the official chat for my projects, but the experience was just so painful that I ended up fragmenting the community across Discord and a gated Slack. I would love to have a forever home where I can feel comfortable getting everyone on board.

I really like matrix, but there is one important feature missing : threads.

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.

I really like to use IRC on the terminal via Irssi.

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?

Matrix is based on an open documented protocol, which means it welcomes multiple implementations. There are several terminal-based clients, which you can see on their current client list, and I wouldn't be surprised if more appear over time: https://matrix.org/clients/

There are also Matrix-IRC bridges that already exist: https://matrix.org/bridges/#irc

None of the terminal ones seem to be in the Debian repos.

I'm not sure anyone has written an irssi plugin specifically, but there's an excellent weechat plugin (https://github.com/poljar/weechat-matrix). As others have said, there's also matrix-ircd which exposes all of Matrix as an IRC server you can connect to from whatever IRC client floats your boat, but you end up speaking the subset of Matrix which can be represented as IRC, which is a bit of a shame.

> Can Irssi be used to access this matrix thing?

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).

Can you explain the caveat? Federated identity seems to be what matrix already offers. Even if the main instance at matrix.org dominates.

Federated/decentralized identity is on the roadmap and being worked on - while yes, Matrix conversations and discovery are fully decentralized and federated, each account is still tied to a single homeserver through the domain (e.g. user@matrix.org still depends on the matrix.org homeserver to use their identity)

Arguably none of the alternatives have this quality either but I find it worth pointing out as a requirement for next-generation IM.

https://github.com/matrix-org/matrix-doc/blob/neilalexander/... is the latest work on this ftr :)

There's a weechat plugin for matrix that's being actively developed here https://github.com/poljar/weechat-matrix-rs.

> If not, is there some nice matrix command line client in the Debian repos?

There is the gomuks client (https://github.com/tulir/gomuks) for the command line. I'm not sure about the Debian package, though.

There's matrix-ircd which exposes Matrix servers as an IRC server. So, I'm pretty sure what you want already exists.

You could use an IRC Bridge https://github.com/matrix-org/matrix-appservice-irc As for direct access from the command line, I don't know.

Be aware that the bridges between matrix.org and IRC are often unreliable.

this has historically due to the matrix.org (where those bridges live) being thoroughly overloaded. these days (since ~May) we have it under control and it should be pretty robust.

Obligatory https://xkcd.com/1782/

Gitter has a much simpler onboarding experience and users don't have to be signed in or members of a room to view chat. I like the ideals of Element. In fact I have the services bridged between chat rooms. Currently editing chat posts between different clients is less than subpar. Gitter build on Element will fix that issue.

This is awesome. I found Gitter super handy because of it's close tie to repos, but being able to reach it from Element would be really nice.

You already could, before this announcement. For example, want to join https://gitter.im/hashicorp-consul/Lobby ? Then join #gitter_hashicorp-consul=2FLobby:matrix.org from Element.

You can also click little discover icon on Element and search Gitter for channels.

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!

yup, but the experience is pretty dire, particularly on the Gitter side of the bridge. The intention instead is to be able to join #hashicorp-consul_lobby:gitter.im in Matrix, and have all the Gitter users natively there in Matrix... but also all the Matrix users there natively in Gitter :)

So, how long will it take (approximate) to complete the mentioned process ?

Also, I think that matrix ecosystem will grow from this move.

We hope to get Gitter natively speaking Matrix in the coming months. It'll probably be a year or so before Element has feature parity with Gitter though :)

Good luck. We're all counting on you.

Sounds like an optimistic plan.

(Note: I've never used gitter. Registering on another funky and closed chat platform was never a hurdle I managed to jump over. Going for matrix sounds awesome, I have an identity there.)

GitLab hasn't been giving it any attention. All they need is a checkmark in their portfolio.

Yes, shame GitLab didn't integrate Gitter natively into public projects same way issues and roadmaps are integrated.

I recall we considered this at various stages a few years back. I think this was around the same time we introduced our chatops integration.

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.

Ironically Gitter moving to Matrix probably makes this more likely - as integrating Matrix into GitLab would be much more sensible than integrating a single opinionated client like Gitter, given if GitLab properly spoke Matrix for chatops, it'd then be available to anyone in Matrix (Gitter, Element, or any platform bridged into Matrix - Slack, Discord, etc)

element already has some gitlab integrations

Can anyone comment on the state of UX with Element these days? I'm changing to Linux/Windows from Mac, so i'm dumping iMessage - but i'm not convinced Signal has a good enough UX to keep me and my family happy.

Sidenote, i love how i can pay Element and support Matrix/Element.

In my opinion, Signal's UX is better than Element. Element's distinction of rooms / communities is not great, and hindered by the user interface. Although, after checking out Element again, all the other parts of the UI that I thought were unintuitive were changed up, so it's certainly improving.

Particularly for the situation you described - small, family chats - I'd recommend Signal over Element / Matrix.

If you want to support the project and get something from it, a good way is to get yourself a hosted server from Element. The cheapest plan is $10 per month for 5 users, and includes things like a custom domain.

https://element.io/plans-and-pricing/pro

Still not good, confusing and not very fast. Like Keybase four years ago. They have some catching up to do and I hope they do it before Keybase is shut down.

If a Riot contributor is reading this comment, go try Keybase out while you still can, there are things it does well.

Personally speaking, I'm extremely happy with Element.

With good UX, easy encryption, the option to self host if you feel so inclined, I haven't found anything to complain about.

I think it's pretty good! Been using it every day for the past year or so and most of the UX issues I've had before (channel switching, creation and discovery) has been more or less adressed!

The only UX feature I miss is threads to help organize bigger discussions better.

Element is probably harder to use than Signal for less technically inclined users.

There are some other matrix clients, like Pattle, which hide much of the complexity and give a more familiar UX to other messaging apps.

Interesting, I'd never heard of Matrix. And a very timely discovery too... I might find myself integrating this with ShipReq in a few months.

(Disclaimer: ShipReq dev here)

Congratulations to Element ! Gitter is a fantastic platform . Are we possibly going to see Gitter become a reference open source implementation of Matrix ?

This is interesting and unexpected news.

This is great news. I've used Gitter for communication in some open source projects, and have always found certain things painful. My favorite points from the article are;

- 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]

[0] https://xkcd.com/1810/

[1] https://miro.medium.com/max/1400/0*vILzcbWOi7e4RtK0

Wow. It really needed this response to the xkcd comic for the vision of Matrix to click with me. Matrix just went from "just another messenger who happens to have bridges to others" to "possibly the only communication software you’ll ever need" in my mind.

Although I was well aware of Matrix for years, that particular intention behind it somehow never got through to me.

Funny that with all the circles, Discord isn't there.

Or Gitter.

Way cool! Anecdotally, of course, but a sizeable number of Matrix rooms I was in were actually bridged Gitter rooms. Looking forward to tighter integration!

I am happy and thankful to the developers that open source chat is joining forces. It’s the right thing todo!

Nice! This just inspired me to setup my own Matrix server (had been using Matrix for a couple of weeks).

I've found trying to get help from any project that uses Gitter to be a huge pain. It seems that people hardly ever check messages on there. I hope this helps the situation from a UX perspective. Maybe can provide better notification management options?

Oooh. How nice.

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!

I really hope that Gitter chat histories will be still kept search-engine indexed the way they are right now.

they will.

I thought Gitter had already been acquired by GitLab?

GitLab team member here.

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 problem with Matrix is their focus on Electron-based client. Official native client would have been better .

I don't mean to sound stuffy when i say that the beauty of open source is that you are free to build a better alternative...but it is true. Either you can build a better thing that you want, or you can pay someone to do so, etc. That being said, there are existing native clients already. May i direct your attention to: https://www.matrix.org/clients/

I am aware of native clients. Due to being unofficial they often get abandoned and two years ago the list looked differently. What I am talking about is that something simple as chat application should not take gigabyte of memory and incorporate a whole web-browser underneath.

I'm running an electron-based note taking app right now, and it's taking less than 100MB of memory.

Interesting. Is there already a Gitter->Matrix bridge, and that would essentially be going away once Gitter fully supports Matrix? It seems like they're not changing Gitter to talk Matrix, but actually switching the backend to be Matrix? Is that right?

The short term plan is to replace the existing (rather rubbish) Gitter<->Matrix bridge with a fully featured bridge that seamlessly bridges between Gitter and Matrix.

The long term plan folding gitter.im features into Element and Gitter users will migrate to using Element and Matrix.

Reply on news.ycombinator.com