Gitter now speaks Matrix
matrix.org
matrix.org
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)
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
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.
But nobody has fully packaged one up as FOSS Disqus/Intercom/etc alt yet. It's a huge and easily-fillable gap in the Matrix ecosystem :)
So thinking out loud, for a disqus clone - sticking to unencrypted rooms and web components could be the way to go! Thanks for the GSOC and Hydrogen links - will check them out!
I guess anything is possible with custom code though.
Does it send every URL you load to a third-party server to provide this functionality?
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?
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.
Having said that, there's also 'reply to thread and also share to channel', making it even worse. I think that one's the closest Slack has to fixing threading's problems though - if you're aware of it being a potential issue, you can at least highlight it.
It'd be good if there were an 'active thread(s)' thing that appeared on the right side or something (at the bottom of what is the the thread panel when one's open, I'm imagining though. Easy to ignore, but when you're checking if there's new messages in your main channel you'd also see if there were new thread activity.
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.
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.
It's half-baked, but it seems like a great alternative to regular presentation: linear history, but filterable.
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.
Essential for group chats and still useful for DMs.
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! :)
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. :-(
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.
Also, #xmonad:matrix.org being invite only seems to be another bug. I contacted the room admin who sent me a similar screenshot as you did, showing that the room is _not_ set to invite-only, and they had to upgrade the room version from 1 to 6 to fix it. I can now join the room.
I have to say this has been a very frustrating experience. In addition to these two problems with #xmonad, I also suffer from https://github.com/poljar/weechat-matrix/issues/248, https://github.com/wee-slack/wee-slack/issues/812. I am afraid the takeaway is that Matrix is not ready yet. :-/
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.
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)?
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. Store and forward 2. e2e encryption 3. Messages received on multiple clients at the same time, with clients being able to reconnect and pick up the complete conversation history.
In theory, all possible.
In reality, none of the clients I tried supported the same combo of XMPP plugins and encryption methods.
Oh, and I need clients that work on MacOS, Windows, and Android.
I am using conversations legacy on Android right now because that works with how ejabberd is setup on my machine, and how ejabberd is setup works with the clients other people I want to talk to are using.
I gave up using XMPP on a laptop since I'd get encrypted messages with the wrong key sent to other devices except whichever one I'd used most recently to send a message with.
I never did manage to set sending images working at faster than ~2KB/s.
It is like I am back in 1996 and using AOL IM, but worse.
To have OMEMO working between multiple clients but the same user, make sure they’re all running and send a message from each client to your OMEMO contacts so they learn all your different keys and send answers encrypted for all of them.
In regards to Matrix. There’s only one reference client at the moment. But once other clients emerge and the protocol gets extended, they’ll probably have the same fate in that many 3rd party clients won’t support all features.
Conversations doesn't display when your friends are online or not, which is fine if they are almost always online but if they are offline a lot, then depending on the server configuration and the phase of the moon, messages sent while offline go missing (silently of course).
EDIT: I think the only setup I could whole-heartedly recommend non-technical friends is Conversations talking to Conversations with Prosody default-settings server(s).
Among other things, my server has message archiving configured for MUCs, but Conversations is the only client I've ever been able to get to sync that history locally. That's something I just don't ever have to worry about with Matrix. (Not that I don't have other complaints with Matrix.)
Also, Gajim has support for MAM and can sync everything locally. I believe Monal has it, too.
Yes, I've heard that Gajim and Monal support it. I'm running both of them right now; Gajim doesn't appear to be fetching history from the server for the MUC I'm looking at in either the chat or history windows, Monal seems to attempt to but shows a progress spinner indefinitely. Conversations successfully loads history from the server; I can scroll back to well before I got this phone so I know it's not just local.
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.
For example, Apple adds person to person payments in imessage and it suddenly just works for every single imessage user. If someone did that as a feature on top of matrix you now have a situation where some clients support it and some don't so the feature never really gets used as its too unreliable. Maybe over time the feature rolls out to more clients but there will always be some devs who think "No I don't like this feature, I won't ever add it"
I guess things are a little simpler here since it might be possible to implement new features without server changes as they may just work on top of the standard matrix spec.
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)
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".
¯\_(ツ)_/¯
It's like self-loathing teens reflexively making fun of an enthusiastic teacher. Except we're presumably all adults here.
At this point you've probably realized that it's still immensely more than what XMPP-the-protocol has ever done: a voice that is present on all fronts to talk about it and spread the word about our Savior :)
When you want to "get into" XMPP you have to choose between NN clients, and pick a proper provider among the YY that can give you an xmpp address. When you're starting with Matrix there's a server that is "right" for beginners, with a client that is the flagship so every standard feature can be expected to be there and work, there's a company that funds its development...
You might be the only person in Matrix's marketing departement, but I guess it works this way because the way the ecosystem is today, one person is enough !
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?
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 :)
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?
There isn't really a plan for private/invite-only rooms but we could possibly support `virtualUsers` in the `sd.extraMembers`(security descriptor) field to allow inviting Matrix people to a private Gitter room.
[0] https://medium.com/@ericmigi/the-universal-communication-bus...
One other thing: my message was still posted by @matrixbot, rather than by my Matrix user. Is this another case of every client having to migrate (I'm using Fractal)?
`@matrixbot` does show in the browser notification but we do plan to fix that up: https://gitlab.com/gitterHQ/webapp/-/issues/2695
If you see messages directly from `@matrixbot` in the chat area, then that means that the room is still plumbed using the old Gitter bridge. We're working on a plan to migrate rooms using the old bridge over to the new one, https://gitlab.com/gitterHQ/webapp/-/issues/2674
It seems that Gitter will be shelved after a while.
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.
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.
>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)
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.
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?
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) :)
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.