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)
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 :)
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.
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.
Wow, it would be really, really interesting for a blog to offer a Matrix room as a "comment section". If you didn't care about threading, you could probably do something like that even today.
We've been working on some Web Components that use the js sdk to talk with matrix but have been wondering if we should spend time looking at how the react sdk could be implemented in this use case assuming it would better handle encryption etc... although I think I read recently that the js sdk also handles encryption - but we'd need to add UI for verification to access encrypted rooms which seems likely to be a pain across browser sessions... there's also an issue as to which websites you might trust to share your matrix user token with to post on your behalf (but will check out Hydrogen to see how it handles this).
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!
That can definitely be done today: just point a link to a public matrix room...well, the participants would need an account associated to a homeserver first in order to interact...but that's no different - conceptually - than needing to have a disqus account. The benefit of course is that their account can be associated to their __own__ homeserver! In fact, i do this already on my website; though for general contact (like a poorman's contact form), rather than a comment section for blog posts - but the approach works for either perspective.
I wonder how that would work performance wise since I assume comments sections on blogs are loaded many many more times than they are edited so you would want some super fast caching on it.
I guess anything is possible with custom code though.
You know what would be a great goodwill-building move from Github and Microsoft? Them running a Matrix server instance and provide a chat room for each Github repo. This is what Gitter used to offer. Federation allows even competitors to interoperate.
We haven't got as far as figuring out how to advertise/negotiate the threading flavour of a given room. It'd suck if half the people in the room are trying to use it like IRC and the other half are trying to use it like HN tho!
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.
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.
Threads in Slack are useful but the implementation is pretty bad. For example you don't see new responses in a visible thread until you click the button for more messages. It makes them really frustrating to use. Slack does a lot of things really well which makes the pain of using threads even worse.
I also wish there wasn't 'sharing', or at least not to the same channel, so that there's one clear way for the 'continue earlier topic' use case.
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.
> 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.
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.
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'.
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.
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.
In a normal Team channel (i.e. not a chat message) when you press 'New conversation' you type a message and then people reply to that. That is a thread. The fact that you didn't even think of it as one I take an indication how seamless it is.
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.
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! :)
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.
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.
It seems only #xmonad on freenode is affected, so I've been asked by @matrixdotorg to report an issue and I'll do that asap.
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.
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?
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.
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!
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)?
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.
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 ;-)
I can only assume that https://about.mattermost.com/matrix/ is evidence of a major skunkworks Mattermost project to implement native Matrix interoperability :D
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.
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.
I spent a long time trying to get the following to all work:
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.
I’m using ejabberd 20.07 on a Raspberry Pi 4, Conversations (paid) on Android, Monal on iOS and macOS and Gajim on Windows and Linux (sometimes macOS, too). OMEMO works fine between those. So do attachments/file transfers (not slow at all). Also MAM/history.
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.
Just for the sake of accuracy, Matrix really does have a lot of impressively feature complete clients these days - Element, FluffyChat, Weechat, Mirage etc (and technically Element is 3 entirely non-overlapping codebases on web/desktop, iOS & Android). And the protocol is busy evolving; with MSCs landing on some clients before others (e.g. FluffyChat implements BlurHash based image thumbnails but Element doesn't yet). So far we haven't had massive fragmentation though, because the spec itself is monolithic - it's completely unambiguous on what the official recommended featureset is at any point in time. Anything beyond that is experimental, and there's no guarantee that it will work compatibly at all. So when something like blurhashes turns up as a random community spec change proposal (https://github.com/matrix-org/matrix-doc/blob/anoa/blurhash/...), some clients go and implement it, and once proven it gets baked into the official spec.
xmpp works, but barely. Some people will insist on you talking to them using otr, and other will insist on omemo. Multi-device kinda sorta works sometimes. If you have program 1, the other person has program 2 on phone and program 3 on computer, and the issue is also potentially with the configuration of server program 4 or 5, then it starts to get complicated when issues inevitably crop up. Some of which lead to messages just silently going missing, and you mistakenly think that your friend is ghosting you unless you have an out-of-band way to communicate.
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).
Needing a client that supports those features seems like a big ask, though. You're right that Conversations is about as good as an XMPP client can be, and it's a joy to use... but it's one of very few.
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 not many, but they all get history syncing down. They have to, it's at the core of the protocol. (And that aside, at least Element is available on just about every platform.)
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.
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.
it doesn’t have to be a fatal flaw. you “just” have to layer the protocol to give decent abstractions to allow diversity on top of each layer, so as each layer matures you just keep innovating upwards - like the ethernet/ip/tcp/http stack for instance.
The problem I see is every time you drop an extra layer of innovation, you fragment the final product.
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.
This is a great example. Matrix has the concept of widgets which let you embed little webapps, which can be used as a compatibility layer for stuff like payments. For instance video conferencing is done in Matrix as a widget (Jitsi) for clients who just support widgets... but clients with native jitsi support (Element iOS and Android) integrate it natively rather than using a widget.
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.
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)
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".
> 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?
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?
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 :)
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?
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.
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]!
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.
Thanks! I'm still in the room with no feedback that sending the message failed, but from the room's point of view it's now private.
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)?
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
Are you sure it's a room issue? In the same room where my message was sent directly by @matrixbot, I can also see an earlier message from someone else from @theiraccount:matrix.org.
"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.
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
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.
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.
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).
>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)
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.
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?
> 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) :)
> 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.
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).
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?
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.
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)