Gitter now speaks Matrix

https://matrix.org/blog/2020/12/07/gitter-now-speaks-matrix

by Arathorn • 6 years ago

443 114 6 years ago

matrix.org

tomelliott• 6 years ago

This is really exciting! Congrats Arathorn and the rest of the Matrix team

Arathorn19• 6 years ago

aww, thanks tom! :D

the_duke3• 6 years ago

That was impressively quick.

Looking forward to Github/Gitlab repository rooms and activity integration.

In the acquisition announcement they also mentioned threading though, which is the most important feature Element is missing for me.

Without it I'm very hesitant to use it in a professional setting.

I do hope that threads will look much more like Zulip rather than Slack (which is a mess), or offer different view modes. Zulips nested channel concept is a game changer.

(as I understand it, the protocol already has the required plumbing)

ducktective• 6 years ago

Can you explain a bit more on "threading" and its relation to a chat service? And why Zulip's implementation is better?

toyg2• 6 years ago

He’s talking of threads as in “email threads”, not “process threads” - i.e. indentation and grouping of messages and replies.

SulfurHexaFluri5• 6 years ago

Its when IM has a reply feature so you can "reply" to a message sent a little while ago and it quotes the message on the top of yours and usually you can click the message to scroll up to it.

Essential for group chats and still useful for DMs.

benatkin2• 6 years ago

A lot of people, including me, dislike threading in Slack. It breaks the algorithm for reading new messages. I use it when teammates do, and acknowledge it's useful sometimes, but I would prefer not to have that feature.

Discord also does not have threads. I've heard some complaints about it, but not many.

Threads in Zulip seem to change it into a different kind of app. I don't see how the Slack workspaces that I've used heavily would work with it. There are about 15 channels in my sidebar. Making them nested would turn it into 75, assuming 5 threads per channel. Perhaps there wouldn't need to be as many top-level channels with Zulip threads, but it makes it into a whole different paradigm. They are also missing Slack-style threads. I don't think it would be good to adopt it.

Xylakant• 6 years ago

Zulip threads (topics) are fundamentally different from slack threads.

TL;DR Slack threads are an after-thought add-on, Zulips topics are a first-class citizen.

Slacks threads can branch of at any point from any message in a channel - if you miss the start of the thread message, it disappears unless someone cross-posts to the channel or mentions you. This is by far the biggest problem I have with slack threads.

Zulip organizes into streams and topics, streams being roughly equivalent to channels and topics similar to threads. However, unlike slack, every message must live in a topic. Topics that have seen a message lately bubble to the top, topics that don't see activity fall to the bottom. You can still see the full stream in chronological order, but messages are grouped by and visibly marked with the topic they belong to. This makes it much easier to both follow a stream and still mentally follow multiple conversations in the same stream.

tiagod• 6 years ago

I think threads, used sparingly, are nice. They're good to have semi-private messages, so you can keep the more irrelevant conversation that would normally go to PM public and searchable, while not spamming the channel. They're also good for support channels, to have a thread per support message.

eXpl0it3r• 6 years ago

I like threads a lot in the way we use it. With 60+ people in one channel, being able to ask a question and get answers in the thread, while not spamming the channel with replies and potentially interweaving multiple question & answer "threads" is really useful.

yawgmoth• 6 years ago

Discord has a feature (recently added?) in which you can reply to something -- it gets miniquoted above your reply. It does a good job of 'flattening out the tree'.

cpuguy83• 6 years ago

Threading is the one thing I actually kinda like in Teams.

the_duke3• 6 years ago

I don't see how the Slack workspaces that I've used heavily would work with it.

Quite simply: you don't know what you are missing.

I was sceptical at first as well, but having the ability to branch off into separate sub-topics while still maintaining easy visibility is extremely nice for organizing conversations and catching up on things you missed in busy channels.

The nice thing is: you can just use flat channels where appropriate, or just ignore the nested topics and read a channel as a regular continuous stream.

It's incredibly conducive to long-form discussions and organizing information, while still retaining the casualness of a chat when required.

Arathorn19• 6 years ago

Matrix now has two flavours of threading defined and implemented as we experiment with the different approaches: label-based threading in MSC2326[1] (i.e. "filter this room to only show msgs tagged #foo"), and full-blown free-form HN/Reddit/NNTP/SMTP/Twitter style threading in MSC2836[2]. The former is closer to Zulip, and is implemented in Synapse. The latter is closer to HN, and is implemented in Dendrite[3][4].

Clientwise, Element supports neither so far, but we're experimenting with the HN-style threading in a dedicated playground called Cerulean[5]. The idea is to get it working well there, and then figure out how to merge it most effectively into Element. So: it's not ready yet, but it's getting tantalisingly close. We'll probably start hosting a demo version of Cerulean next week so folks can play along and see how it feels :)

[1] https://github.com/matrix-org/matrix-doc/blob/matthew/msc232...

[2] https://github.com/matrix-org/matrix-doc/blob/kegan/msc/thre...

[3] https://github.com/matrix-org/dendrite/pull/1589

[4] https://github.com/matrix-org/dendrite/pull/1596

[5] https://github.com/matrix-org/cerulean

toomuchtodo2• 6 years ago

So...could I write a gateway that provides functionality for threads to be pulled in from HN/Reddit/NNTP/SMTP/Twitter (MSC2836)? Think Epiverse [1] within Matrix and its clients.

[1] https://epiverse.co/

the_duke3• 6 years ago

I realize it must be annoying to have this topic brought up every time Matrix is mentioned, so thanks for the update!

Nested threading could enable some interesting use cases, but I think for many contexts a single nesting level would be better though.

Is the current plan to allow customization via room settings?

alexvoda• 6 years ago

Does Matrix support linearly directed imageboards (e.g.:4chan) style threading?

In 4chan threading is done by linking the between posts using the post id permalink (1). This is aided by the UI which allows you to hover over the listed ID and see parents or children. This results in being able to respond to multiple posts in a single post. This means that instead of tree structured threading, DAG style threading is possible. The second consequence is that by default posts are displayed linearly, like an IRC discussion. This linear display results in unlimited nesting depth. Nesting is not dependent on indentation.

(1) https://www.4channel.org/faq#quote

rkangel2• 6 years ago

I actually think that the MS Teams implementation of threads is the best.

The problem with the Slack implementation is that it's not the default. You have to understand it to use it, and you have to have an organisational culture that pushes people to use it. Otherwise you end up only occasional threads, and mostly you're back in in the classic Slack '200 messages since you last visited, only 10 of them are of interest, but you have to read everything to find them' situation.

I like the Zulip version, it is automatically threaded but personally I had a slightly silly problem - you had to think of a topic name. It's a bit like the subject line of an email, except that you don't want it to be as long. This increases the friction slightly and you inevitably end up with a lot of messages going in one topic called something like 'general' when people can't think of a suitable topic name. I haven't used Zulip as intensively as the other two though, so maybe that problem goes away (or maybe it gets worse).

Teams is a lot like Zulip. Everything is in a thread automatically, but you don't have to name it, you just start a new 'conversation'. It works pretty organically, and it works by default without any 'culture' needed. You can give a thread a title if you want, but you don't have to. A bonus of the structure of Teams is that private messages (as supposed to Team channels) are just are a normal sequence of messages like Slack or anything else, because that's what you want. Teams is a memory hog and sluggish to use, but I do think they got that bit of the user experience right. Like many companies we had enforced, hurried massive increase in usage of Teams in March, and it has worked pretty seamlessly.

unicornporn• 6 years ago

Threads in Teams? I use it daily and have not noticed that feature. How? In the desktop client I can't even properly quote.

StavrosK• 6 years ago

I'll second Zulip, though I think the message view and "zooming in/out" they implemented is just as much of a game changer as the threading model.

sktrdie• 6 years ago

Can anyone explain what Matrix is and why is this interesting? Feels like we’re reinventing Jabber?

olah_1• 6 years ago

FAQ response here: https://matrix.org/faq/#what-is-the-difference-between-matri...

random9763• 6 years ago

It's totally different because it is a message syncing http+json API and totally not a messaging and presence protocol based on XML. /joke

It is interesting because Matrix has money thus full-time developers, marketing, exposure, and time to defend their work to the depth of the deepest reddit thread.

(The Element page on F-Droid reads "Element is able to do all this because it operates on Matrix - the standard for open, decentralised communication.", not presumptuous at all)

Arathorn19• 6 years ago

I love that all 3 of the snarky points here are illfounded :D

Yes, Matrix is a conversation history syncing protocol, and XMPP is a message-passing protocol. They genuinely are fundamentally different. It's a bit like the difference between SVG and Canvas. Sure, you can use both to draw pretty vector artwork. But one's an object graph, and the other's immediate mode.

In terms of Matrix having money: yup, it's true that folks have generously donated to Matrix over the years to keep the project afloat, and more recently Element has funnelled most of its VC funding into supporting Matrix. However, the whole "marketing, exposure and time to defend their work to the depth of the deepest reddit thread" trope is hilarious, given Matrix's marketing department is... me, the project lead? and I'm doing this in my spare time with my FOSS hat on. (technically there's benpa, our dev evangelist too, but he's ended up being hijacked by Element business this year).

Finally, "Matrix - the standard for open, decentralised communication" is like saying "Rugby - the game". It's not saying that Matrix is the one and only standard for open, decentralised communication any more than Rugby is the one and only game; it's disambiguating it from "Matrix - the mathematical construct".

Meanwhile, comically, xmpp.org declares itself "The universal messaging standard" and "XMPP is the open standard for messaging and presence".

¯\_(ツ)_/¯

zanny• 6 years ago

Jabber needed reinventing. XMPP grew and thrived in the early 2000s and died as every participant fragmented off to spin up a proprietary walled garden replacement. You then need something better than XMPP to fight back against that partitioning of the messaging space because XMPP implementations became too fragmented in feature compatibility to reliably compete.

SulfurHexaFluri5• 6 years ago

Part of me wonders if this is a fatal flaw in the very concept of distributed systems. It seems to me that as soon as a protocol or technology loses its single authority (multiple companies write implementations) it becomes feature frozen since it would be impossible for multiple companies to come to an agreement on what the new features should be or getting them all to implement them.

If matrix actually does succeed and continue to change I think it will result in having only 1-2 server implementations and 1 client per platform. A hobby dev can't possibly keep up with all the features being implemented by a whole team working on the main client.

mbirth3• 6 years ago

XMPP is anything but dead yet. There were a lot of XEPs added and updated in recent years and it turned into a modern protocol being able to provide all features you could expect from a modern messaging service.

It's just that you need a client and server that supports those features. Daniel Gultsch has written an Android client[1], that's as good as it can be. He also offers a maintained XMPP server [2] providing the full-featured counterpart. But if you want to self-host, ejabberd supports all the features as does Prosody. For iOS users, there's Monal which is slowly getting there.

[1] https://conversations.im

[2] https://account.conversations.im

3r8riacz• 6 years ago

A simple thing won me over XMPP to Matrix: .well-known domain delegation to use @asd:example.com as username instead of @asd:some.subdomain.example.com while being able to use the subdomain cert for the server instead of the parent domain cert. XMPP only supported SRV delegation which required the parent cert on the virtual (sub)domain.

Ericson2314• 6 years ago

Good job! But I think I will loiter in the old bridge and new rooms on the Matrix side until the history is migrated. After that...yay!

lftherios• 6 years ago

decentralized protocols will win :)

haolez• 6 years ago

"In the medium/long term, it’s simply not going to be efficient for the combined Element/Gitter team to split our efforts maintaining two high-profile Matrix clients. 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 - 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."

It seems that Gitter will be shelved after a while.

toyg2• 6 years ago

As long as the actual system still does what Gitter does (i.e. provide a quick way to have project-related chatrooms), I don’t think anyone will care what it’s powered by.

Arathorn19• 6 years ago

To be 100% clear: we are not going to shelve the Gitter codebase until Element (or other Matrix clients) have total parity with it. And once we do, we'll replace the current Gitter codebase with a Gitter-branded version of Element, and make sure it's configured so all the Gittery stuff works as you'd expect... while also benefiting from all the work we're pouring into Matrix and Element. So, I'd see it more like Gitter sprouting E2EE, VoIP, widgets, reactions, video conferencing, open standard API, etc, rather than "gitter being shelved" :D

dralley• 6 years ago

Please consider more than just features when making this decision. Gitter has a very different user experience from Element at the moment.

Gitter's default layout is clean, information-dense and distraction-free. There is no "x has left/joined the room" spam, very little unnecessary whitespace, a bare minimum of icons (no "seen by", no miniature avatars in quotes and @callouts), and a more subdued color palette (emphasis is provided primarily by bold font rather than by different colors).

That's not to say that Element is bad, because it isn't. But for focused technical discussions, Gitter is much better in my opinion.

I've tried the "modern" compact and IRC layouts, but unfortunately they don't really solve these problems. Mostly they are the same amount of distraction packed into a more condensed form.

sandGorgon2• 6 years ago

oh this is huge. and right in time for the slack acquisition !

gitter fixes one of the biggest issues with matrix - the product/ux/ui.

one thing im not sure of is the conscious decision to deprecate mobile apps and instead recommend mobile web. https://gitlab.com/gitterHQ/webapp/-/issues/2281

is that a strategic decision ? because this wont be a pleasant experience is potentially a massive blocker for any type of serious usage.

Arathorn19• 6 years ago

We're not recommending mobile web; rather than replacing the native Gitter mobile apps with the Gitter mobile webapp, we're instead recommending folks move to native Matrix mobile clients like Element (or mobile web Matrix clients like Hydrogen, if they prefer).

sandGorgon2• 6 years ago

well you do

https://gitter.im/apps

The dedicated Android/iOS apps are no longer recommended and may be officially deprecated in the future. For mobile, we recommend using the mobile web version in your browser.Our efforts are focused on the webapp which is the backbone of the mobile/desktop apps but mainly focused on the web experience. There are a number of bugs in these desktop/mobile clients and they spread the Gitter team too thin for us to give them proper attention. The apps are open-source if you want to tackle something particularly annoying to you. (desktop, iOS, Android)

susam2• 6 years ago

This is a great addition to Matrix. One of the things I really like about Matrix is how matrix.org has an IRC bridge that bridges all of Freenode. It is good to see Gitter getting bridged into Matrix too.

For example, if you want to join Freenode #lisp channel via Matrix, you can do so by joining #freenode_#lisp:matrix.org. Here is a direct Element web client URL to it, in case you want to try it now: https://app.element.io/#/room/#freenode_#lisp:matrix.org .

Element (previous known as Riot) web client is a great way to get started with Matrix without having to install anything. You have to create an account of course but after that it is pretty straightforward. The fact that all of Freenode (and now Gitter) is available on it makes it like one big IRC bouncer. Moreover, this is all distributed and decentralized!

Here is another safe Matrix room to try out and experiment with: https://app.element.io/#/room/#spxy:matrix.org . Most of us here are from Hacker News. We talk about computer science and mathematics here. Common Lisp and Emacs are being discussed these days. Say "hi" if you join it! :)

Liskni_si2• 6 years ago

Does the IRC bridge work reliably for you? I tried experimenting with Matrix today, I could make it to join #freenode_#xmonad:matrix.org but any message I sent didn't go through to the IRC side. When I then joined #irc:matrix.org it seems several other people were reporting this not working lately.

To make this experience even less amusing, I then tried to join #xmonad:matrix.org, assuming it's the matrix equivalent of #xmonad on freenode, but it just said I'm not invited and that was it.

Can't say I'm impressed. :-(

susam2• 6 years ago

The IRC bridge has worked reliably for me so far. My messages from Matrix get delivered to Freenode IRC channel without any problems, so far.

The settings of #xmonad:matrix.org show that they allow only invited users to access their room. Here is a screenshot of their room settings: https://i.imgur.com/vxap6wY.png . This is a little weird indeed. However, there are other plenty of other rooms that do not require invitation to join.

doc_gunthrop• 6 years ago

If anyone on the Gitter/Matrix dev team is reading the post comments, here's a question for those who already use both platforms:

If I have an account on Matrix, but I also sign into Gitter with Github credentials, how would I go about merging the two accounts (without loss of data)?

TehCorwiz• 6 years ago

I don’t mind that being an option, but I would not want that happening automatically.

Arathorn19• 6 years ago

We don't have account merging yet, as while Matrix can see all of Gitter, we're not exposing the entirety of Matrix into Gitter (mainly because it'd cause the Gitter AWS bill to go through the roof :P). Once Gitter becomes a pure Matrix client, though, you'll automatically be able to use your Gitter.im homeserver credentials to access Matrix, and with account portability (MSC2787[1]) there /may/ end up being a way to combine two existing accounts into one.

fractalf• 6 years ago

Very nice, GJ! Matrix is the FURURE. Now the work begins converting all slackers...

IshKebab• 6 years ago

It might be the future, but it isn't the present while it doesn't have basic Slack features like threads.

SulfurHexaFluri5• 6 years ago

Matrix has threading at least in the spec.

Evidlo2• 6 years ago

Hail the furure!

JD557• 6 years ago

Hi there.

I'm completely new to Matrix, so sorry if this is a stupid question, but is there something like a gitter homeserver where I can login with my gitter credentials?

If so, what homeserver URL should I use in element?

Arathorn19• 6 years ago

You can't use your Gitter creds to log into Matrix yet (although we're hoping to support Gitlab/Github/Twitter login for Matrix before Christmas).

Instead, just sign up for a Matrix account via Element or another Matrix client, and then you can look at the Gitter server's room directory at Gitter.im and join its rooms from there. Because Matrix is one great big open network, you can pick any server for your account; you don't have to use the Gitter one :)

coolreader18• 6 years ago

That'll be a nice Hanukkah/early Christmas gift, depending on when it lands :)

Will there ever be a way to show on gitter that a gitter account and a matrix account are the same person? I'm pretty active on gitter right now, and I'd like to choose a homeserver to have an account on so that my messages from the gitter client (logged in with gh) and the messages from a matrix client are from the same user. Would github login allow that?

Edit: also, what's the plan for private/invite-only gitter rooms?

siraben• 6 years ago

This is a much welcome change. Gitter has been pretty klunky to use (especially the stalled mobile client), and the Gitter-Matrix bridge had multiple pain points as well. Looks one step further towards the Universal Communication Bus[0]!

[0] https://medium.com/@ericmigi/the-universal-communication-bus...

dpc_pw• 6 years ago

Fantastic. The pace of introducing such a change speaks loudly how good the engineering around teams and product involved must be.

Stephen3042• 6 years ago

This is amazing! Side note, there seems to be a typo "would be to have got Gitter".

Also, I'm curious what the plan is to reconcile Gitter's one room per repo model with Matrix's anybody-can-create-any-room - in the long term, is the plan to keep gitter.im rooms restricted to matching repos? Or (post gitter-skinned-element) will people eventually be able to create arbitrary rooms on the gitter homeserver?

Arathorn19• 6 years ago

An alternative architecture would be to have got Gitter directly federating

This isn't exactly elegant English, but I think it's structurally correct. In US English you might say "gotten Gitter", i guess.

Also, I'm curious what the plan is to reconcile Gitter's one room per repo model with Matrix's anybody-can-create-any-room

You can already create non-repo rooms in Gitter, so this one's already solved. For instance, I just created https://gitter.im/matrix-org/matthew-test (with no matching repo) :)

Stephen3042• 6 years ago

In US English you might say "gotten Gitter", i guess.

I assumed "got" was extraneous due to editing, removing it sounds a lot better to my ear: "An alternative architecture would be to have Gitter directly federating with Matrix by..."

I assumed it was a mistake due to editing, since I would use "got" primarily in this way: "An alternative architecture would be if we got Gitter directly federating with Matrix by...", to my ear "got" normally follows a noun, but I think the alliteration makes it sound extra awkward.

At any rate, I'm no english major so it's not a big deal.

You can already create non-repo rooms in Gitter

My question is less about non-repo rooms and more about rooms that look like repo-rooms. Is there any protection against a malicious user setting up "#google_chromium:gitter.im" and distributing malicious binaries?

Edit: Maybe I'm not really asking a clear question - overall I'm wondering what the long term plan is for the gitter room addresses, where you can be sure that matrix-org/matthew-test belongs to matrix-org. It seems to me that if the gitter room addresses are planned to be removed in the long term, the security implications of the room address will change, so I was looking for some mention of that in the post. Not that it's a huge deal if communicated properly, people would just have to be sure they found the room from an official repo and keep in mind that the restriction of creating rooms under the org is no longer present.

ktpsns• 6 years ago

Gitlab comes with an easy Mattermost integration. Therefore, we use Mattermost in our team instead of Gitter. What's the status of Mattermost vs. Matrix? I found https://about.mattermost.com/matrix/ but this seems to be ... irony ;-)

Arathorn19• 6 years ago

I can only assume that https://about.mattermost.com/matrix/ is evidence of a major skunkworks Mattermost project to implement native Matrix interoperability :D

Vinnl3• 6 years ago

Great news! Very quickly done, which kind-of makes me suspicious... One thing I did already observe is that I was able to send a message to a closed Gitter room via my Matrix account, although I couldn't see other people's messages.

MadLittleMods4• 6 years ago

Thanks for the heads-up! Working on a fix so you can't query a private room and send in Matrix events. We already block from Gitter -> Matrix side.

MadLittleMods4• 6 years ago

Update: Fix deployed -> https://gitlab.com/gitterHQ/webapp/-/blob/develop/CHANGELOG....

kawfey• 6 years ago

The ecosystem of a multitude of various chat apps is daunting and confusing. I've been finding that I'm spending more time talking and thinking about chat programs rather than actually doing anything valuable. It's kind of like how ham radio operators almost exclusively talk about ham radio on ham radio (when not talking about weather and personal ailments, lol).

Arathorn19• 6 years ago

It's like all the people on the Web who sit there discussing how to make the Web better :D doesn't mean it's a bad thing.

throwaway894345• 6 years ago

Is there a good reason why we have a distributed platform for IM and other distributed platforms for e.g. social media (think Mastodon) that appear to work the same way except that the data types are different? Could this “distributed server atop HTTP/whatever” be abstracted out into its own protocol such that anyone could more easily build distributed applications for their own domain? Maybe there is more variation between domains than I am aware of?

Arathorn19• 6 years ago

ActivityPub, Matrix, XMPP and NNTP all do superficially similar things in very different ways. I personally think of ActivityPub as being a bit like multiplayer RSS; Matrix as being like a replicated pubsub open object database; XMPP like a overgenerously extensible messaging protocol; NNTP like a semi-closed federated BBS.

They all have different primitives and semantics - it’s not just data types. Matrix is the only one which actually implements a full data structure replication protocol between nodes, for instance.

Braid https://braid.news/ is one way you might be able to abstract thag operation on HTTP tho.

brianzelip• 6 years ago

Here's an informing (and inspiring!) Changelog podcast episode with a technical co-founder of Matrix, https://changelog.com/podcast/384.

dstaley• 6 years ago

I truly hope that Matrix+Gitter becomes the defacto standard when it comes to chat for open source communities. I think Discord is a bit ahead in terms of UX and features, but Matrix is catching up fast. I noticed that Element recently added support for Communities, which is sort of like a Discord server!

Evidlo2• 6 years ago

I think they may be called "spaces" now.

mxuribe2• 6 years ago

This is great news! Congrats to the matrix (and element) and gitter teams!!

smarx007• 6 years ago

Great news! How do I make it work? I just tried in our room https://gitter.im/OSLC/chat# and I still see the matrixbot. The post talks about how to connect another chat system to Matrix but there are no instructions for Gitter itself.

Edit: Okay, this is what should have been in the post: go to Explore rooms, and instead of choosing Gitter, select Add new server and type 'gitter.im'. Now you can find a room through a native integration.

FloatArtifact• 6 years ago

This is very exciting. On the element client edits from gitter via the gitter bridge currently do not display very well. The bridge creates a new pseudo post when edits are made. Will these edits automatically be cleaned up in the history of a room in the future?

ptman2• 6 years ago

Previous history is probably not going to get rewritten. The ugly edits are sent by the old gitter bridge, the new gitter bridge can bridge edits properly.

Gitter now speaks Matrix

Related Stories