Synchronous Messaging at Mozilla: The Decision(discourse.mozilla.org)
discourse.mozilla.org
Synchronous Messaging at Mozilla: The Decision
https://discourse.mozilla.org/t/synchronous-messaging-at-mozilla-the-decision/50620
257 comments
I'm pleasantly surprised! They took the route of "promising but underdeveloped technology" rather than settling for a well-developed solution that compromises their principles (which, frankly, I wouldn't have faulted them for; at the end of the day you still have to get work done). With luck maybe we'll see Mozilla contribute to Matrix? There is, after all, an implementation written in Rust: https://github.com/ruma
The last ruma commit was in August, which was after a long period where nothing happened at all. Is the project dead?
I actually interviewed the author in August for our Rust podcast, on which he says he's waiting for async to mature before progressing further: https://rustacean-station.org/episode/001-ruma/
I love the name of your podcast.
Thanks! Also, while we're here, let me advertise that this is not just "my" podcast, it's a community-based podcast that accepts audio files from anyone who wants to make any Rust-related podcast content but who doesn't want to go through the trouble of setting up a website, file hosting solution, podcast index integration, and so on. Contributions accepted. :) https://github.com/rustacean-station/rustacean-station.org/
What a cool concept. Have you had many episodes contributed so far?
Of our seven episodes only one hasn't been a product of me or Jon: an interview with Armin Ronacher about using Rust in production (https://rustacean-station.org/episode/004-rust-in-production...). Though we're about to publish our second externally-produced episode tonight, an interview with the creator of static site generator named Zola (née Gutenberg).
Plenty of people say tell us they're going to contribute, but you know how life gets in the way. :) We're not bothered by having a low-volume or irregular release schedule, this is just a fun side project for us.
Plenty of people say tell us they're going to contribute, but you know how life gets in the way. :) We're not bothered by having a low-volume or irregular release schedule, this is just a fun side project for us.
No, the last commit was two days ago: https://github.com/ruma/ruma-events/commit/c7d7212b000e324b9...
It is a bit hard to follow their project since they have split it up in so many tiny repos. I personally prefer when a set of closely related crates are developed in one mono repo.
It is a bit hard to follow their project since they have split it up in so many tiny repos. I personally prefer when a set of closely related crates are developed in one mono repo.
For rust it's sometimes useful to split it like that, because it makes it easy to publish small subsets of your project on cargo. Say you develop a custom datastructure, or an extension on Streams.
The same applies to other languages to some degree, but crates/cargo just makes it very painless to grab crates that are on a seperate git.
The same applies to other languages to some degree, but crates/cargo just makes it very painless to grab crates that are on a seperate git.
But Cargo supports having multiple crates in the same git repo. Many projects do this like regex (regex and regex-syntax are in the same repo) and openssl (openssl, openssl-sys, openssl-errors). Maybe I am missing something but it seems very easy to handle multiple closely related crates in the same repo.
What makes this possible is Cargo's "workspace" feature, which is relatively new enough that it's not hard to imagine that some older projects may simply predate it.
Would something like git subtree help here? Allow people to continue working with their individual repos but present a unified view for outsiders to follow along? We could automate this, right?
Hm, I have been doing this just fine without using the workspaces. What am I missing?
Cargo workspaces are more of an optimization in that they let all the crates in your project share the same output directory[0], so built dependencies can be shared among every crate, as opposed to each crate needing to (re)build all of its dependencies independently.
This helps to reduce compile times when working on projects where you frequently switch between crates.
[0] https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html
This helps to reduce compile times when working on projects where you frequently switch between crates.
[0] https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html
Oh indeed, thanks for pointing out! Wishing them luck then.
The latest status seems to be https://github.com/ruma/ruma/issues/189#issuecomment-5539555... from a month ago. It looks like he is working on the client while he waits for Rust web server frameworks to adopt the recently-released async-await language features.
edit: https://www.ruma.io/status/ is a better overview
They just put up a blog post going over their progress https://www.ruma.io/news/these-weeks-in-ruma-2019-12-14/
The author says they’re waiting on Rust and Matrix features/documentation. There’s an open issue with more details
https://github.com/ruma/ruma/issues/189
https://github.com/ruma/ruma/issues/189
[deleted]
So after testing matrix and riot with friends for a couple of months, there're still a ton of work to be done. We all used the most common setup - matrix.org homeserver, riot and riotX as apps. (Also please don't point me to dev version, I am only considering what's in stable.) Random stuff not in particular order:
1a) e2e is a choice that affects experience in riot, a lot - you can't use search, you don't see recent images/files ...
1b) you have to verify each others devices, N:M; although they're working on a change
2) I hoped that riotX will be a lot better at the end of this year, but there're still lots of bugs, messages get stuck at the bottom, mobile - mobile e2e can't be decrypted sometimes, you have to have another device online; and you can't even zoom in or save an image that's sent to you which is infuriating
3) matrix.org homeserver performance, although a lot better now is still sometimes utterly slow
4) riot is still missing crucial functions like copy entire message, online status, jump to date, and lacking any good notification system(the current one is really simple/stupid) and you can't even enable notifications without sound e.g.
4) also it's still lacking custom emote support although many ppl asked, there's no option to pin/save messages...
1a) e2e is a choice that affects experience in riot, a lot - you can't use search, you don't see recent images/files ...
1b) you have to verify each others devices, N:M; although they're working on a change
2) I hoped that riotX will be a lot better at the end of this year, but there're still lots of bugs, messages get stuck at the bottom, mobile - mobile e2e can't be decrypted sometimes, you have to have another device online; and you can't even zoom in or save an image that's sent to you which is infuriating
3) matrix.org homeserver performance, although a lot better now is still sometimes utterly slow
4) riot is still missing crucial functions like copy entire message, online status, jump to date, and lacking any good notification system(the current one is really simple/stupid) and you can't even enable notifications without sound e.g.
4) also it's still lacking custom emote support although many ppl asked, there's no option to pin/save messages...
2) could be partially solved by backing up all of your keys from all devices. After that, non-decryptable messages decreased about 95%.
Ironically, backing up your keys is done by recovering your keys from a backup – Settings → Cryptography Keys Management → Encrypted Messages Recovery → Restore from backup.
(Web version: Settings → Security and Privacy → Key Backup → Restore from Backup)
You can verify that you set it up properly by checking if the backups are signed by all your currently used devices (and possibly old ones, too).
3) can be mitigated by using workers. You'll need a beefy server, but message transfer and synchronisation will be super fast.
The other things you mentioned are works in progress and I think the progress is outlined pretty transparently on Github, even if some people disagree with how the Matrix team is handling things.
Ironically, backing up your keys is done by recovering your keys from a backup – Settings → Cryptography Keys Management → Encrypted Messages Recovery → Restore from backup.
(Web version: Settings → Security and Privacy → Key Backup → Restore from Backup)
You can verify that you set it up properly by checking if the backups are signed by all your currently used devices (and possibly old ones, too).
3) can be mitigated by using workers. You'll need a beefy server, but message transfer and synchronisation will be super fast.
The other things you mentioned are works in progress and I think the progress is outlined pretty transparently on Github, even if some people disagree with how the Matrix team is handling things.
1a/1b and 2 is where all our work is going currently. We're trying to get E2E on by default in Jan, and likewise exit beta for RiotX/Android around the same time. We're going as fast as we can.
3: Matrix.org homeserver performance should be absolutely fine now. Delays when doing things like joining big rooms are unrelated to the hardware, but perf optimisations we need to do to synapse in general. They're on the radar.
4: This is literally the first time i've heard an ask for 'copy entire message'. The other features exist in labs, and yes, we need to fix notifs and add custom emoji. "Many people asking" doesn't magically produce features unfortunately, especially when we are battling points 1 & 2. Contributions help though. Thanks for testing though.
3: Matrix.org homeserver performance should be absolutely fine now. Delays when doing things like joining big rooms are unrelated to the hardware, but perf optimisations we need to do to synapse in general. They're on the radar.
4: This is literally the first time i've heard an ask for 'copy entire message'. The other features exist in labs, and yes, we need to fix notifs and add custom emoji. "Many people asking" doesn't magically produce features unfortunately, especially when we are battling points 1 & 2. Contributions help though. Thanks for testing though.
After spending several months convincing a few friends to use Riot, the ongoing fiasco with E2E has caused all of them to leave within a couple of days. Obviously they're unlikely to ever come back.
It's a real shame. These are technical people who don't particularly mind verifying a key by hand. In fact I personally even prefer it.
The problem is not only that certain things are not done automatically, but that the UI is designed to make it difficult to do them even manually!
E.g., I have one device 'foo' which you already trust. I add a new device 'bar'. Why on earth would you want to verify its key manually when I could just send you the new key from 'foo' which you already trust?
Even worse, the key for 'bar' is not straightforwardly available anywhere in the UI on device 'foo'. It should be easily viewable in the right hand pane where the list of devices is, but it's not. The only way to get the device ID and key is to send a message from 'bar' to 'foo' and view the details of the message. Why?
It's a real shame. These are technical people who don't particularly mind verifying a key by hand. In fact I personally even prefer it.
The problem is not only that certain things are not done automatically, but that the UI is designed to make it difficult to do them even manually!
E.g., I have one device 'foo' which you already trust. I add a new device 'bar'. Why on earth would you want to verify its key manually when I could just send you the new key from 'foo' which you already trust?
Even worse, the key for 'bar' is not straightforwardly available anywhere in the UI on device 'foo'. It should be easily viewable in the right hand pane where the list of devices is, but it's not. The only way to get the device ID and key is to send a message from 'bar' to 'foo' and view the details of the message. Why?
> E.g., I have one device 'foo' which you already trust. I add a new device 'bar'. Why on earth would you want to verify its key manually when I could just send you the new key from 'foo' which you already trust?
This particular issue is being worked on right now in Riot, and should be fixed early in the new year.
This particular issue is being worked on right now in Riot, and should be fixed early in the new year.
That is awesome, but any thoughts on why I cannot easily view the keys of my other devices in the UI?
If I could then this would be a minor inconvenience at best, I'd just copy/paste the key from the already-trusted device.
If I could then this would be a minor inconvenience at best, I'd just copy/paste the key from the already-trusted device.
I guess we just prioritised working on cross-signing etc rather than adding in UI for this. Sorry; it's an oversight.
Thank you for your quick and patient answers to my perhaps too demanding questions.
Cross-signing is obviously better, no question about that. However this simple UI change would be at least 95% as good, and certainly good enough to have prevented my friends from giving up on Riot.
I hope that is at least somewhat constructive. Thank you for your work.
Cross-signing is obviously better, no question about that. However this simple UI change would be at least 95% as good, and certainly good enough to have prevented my friends from giving up on Riot.
I hope that is at least somewhat constructive. Thank you for your work.
I guess https://github.com/vector-im/riot-web/issues/2735 is the bug to upvote. Annoying it's been stuck open forever :(
> Obviously they're unlikely to ever come back.
I recognize this is a common attitude, but it makes no sense to me.
Some software you tried today isn't designed in a way you prefer, so you go back to using something else. Okay. Makes sense.
But to declare the whole project forever hopeless as if it can never be improved upon because the snapshot of your first experience with it was negative is truly irrational.
I recognize this is a common attitude, but it makes no sense to me.
Some software you tried today isn't designed in a way you prefer, so you go back to using something else. Okay. Makes sense.
But to declare the whole project forever hopeless as if it can never be improved upon because the snapshot of your first experience with it was negative is truly irrational.
Keep in mind the only reason they tried the software is that I regularly pressured to do so for months, before they finally caved.
After all that they quickly come to realize that something simple like adding a new device is a massive pain in the ass.
It's not that they declare the whole project as forever hopeless, it's that they invested time and effort into trying it already and it turned out (for them) to be a waste.
It's just a bad taste left in the mouth. In order for them to try it again, they not only have to overcome their natural laziness/time constraints, but also the rather unpleasant memory of the last time.
After all that they quickly come to realize that something simple like adding a new device is a massive pain in the ass.
It's not that they declare the whole project as forever hopeless, it's that they invested time and effort into trying it already and it turned out (for them) to be a waste.
It's just a bad taste left in the mouth. In order for them to try it again, they not only have to overcome their natural laziness/time constraints, but also the rather unpleasant memory of the last time.
The same thing happened to me, but I am thinking of having another go and just discouraging the use of E2EE. (The community I’m thinking of is currently on Slack, so there would be no marginal loss of privacy.) Have you considered that, or is your group already using another E2EE platform that isn’t a massive pain in the ass? I’ve yet to discover one myself.
They all use Signal, with varying degrees of dissatisfaction. I'm the only one who doesn't have a Signal account.
I think it's less that people assume that it can never be improved and more that they find something else that is "good enough" and they won't leave that ecosystem until it stops being good enough. Generally speaking, I've found others (and myself, at times) don't re-evaluate their options until there's a need for them to upgrade or its brought to their attention by someone else.
For me it is usually lost trust in the creators. If they market it like a finished product when it barely works I will not trust them anymore.
Now, if it is obvious that something is a work in progress then I personally wont mind giving it a new shot.
Now, if it is obvious that something is a work in progress then I personally wont mind giving it a new shot.
On 4, yes, please support "copy entire message". It already works if the entire message is a code block, and it's unfortunate there is no alternative when it is not.
I've often encountered this when I paste one of my Markdown notes from my knowledge base into the chat in order for it to be rendered so that the other participants may read it in a visually appealing form. But then I decide that I also want to give this same note to someone else in another room, but there's no way to copy the message and simply paste it at the new destination.
Conversely, sometimes I write a worthwhile Markdown note directly in Riot and I'd like to save it in my notes system, but it's hard since there is no "copy entire message" button.
I've often encountered this when I paste one of my Markdown notes from my knowledge base into the chat in order for it to be rendered so that the other participants may read it in a visually appealing form. But then I decide that I also want to give this same note to someone else in another room, but there's no way to copy the message and simply paste it at the new destination.
Conversely, sometimes I write a worthwhile Markdown note directly in Riot and I'd like to save it in my notes system, but it's hard since there is no "copy entire message" button.
ad 1a - E2E by default - meaning you'll flip the switch once there's a feature parity with non encypted rooms in riot?
ad 3 - from my testing it's fine for about 98% of the time, but sometimes it takes ~3-8seconds to send a message (sitting on 300 or 500Mbps wired connection), in e2e direct message room
ad 4 - @ copy entire message - interesting, i needed it just recenly so i went into the submenu and there's show source, show decrypted source (which is cool but maybe something that should probably be enabled in via a toggle in the options menu) and quote but no message copy (and using quote messes up markdown formatting...)
ad many people asking - i totally understand that, however, this could be used as a roadmap for shipping features. And since I don't write code (read javascript) I am trying to contribute with testing/reporting bugs (so although not obvious from my OP, my testing continues as is suffering of my friends ;) )
ad 3 - from my testing it's fine for about 98% of the time, but sometimes it takes ~3-8seconds to send a message (sitting on 300 or 500Mbps wired connection), in e2e direct message room
ad 4 - @ copy entire message - interesting, i needed it just recenly so i went into the submenu and there's show source, show decrypted source (which is cool but maybe something that should probably be enabled in via a toggle in the options menu) and quote but no message copy (and using quote messes up markdown formatting...)
ad many people asking - i totally understand that, however, this could be used as a roadmap for shipping features. And since I don't write code (read javascript) I am trying to contribute with testing/reporting bugs (so although not obvious from my OP, my testing continues as is suffering of my friends ;) )
1a: Yes. the second we have parity, we'll start turning it on by default for private rooms. We'll probably start with DMs, and we'll probably do a fairly soft roll-out to sneak in some final testing. Current status is that we have E2E Search working (github.com/matrix-org/seshat); we have E2E cross-signing almost done (https://dashboard.lant.uk/#/plan?epic=vector-im/user-stories... we have eyes on the remaining causes of undecryptable messages and are working through them. We're aiming for Jan.
3: Interesting. It could be a very temporary CPU saturation on the Matrix.org CPU master. We're working on sharding the master per-room to mitigate this, but it's going to be a few months to land.
4: Looks like there is a bug for this already - please upvote https://github.com/vector-im/riot-web/issues/10649.
Testing & reporting bugs is absolutely invaluable - thank you.
3: Interesting. It could be a very temporary CPU saturation on the Matrix.org CPU master. We're working on sharding the master per-room to mitigate this, but it's going to be a few months to land.
4: Looks like there is a bug for this already - please upvote https://github.com/vector-im/riot-web/issues/10649.
Testing & reporting bugs is absolutely invaluable - thank you.
This is really good news. I have only one question for Mozilla: why choose a solution whose hallmark is decentralization and the libre model- only to become a customer of a centralized host (modular.im). Why can't Mozilla actually federate? That's a step backward from your IRCd in my opinion.
I hope Mozilla gets onboard with everyone else running their own Synapse, hacks on it, and pay their dues with patches, rather than with their cash.
I hope Mozilla gets onboard with everyone else running their own Synapse, hacks on it, and pay their dues with patches, rather than with their cash.
They are using a hosted provider, run by the makers of Matrix themselves. This lets them get the benefits of federation while making the hosting someone else's problem.
Of course, we all want to see Mozilla bootstrap their own Matrix instance, but maybe the cost/benefit equation worked out differently for them than we would have expected. I can imagine this lets them replace IRC with a better solution faster while still supporting the development of an open standard by becoming a client of the company that's developing it.
Does this forebode something more sinister? I hope not...
Of course, we all want to see Mozilla bootstrap their own Matrix instance, but maybe the cost/benefit equation worked out differently for them than we would have expected. I can imagine this lets them replace IRC with a better solution faster while still supporting the development of an open standard by becoming a client of the company that's developing it.
Does this forebode something more sinister? I hope not...
Is Mozilla an example for the next major adopter of Matrix or are they not? If they are, and everyone else signs up for modular.im as well: at what point does this ship of Theseus called Federation only exist inside a bottle?
If it were me, I would want to a) support the existing players in the ecosystem and b) do the migration piecemeal if possible.
Working with a third party lets them start standing up rooms immediately, and get their people using the new standard without being blocked on a long process of setting up their own infra. It’s federated. They can easily migrate onto their own hardware at a later date.
It also injects money into the community they are trying to support. Even if they did start running all of their own instances, I would hope they keep a support contract with Modular for that reason.
Paying Modular + using Matrix widely immediately + beginning work on their own infrastructure is a strictly bigger shot in the arm for Matrix than just putting a couple devs on pre-planning and prototyping infra would be.
Working with a third party lets them start standing up rooms immediately, and get their people using the new standard without being blocked on a long process of setting up their own infra. It’s federated. They can easily migrate onto their own hardware at a later date.
It also injects money into the community they are trying to support. Even if they did start running all of their own instances, I would hope they keep a support contract with Modular for that reason.
Paying Modular + using Matrix widely immediately + beginning work on their own infrastructure is a strictly bigger shot in the arm for Matrix than just putting a couple devs on pre-planning and prototyping infra would be.
WordPress exists as as OSS even though WordPress.com exists. And there's a clear migration path from being hosted by WordPress.com to running your own private WordPress.org instance (or vice-versa), that can be taken at any time if someone's needs change. I don't see what's so different here.
If Mozilla will use their own domain name they will be free to move their federated Matrix instance wherever they want. Modular.im will only provide the hosting expertise. I expect that in the future self-hosting your own Matrix server instance will become much easier.
Mozilla will no doubt use their own domain name, and would have the option to go self hosted if they wish to.
Moving synapse databases around isn't too difficult, and certainly Modular.im would be able to provide the data on request.
Moving synapse databases around isn't too difficult, and certainly Modular.im would be able to provide the data on request.
It can be a bit onerous, half the convo in our matrix room is about updating matrix.
I don’t have experience with running Synapse but it looks like a beast. Dendrite and Ruma look very promising though; can’t wait to have a lightweight home-server ready for prime-time.
Assuming the purpose of the messaging system selected is to help Mozilla's community work together on Mozilla projects, what benefit of 'decentralization' do you think would improve their ability to work together effectively?
Work together to what end? If the goal is a vibrant internet where large players are not in control, supporting decentralization is important.
I encourage reading the earlier posts on HN from exple.tive.org about this over the past year, as I think they may speak more to the reasoning you’re interested in discussing.
What benefits would Mozilla get from running their own server and federation (that they have with ircd today)?
Good publicity for decentralization. If they can get it to work, it shows that it’s possible to run a large instance from a non-central host.
Federation and decentralization are two different properties with different tradeoffs.
Well, sure it's possible. They don't need to prove it.
But I don't think Mozilla has such a large userbase that it would make any difference.
I like the publicity angle but maybe that's for the future. If Mozilla validates the transition and wants to get more involved with Matrix.org then it'd make sense to own and manage their own stuff.
I like that they are being cautious and not jumping with both feet in.
But I don't think Mozilla has such a large userbase that it would make any difference.
I like the publicity angle but maybe that's for the future. If Mozilla validates the transition and wants to get more involved with Matrix.org then it'd make sense to own and manage their own stuff.
I like that they are being cautious and not jumping with both feet in.
At a technical level, the Mozilla homeserver will be as decentralised as any other server in Matrix: i.e. entirely independent, and federating with the rest of the Matrix as normal.
At a legal level, it's true that the server will be admined by New Vector via Modular.im - but this is basically Mozilla just outsourcing their sysadmin to Modular, while also helping fund Matrix development (given that Modular subscriptions are used to fund development on Synapse and Matrix in general).
At a legal level, it's true that the server will be admined by New Vector via Modular.im - but this is basically Mozilla just outsourcing their sysadmin to Modular, while also helping fund Matrix development (given that Modular subscriptions are used to fund development on Synapse and Matrix in general).
That sounds like a benefit for Matrix, but it's not obvious why Mozilla would want to spend time and money on that?
It also keeps their failures untethered to that of a centralized network.
Matrix servers are kinda a pain in the ass to get up-and-running and to manage versus, say, XMPP or IRC. Especially if you can't get away with just running someone else's pre-built docker images for it, or whatever.
I've administered both XMPP and Matrix servers and I must say I don't see either as much of a hassle. Synapse had some growing pains but is pretty painless for me these days.
Not true in my experience. Synapse is just as easy to stand up as Prosody, and in fact requires making less choices since you don't have to pick which modules to enable and stuff.
Can you tell me more about the modular.im behaviour/policy towards federation? Is it explicitly turned off?
Also, IRC has federation too by having multiple servers in a network. IIRC Mozilla hadn't allowed you to do this for moznet did they? So how is this different?
Also, IRC has federation too by having multiple servers in a network. IIRC Mozilla hadn't allowed you to do this for moznet did they? So how is this different?
To be clear: the server will be publicly federated. All modular.im servers federate by default unless you explicitly turn it off.
Let's hope they do both: Cash + Development.
Might as well ask, right?
Might as well ask, right?
Nice, given how the discussions were going some months ago I was worried that they would pick some closed source solution like Discord or Slack. I have not used Matrix so I do not know how good it is, but I do not like the lock-in of Discord and Slack.
Matrix can bridge in IRC, Slack, Gitter and a few other protocols very nicely, it reminds me of Pidgin but with much better UX.
I haven't managed to properly use Matrix myself, but I am part of a number of Gitter rooms that includes people using the Matrix bridge. I certainly wouldn't call that bridge "nice": all their messages are posted by a single user called matrixbot, that simply prefixes it message by their Matrix username in backticks. I'm not sure if the people in the room who aren't aware of Matrix understand that that's what's going on.
Agreed, this is a huge relief. I was getting quite worried that Mozilla would go to Discord, like Rust and other projects have done. I don't know anything about Matrix, but I know it's free, and if it has Mozilla's endorsement, now I'm actually curious to try it... maybe even via an IRC bridge!
FYI #rust-beginners is on discord, but many of the teams have transitioned to Zulip because it has threads. I'd love if Zulip was OSS, but at least it's a highly innovative company that's improved a lot on the UX of IRC (far beyond not needing to setup a bouncer).
The mismatch between Discord's targeted audience of gamers can get funny at times. One rust dev has had their status we to "playing systemd" for days.
Edit: How did I miss that Zulip is open source??? Thank you to the commentators who pointed this out, you made my day :)
Edit2: Just learned what I said about rust decision-making was totally wrong. Thanks to Rob Pike in the other thread for his detailed comments.
The mismatch between Discord's targeted audience of gamers can get funny at times. One rust dev has had their status we to "playing systemd" for days.
Edit: How did I miss that Zulip is open source??? Thank you to the commentators who pointed this out, you made my day :)
Edit2: Just learned what I said about rust decision-making was totally wrong. Thanks to Rob Pike in the other thread for his detailed comments.
You're talking about https://github.com/zulip/zulip, right? It was open sourced in 2015.
I wouldn't describe Zulip as coming from the IRC tradition -- it was built by MIT students as an improvement on MIT's Zephyr. There's a split between line-at-a-time messaging like IRC or Slack, and paragraphs-at-a-time messaging with per-message channels like Zephyr, Gale, and now Zulip.
I really miss the paragraphs style.
I really miss the paragraphs style.
Wait, why can't you type a paragraph at a time in IRC?
I said "paragraphs-at-a-time", not "paragraph-at-a-time". You can't type paragraphs at a time on IRC because a single message can't contain newlines.
But even then, paragraph-at-a-time is hard on IRC because there's a max line length that's surprisingly short (and usually just truncates the rest of your message once you exceed it!), and just because you'd stand out as being the person writing much more than everyone else and being slow to reply. IRC simply isn't a medium designed for carefully considered thought like that.
But even then, paragraph-at-a-time is hard on IRC because there's a max line length that's surprisingly short (and usually just truncates the rest of your message once you exceed it!), and just because you'd stand out as being the person writing much more than everyone else and being slow to reply. IRC simply isn't a medium designed for carefully considered thought like that.
> a medium designed for carefully considered thought like that.
"Sorry this is so long. I didn't have time to make it shorter."
"Sorry this is so long. I didn't have time to make it shorter."
You can type a paragraph if it is not too long, but you can't write several paragraphs.
Zulip is open source: https://github.com/zulip/zulip
[deleted]
Where’s the other thread with Rob Pike?
There isn't one, because ... I'm not even sure what I was thinking, except that I probably should have gotten a few more hours of sleep last night.
Maybe I was thinking about this comment by someone else when I wrote that???: https://news.ycombinator.com/user?id=kibwen
Maybe I was thinking about this comment by someone else when I wrote that???: https://news.ycombinator.com/user?id=kibwen
> I was getting quite worried that Mozilla would go to Discord, like Rust and other projects have done.
Just so you know, the Rust Embedded guys went with Matrix back in June and several people do use the IRC bridge.
https://github.com/rust-embedded/wg/issues/357
Just so you know, the Rust Embedded guys went with Matrix back in June and several people do use the IRC bridge.
https://github.com/rust-embedded/wg/issues/357
Congrats to Riot/Matrix.
I'm hoping with Mozilla's backing the product, there's a lot of features that get built out.
There's no reason this cant be a Slack-beating product now.
I'm betting a Rust based homeserver replacing Synapse.
I'm hoping with Mozilla's backing the product, there's a lot of features that get built out.
There's no reason this cant be a Slack-beating product now.
I'm betting a Rust based homeserver replacing Synapse.
The official successor to Synapse homeserver is Dendrite written in Go (https://github.com/matrix-org/dendrite). There is homeserver project in Rust called Ruma (https://github.com/ruma/ruma). Ruma was waiting for async/await to stabilize. But it doesn't seem to have much activity even after that.
It looks like Ruma was waiting for an async web framework to emerge, and the web frameworks were waiting on hyper to upgrade, and hyper was waiting on h2 to upgrade, and h2 was waiting on http to upgrade, and http was waiting on bytes to upgrade, and everyone was waiting on tokio to upgrade. In the six weeks since async await has stabilized, the web framework that my company uses has only just managed to upgrade to stable async/await last week. I wouldn't fault Ruma for waiting for other frameworks to upgrade before making a choice.
Thank you for that perspective. I apologize if it sounded like I am blaming Ruma - just waiting eagerly for its development.
No problem. :) I just don't want potential contributors to write off Ruma as something worth looking at, especially since with this announcement it ought to be be more relevant than ever. And having multiple independent implementations of a federated protocol is very important to proving out the specification (the Ruma author has already filed several bugs against the spec as a result of implementing it).
No longer true.
To quote the founder:
There are quite a lot of Synapses out there right now, and Synapse's featureset is pretty mature. Given we have pretty high profile people running Synapse (e.g. all of the French government) we have no choice but to invest the time to polish it and make it more efficient and stable. In an ideal world we'd have paused on Synapse ages ago and focused purely on a next-gen server, but we can't leave Synapse users in the lurch. Dendrite will be getting some attention in the coming months though, but not as a direct Synapse-replacement, but more of a playground for more experimental stuff.
https://news.ycombinator.com/item?id=21767057
To quote the founder:
There are quite a lot of Synapses out there right now, and Synapse's featureset is pretty mature. Given we have pretty high profile people running Synapse (e.g. all of the French government) we have no choice but to invest the time to polish it and make it more efficient and stable. In an ideal world we'd have paused on Synapse ages ago and focused purely on a next-gen server, but we can't leave Synapse users in the lurch. Dendrite will be getting some attention in the coming months though, but not as a direct Synapse-replacement, but more of a playground for more experimental stuff.
https://news.ycombinator.com/item?id=21767057
From two Matrix members, one who is the matrix.org team lead today:
https://news.ycombinator.com/item?id=21836684
https://news.ycombinator.com/item?id=21836684
Two new full-time employees were hired to work on Dendrite (written in Go) and p2p matrix?
Interesting. I had the impression that the Rust version would have priority.
Interesting. I had the impression that the Rust version would have priority.
Ruma isn't written by the core matrix.org team, and has its own community. Dendrite is much further along, so makes sense for us to hack on the projects we created :)
New Vector (https://www.vector.im/) is hiring more designers to come work fulltime on Riot’s UI and UX as they shift Riot’s focus from being developer-led to design-led.
That's great news!
https://apply.workable.com/new-vector/j/6CB817C79E/
That's great news!
https://apply.workable.com/new-vector/j/6CB817C79E/
Fantastic, though I wish they weren't burdened with such a bad name. I wonder if they would ever change it...
Can't wait for Mozilla to back a stable, native desktop client into a daily driver state so we can finally ditch Mattermost at work.
[deleted]
Seriously, I feel like it’s such an indictment on native app tool development that we have a bazillion new electron apps written by ppl all the time for weekend projects yet almost no one spitting out native apps to interface with services.
It’s clearly in demand (if a bit of a niche kind of demand)
It’s clearly in demand (if a bit of a niche kind of demand)
There are a bunch of very promising native desktop Matrix clients in progress:
https://github.com/Nheko-Reborn/nheko as a Qt telegram-like
https://github.com/quotient-im/Quaternion as a Qt xchat-like
https://github.com/manuroe/messagerie for instance is a SwiftUI client proof-of-concept that should work on macOS as well as iOS
None are as polished as Riot functionalitywise, but we will get there eventually - even more so if people contribute.
https://github.com/Nheko-Reborn/nheko as a Qt telegram-like
https://github.com/quotient-im/Quaternion as a Qt xchat-like
https://github.com/manuroe/messagerie for instance is a SwiftUI client proof-of-concept that should work on macOS as well as iOS
None are as polished as Riot functionalitywise, but we will get there eventually - even more so if people contribute.
Spectral is quite usable as well in my experience (At-based) https://spectral.encom.eu.org/
Fractal is the GTK counterpart https://wiki.gnome.org/Apps/Fractal
Thunderbird also has a Matrix back-end, though XUL is quite close to electron.
Lots of other clients https://matrix.org/clients/
Fractal is the GTK counterpart https://wiki.gnome.org/Apps/Fractal
Thunderbird also has a Matrix back-end, though XUL is quite close to electron.
Lots of other clients https://matrix.org/clients/
I wonder if there's one for emacs.
That's what I'd like to see.
That's what I'd like to see.
There's the weechat terminal client.
You answered your own question.
You can write a pretty and functional Electron app in a weekend.
To implement the same level of functionality and prettiness in a native app toolkit like Qt is at least a month of work.
It's the same story as Python versus C, or C versus Assembly.
When C was introduced, the old-timers had the same complains like we do today: why would you program in such a slow and inefficient language? Real programmers (TM) use Assembly, C is for lazy people who don't want to learn and who don't care about the awful resource wasting. 3 KB for a hello world? That's an absolutely ridiculous level of bloat.
You can write a pretty and functional Electron app in a weekend.
To implement the same level of functionality and prettiness in a native app toolkit like Qt is at least a month of work.
It's the same story as Python versus C, or C versus Assembly.
When C was introduced, the old-timers had the same complains like we do today: why would you program in such a slow and inefficient language? Real programmers (TM) use Assembly, C is for lazy people who don't want to learn and who don't care about the awful resource wasting. 3 KB for a hello world? That's an absolutely ridiculous level of bloat.
> You can write a pretty and functional Electron app in a weekend.
You can also do so in Qt and other frameworks.
The fact that you are proficient in web frameworks does not mean other tools are less productive.
In fact, being proficient in modern web dev, including HTML, CSS, JS, TS, React, etc. takes way longer than learning something like Qt. And if you go to easier frameworks like Delphi or VB6, you would be amazed at the productivity speed.
You can also do so in Qt and other frameworks.
The fact that you are proficient in web frameworks does not mean other tools are less productive.
In fact, being proficient in modern web dev, including HTML, CSS, JS, TS, React, etc. takes way longer than learning something like Qt. And if you go to easier frameworks like Delphi or VB6, you would be amazed at the productivity speed.
"In fact, being proficient in modern web dev, including HTML, CSS, JS, TS, React, etc. takes way longer than learning something like Qt."
But there are already a ton of web developers who already know those web development technologies, but don't know Qt. So it would be extra effort for them to learn Qt. Much easier to just use React.
The same thing goes for why there so many academics write Java apps for their proof-of-concept research work. That's what they're taught in school and for many that's all they know.
Curiously, Python was able to make huge inroads in to the academic community, but that was largely due to having a killer app (Jupyter notebooks) along with having a bunch of desirable tools for scientific computing, data processing, and visualization. I'm not sure if there's anything as compelling in the Qt ecosystem that would be as attractive to web developers who already know HTML, Javascript, React, etc.
But there are already a ton of web developers who already know those web development technologies, but don't know Qt. So it would be extra effort for them to learn Qt. Much easier to just use React.
The same thing goes for why there so many academics write Java apps for their proof-of-concept research work. That's what they're taught in school and for many that's all they know.
Curiously, Python was able to make huge inroads in to the academic community, but that was largely due to having a killer app (Jupyter notebooks) along with having a bunch of desirable tools for scientific computing, data processing, and visualization. I'm not sure if there's anything as compelling in the Qt ecosystem that would be as attractive to web developers who already know HTML, Javascript, React, etc.
I still find WinForms to be a very productive and pleasant way to write native Windows apps, even quick weekend MVP’s.
Yes, it’s Windows only, but if you really want tight efficient native apps then you’ll want a custom built app for each platform anyway, with a nice standardized API for them to connect to. So I don’t see the Windows platform lock-in as a downside if the goal is good native performance.
Yes, it’s Windows only, but if you really want tight efficient native apps then you’ll want a custom built app for each platform anyway, with a nice standardized API for them to connect to. So I don’t see the Windows platform lock-in as a downside if the goal is good native performance.
> To implement the same level of functionality and prettiness in a native app toolkit like Qt is at least a month of work.
That's really only true for web developers trying to make native apps, and only because they're used to the mess that is web development.
It's a piece of cake to build a small app in Qt with C++, and it's even easier using Python or Common Lisp or one of the other language bindings.
Like everything, it depends on each developer's experience which one is easier for them.
That's really only true for web developers trying to make native apps, and only because they're used to the mess that is web development.
It's a piece of cake to build a small app in Qt with C++, and it's even easier using Python or Common Lisp or one of the other language bindings.
Like everything, it depends on each developer's experience which one is easier for them.
> To implement the same level of functionality and prettiness in a native app toolkit like Qt is at least a month of work.
Qt is not native in the way that matters: using platform widgets. In fact, the choice of language really doesn't matter if you're using them right: if you have a platform-to-language bridge and it works, generally the end product is not too bad.
Qt is not native in the way that matters: using platform widgets. In fact, the choice of language really doesn't matter if you're using them right: if you have a platform-to-language bridge and it works, generally the end product is not too bad.
This is not at all the same thing. Programs written in C aren't inherently low-quality, everything abusing the web stack as an application platform – including Electron – is.
If you had said low performance, you would have had a point. Even then, someone else could say that programs based on Electron at least aren't inherently insecure, like programs written in C are.
Don't get that optimistic about Electron apps security
If Electron vs Qt/C++ were the only two choices that would be true. In reality there are lots of ways to write cross platform native apps without using C or C++: Gtk + scripting language of your choice (even Javascript); Tcl/Tk; WxWindows; Mono/C#; lots of Java options; Delphi/Lazarus.
Isn’t NW.js way better than Electron?
And they have a robust ecosystem
https://hackernoon.com/why-i-prefer-nw-js-over-electron-2018...
https://github.com/nwjs/nw.js
And they have a robust ecosystem
https://hackernoon.com/why-i-prefer-nw-js-over-electron-2018...
https://github.com/nwjs/nw.js
Native development on OSX and iOS both kind of suck unless you completely embrace objective C and coaca. I think that’s what’s turned so many people off to it.
It’s comparatively easy to write complex portable applications with tk (or even just strait win32 and whichever X11 widget toolkit is your favorite.)
It’s comparatively easy to write complex portable applications with tk (or even just strait win32 and whichever X11 widget toolkit is your favorite.)
https://github.com/neilalexander/seaglass looks promising.
That’s exactly what I’m talking about; you can’t reuse code on OSX and more or less have to start from scratch.
> Native development on OSX and iOS both kind of suck unless you completely embrace objective C and coaca.
You can try all-Swift development with SwiftUI.
You can try all-Swift development with SwiftUI.
Well yeah that gives you an OS X app and you get to reimplement it completely from scratch for all the other platforms. So it’s exactly the same problem as objective C (except you can at least compile objective C on other platforms you just don’t get the GUI stuff.)
[deleted]
[deleted]
At least some people try to work on that issue:
https://www.outrunlabs.com/revery/
https://www.outrunlabs.com/revery/
Has anyone had experience with both Matrix and Mattermost? What are the main differences between the two?
Apropos of nothing, currently I am running:
Apropos of nothing, currently I am running:
* Signal
* Wife
* Family
* Google Hangouts (web)
* Friends and ex-coworkers
* Slack
* Vendor A
* Vendor B
* Team C
* Team D
* Keybase
* Some friends
* SMS
* My Stepdaughter
* Skype
* Coworkers too stubborn to open Mattermost or change what they do
* Mattermost
* Coworkers
* Various teams and groups
* Remote Desktop
* Microsoft Teams
* My team
* Client coworkers
* Other teams at client
* Microsoft Skype for Business
* Chats from people who don't use MS Teams
* Meetings
* Gitter
* Spacemacs chat
* IRC (web)
* Various random channels
Mattermost is currently a better UX with a more stable codebase, but I suspect that the Matrix/Riot federated model will one day overtake Mattermost.
Personally I use Mattermost at work and Matrix/Riot for personal chat. If Matrix/Riot began to overtake Mattermost in terms of UX, we would probably replace Mattermost with Matrix/Riot at work.
Personally I use Mattermost at work and Matrix/Riot for personal chat. If Matrix/Riot began to overtake Mattermost in terms of UX, we would probably replace Mattermost with Matrix/Riot at work.
Thank you!
You've just described my nightmare scenario. I'm currently experiencing "Messaging app fatigue" and I'm not using even a quarter of the apps that you are.
Yes, fatigue is a great word for it.
My list isn't quite that long, but I'm using Franz to put most of them into a single window (albeit, with many tabs).
Sadly, it doesn't work with iMessage, nor Signal.
I just wish it was a native app, although I appreciate that'd make the effort involved 100x more.
Sadly, it doesn't work with iMessage, nor Signal.
I just wish it was a native app, although I appreciate that'd make the effort involved 100x more.
I really wish Telepathy took off, then you could have one single app that speaks each of those protocols and talks to the relevant servers.
https://telepathy.freedesktop.org/
https://telepathy.freedesktop.org/
I use SMS, Slack, Discord, Skype, IRC, Google Hangouts, Facebook Messenger and WhatsApp, so you have me beat by 3. :) It would be amazing of Matrix and its bridges got good enough so I could reduce this number a bit.
This screenshot https://discourse-prod-uploads-81679984178418.s3.dualstack.u... shows a UI that seems way wore easier to grip than the riot UI. I remember screenshots https://img.bfmtv.com/c/840/625/06e8/68cd7316f6a279a3899fcf8... http://www.tchap.fr/wp-content/uploads/2019/05/interface-tch... of the client used set up by the France efforts.
Are those clients ever going to be released to the general public ?
Are those clients ever going to be released to the general public ?
the first image is Riot circa 2015 (back when it was called Vector). You can run it if you really want from https://riots.im.
Tchap meanwhile is opensource at https://github.com/dinsic-pim and there are unofficial builds which let you use it as a general purpose Matrix client.
However, we're busy improving Riot's UX in general to make it easier to grip - on Mobile that ends up being a rewrite (RiotX), on Web we're iterating incrementally.
Tchap meanwhile is opensource at https://github.com/dinsic-pim and there are unofficial builds which let you use it as a general purpose Matrix client.
However, we're busy improving Riot's UX in general to make it easier to grip - on Mobile that ends up being a rewrite (RiotX), on Web we're iterating incrementally.
Ah, cool ! I am off to installing tchap then.
Really glad to hear you are upgrading the game on the front-end/UX/UI !
edit: well, I give up :D. Been playing for 40 minutes with yarn build/dist and config.json and missing olm and async_hooks dependencies.
Really glad to hear you are upgrading the game on the front-end/UX/UI !
edit: well, I give up :D. Been playing for 40 minutes with yarn build/dist and config.json and missing olm and async_hooks dependencies.
Congrats to Mozilla and matrix.org! I am at least very happy they went with a FOSS solution.
> effectively using Matrix as a big decentralised IRC bouncer in the sky.
No. In theory it is, but in practice it's a big centralized IRC bouncer in the sky where everyone is reliant on riot.im servers.
No. In theory it is, but in practice it's a big centralized IRC bouncer in the sky where everyone is reliant on riot.im servers.
Not really: anyone can run an IRC bridge, and many people do. The #mozilla_#wherever:matrix.org namespace is the preexisting moznet bridge run by Matrix.org (not Riot.im), but anyone with their own server could also run their own bridge, much like they could run their own bouncer today. There is then additional decentralisation from the fact that the room history is replicated throughout all the participating Matrix servers.
Anyone can, few do. At least in terms of what I see on the 20 IRC networks I'm connected to. The only one where people actually tend to run their own Matrix servers is on OFTC with the Freedombox (https://wiki.debian.org/FreedomBox) people. On Freenode I don't think I have ever seen someone connect from a Matrix server that wasn't riot.im since the creation of the Matrix protocol.
How would you even know, though? When running personal bridges I just have them auth as my normal user account like a bouncer. Or are you looking at CTCP versions?
The 'Real Name' field shows where they're proxying in from. Like the normal riot.im "@username:matrix.org" or self-hosted "@username:theirserver.address.tld". Is this an option that isn't the default for most matrix bridges/clients/whatever?
I guess if it doesn't show in their realname field I wouldn't see it. But I imagine since the defaults seems to be what I described above the amount of users that turned that off will be fairly small and irrelevant.
I guess if it doesn't show in their realname field I wouldn't see it. But I imagine since the defaults seems to be what I described above the amount of users that turned that off will be fairly small and irrelevant.
And them Matrix will happily spam IRC with links to comments instead of the comments themselves.
Matrix is toxic to IRC.
Any widely used IRC channel that has matrix joined to it would do well to ban matrix if they want the channel to pratically continue to exist as a IRC channel.
Matrix is toxic to IRC.
Any widely used IRC channel that has matrix joined to it would do well to ban matrix if they want the channel to pratically continue to exist as a IRC channel.
The default heuristic is that if someone sends a message on Matrix which is longer than 3 lines, it gets sent as a pastebin to IRC. This feels significantly better than spamming an N-line paste into IRC, which could be seen as even more toxic.
Open to suggestions on how to improve it, though...
Open to suggestions on how to improve it, though...
> Open to suggestions on how to improve it, though...
I for one would really like code blocks formatting & syntax highlight in the linked text, maybe even show all formatting :)
I for one would really like code blocks formatting & syntax highlight in the linked text, maybe even show all formatting :)
If someone sends an overly long message and it irritates people, they'll get asked to not do that in the future.
Do you also plan to replace offensive words in messages?
Forcing people to load a URL to a remote server to see a message is one of the most hostile things I've _ever_ seen an attempt at IRC integration do.
Do you also plan to replace offensive words in messages?
Forcing people to load a URL to a remote server to see a message is one of the most hostile things I've _ever_ seen an attempt at IRC integration do.
I'm curious, what's wrong with IRC? Is it too old? Too difficult to monitor and moderate? Too easy to spam? I don't understand.
I've never really understood why mozilla chose their own servers and not freenode. I've never really grasped the whole history of enet vs freenode either.
I've never really understood why mozilla chose their own servers and not freenode. I've never really grasped the whole history of enet vs freenode either.
Mozilla has said they thought it was too difficult to monitor and moderate. Could that have been solved by moving to Freenode? Probably, but there are other issues with IRC.
Having to run your own IRC bouncer increases the barrier of entry, as does nickserv based auth. Modern people also expect to be able to seamlessly post images, large code examples, files, etc. Some people also want support for threaded conversations. None of this is offered by the typical IRC setup which Mozilla probably thinks that it scares away users. I do not think Matrix solves all of these yet, but it solves some of them.
Having to run your own IRC bouncer increases the barrier of entry, as does nickserv based auth. Modern people also expect to be able to seamlessly post images, large code examples, files, etc. Some people also want support for threaded conversations. None of this is offered by the typical IRC setup which Mozilla probably thinks that it scares away users. I do not think Matrix solves all of these yet, but it solves some of them.
How is the feature parity with newer alternatives? Can I share my screen with someone easily? Can I post a screenshot? Can I be sure every client shows the screenshot properly? Will it handle an animated screenshot?
I wouldn’t want to use one tool for typing text and another for calling a third for sharing files and a fourth for sharing a screen and so on.
For example: Sharing an image as a link isn’t really an acceptable UX these days I think.
I wouldn’t want to use one tool for typing text and another for calling a third for sharing files and a fourth for sharing a screen and so on.
For example: Sharing an image as a link isn’t really an acceptable UX these days I think.
A lot of younger developers consider IRC limited and crusty. They are more easily attracted to platforms they've grown used to that behave similar to discord, teams, and slack.
> I'm curious, what's wrong with IRC?
It seems that the most significant complaint is bad mobile experience.
It seems that the most significant complaint is bad mobile experience.
I've always asked this question : Can't we make better IRC clients yet, more Slack like, but just works over traditional IRC?
Yes.
See https://ircv3.net/.
An example: https://blog.irccloud.com/slack-integration/
See https://ircv3.net/.
An example: https://blog.irccloud.com/slack-integration/
Is there a low-friction way to give Matrix a try? Like a Hacker News channel that you can join with a web client or something?
Riot is a popular Matrix client and a good place to start., pointing your browser at https://riot.im/app/#/welcome
I'm unaware of a hacker news matrix channel (perhaps others can enlighten me), but joining the Matrix HQ channel (https://riot.im/app/#/room/#matrix:matrix.org) is a good place to learn more about Matrix.
I'm unaware of a hacker news matrix channel (perhaps others can enlighten me), but joining the Matrix HQ channel (https://riot.im/app/#/room/#matrix:matrix.org) is a good place to learn more about Matrix.
There's https://riot.im/app/#/room/#hn:matrix.org, but it's sadly very dead and not bridged anywhere useful. Is there actually a good chat community for HN anywhere?
https://riot.im/app/ You need to register an account but you can log into many public channels.
Any one knows the progress of dendrite? Have not used matrix/riot for a while. It was too heavy to run awhile back. Hopefully they make the client and server more light weight.
Riot should be way lighter these days, at least on web. We reduced RAM by 5x by lazyloading about a year ago.
We've just hired a new full-time employee to work on Dendrite and p2p matrix. Expect rapid progress on Dendrite as of a few days ago.
https://github.com/matrix-org/dendrite
https://github.com/matrix-org/dendrite
(two new employees actually ;P)
Are you guys planning "private communities" usecases ?
When I last evaluated Riot, it was vehemently public...so Slack/Mattermost like usecases were very hard to do.
Ideally a private community should be possible, where users invited to that community have access to all channels. however within the community, I should have private channels restricted to only few invited users.
I was told that the only possible way to do this was make all channels of a community private ..and when adding a new user, you should explicitly invite to every single one of the channels. This is not viable for an org.
I really hope this has changed.
When I last evaluated Riot, it was vehemently public...so Slack/Mattermost like usecases were very hard to do.
Ideally a private community should be possible, where users invited to that community have access to all channels. however within the community, I should have private channels restricted to only few invited users.
I was told that the only possible way to do this was make all channels of a community private ..and when adding a new user, you should explicitly invite to every single one of the channels. This is not viable for an org.
I really hope this has changed.
AFAIK it is planned but not done
I really hope this means more development and focus on building great mobile apps for Matrix. For the past four months the Riot Android app has had this bug where login state expires after a day and the app gets stuck in an infinite loop trying to refresh the token. Supposedly a fix was merged [1], but after four months of not being able to use Riot (and thus Matrix) my friend group has fallen back to Discord.
[1] https://github.com/vector-im/riot-android/issues/3249
[1] https://github.com/vector-im/riot-android/issues/3249
Have you tried RiotX https://play.google.com/store/apps/details?id=im.vector.riot...
Most efforts are going to this new android client. The issue you refer to has been properly handled on RiotX (soft logout)
I don't think this issue is related to soft logout, which is what happens when the user logs out of a device remotely. The issue I was running into was that the app, after 24 hours of being logged in, would get stuck in an initialization loop.
Sry, to be more precise, token invalidation has been properly handled in riotX as part of the soft logout feature;
Oh, awesome! I just installed Riot 0.9.9, so I'm going to test that out and see if the issue occurs. After that I'll switch to RiotX and check there as well and report any issues I find.
Are there any other projects using this setup? Also, any write up on the compelling reasons to switch? Are they hoping this move will attract more contributors? Article is unclear.
Compelling reasons to switch: it's an open standard, it's federated (so you can own your own server and avoid vendor lock-in), it has end-to-end encryption, it supports bridging with many other protocols, there's quite a growing ecosystem of tools and libraries around it, etc.
The protocol itself is designed to be really flexible in the kind of data you can send through it (and therefore automatically propagated to and synchronized with other servers) so it can support a lot of different use cases. This includes standard chat app things like audio/video calls but it could also be used for stuff like forums or even serve as a backend for syncing information between organization (I'm thinking of things like medical information between health institutions).
All in all, there's a lot of potential in Matrix.
The protocol itself is designed to be really flexible in the kind of data you can send through it (and therefore automatically propagated to and synchronized with other servers) so it can support a lot of different use cases. This includes standard chat app things like audio/video calls but it could also be used for stuff like forums or even serve as a backend for syncing information between organization (I'm thinking of things like medical information between health institutions).
All in all, there's a lot of potential in Matrix.
I try matrix on occasion (as in, I set up my own server from scratch). The last time I tried it, support for multi-participant audio and video calls (and screensharing) was still between terrible and nonexistant. Definitely much worse than Discord. Has it improved?
There were some bug fixes in the last year (IIRC) though nothing very substantial, I think. Then again, it's always worked reasonably well for me and I'm using it regularly. I heard it was going to get worked on soon, though.
There was a major upgrade to the conference calling about 6 months ago which took it from being "barely usable" to "almost as good as Zoom". It's different semantics to Discord in that it's classic conferencing rather than a voice channel, but it works well enough for the whole core Matrix team to use it basically constantly for remote collaboration.
The conferencing servers are currently in London however, so you may suffer from transatlantic traffic problems if you are elsewhere in the world.
The conferencing servers are currently in London however, so you may suffer from transatlantic traffic problems if you are elsewhere in the world.
Ah, thank you for the additional information. Is my grapevine information correct that more work will be done to improve video calls and screensharing in the coming months?
As an example of what could be improved, I do still encounter the occasional bug with call synchronization, the video stream of one of the sides not getting started on occasion and screensharing is hardly discoverable.
As an example of what could be improved, I do still encounter the occasional bug with call synchronization, the video stream of one of the sides not getting started on occasion and screensharing is hardly discoverable.
Good to know!
For background, see http://exple.tive.org/blarg/2019/04/26/synchronous-text/
[deleted]
Write up of reasons at this morning’s other FP here: https://news.ycombinator.com/item?id=21835749
> Are there any other projects using this setup?
GNOME and KDE are also using Matrix.
GNOME and KDE are also using Matrix.
I'm confused. Is Matrix actually synchronous or asynchronous? The Matrix FAQ (https://matrix.org/faq/#what-is-a-homeserver%3F) makes it sound like it can be asynchronous. Otherwise, why store communication history at all?
Matrix is asynchronous. You send a message into a room; other people can receive it later or respond to it subsequently - it's not like the data blocks the room somehow until it's read, or that messages disappear after reading.
Good, but what about Rust project jumping to Discord instead? They should have used Matrix as well.
Each individual Rust team (which govern individual aspects of Rust) got to choose where to jump to; I believe one did choose to use Matrix, but the others mostly chose Discord (because there was already a very large Rust user community there), a few chose Zulip, and one is still on IRC. If Matrix clients were more well-developed and widely-used, I believe there would be good incentive for them to transition--the Rust developers already have enough on their plate without feeling like they need to also develop their own communication protocol.
I still find it inappropriate for a FOSS project to promote closed non federated communication tools. Hopefully they won't be stuck with Discord because "we already switched to it".
I think they are just being pragmatic. No one, not even RMS, ever felt that open source needed to be open source from bottom to top, just the final product. You have to be pragmatic in this life. We can't wait for open source processors running on open source hardware on and open source OS compiled on an open source compiler before something gets released. I find it entirely appropriate for them to be pragmatic and use the tools to get done what they need to get done.
Yeah, that was a bummer for me.
Discord is admittedly awesome, but not in line with openness.
Discord is admittedly awesome, but not in line with openness.
Wow this already looks like a fractured mess! https://matrix.org/clients/ Why are there so many clients with different supported functionality?
It's called "freedom of choice". The alternative is for Facebook, GOSPLAN or Apple to decide what features and UI you get.
"Already"? Is that something that usually happens as a project matures?
Yes? See the fracturing of what HTML browsers supported in the 90s, or what happened to XMPP, for example.
HTML's middle ages were characterised by competing implementations of similar functionality. Inconsistency would be cause for concern, but incompleteness is expected.
Wait, are we complaining about one of the key advantages of open source now?
Is lots of half finished clients rather than one finished client an advantage?
Riot is pretty finished. So you have one fully-baked client, and a bunch of others to choose from if you don't like Riot.
Compare that to Slack, which only has one client, and it gets worse seemingly every day (somehow?).
Compare that to Slack, which only has one client, and it gets worse seemingly every day (somehow?).
[deleted]
Yes, the ability to create your own client certainly is. Everyone can implement their client as they see fit, as long as they stay compatible with the API. Naturally, you get many clients with different features.
Besides that, there is a reference implementation (Riot).
Besides that, there is a reference implementation (Riot).
Maybe if the one "finished" client doesn't work well for some users, e.g. is cumbersome to use with a screen reader, but there's a "half-finished" client that works well for them.
because it's an open protocol and that's how open protocols work
Presumably Matrix is the protocol and the clients implement that protocol. Some may be at a further stage of development than others.
Matrix advertises themselves as an eventually consistent global JSON DB. So it makes sense anyone can build a client and stuff something in there and maybe only their client really handles it.
Seems like a better idea given the failure of XMPP. XMPP was a communications protocol lots of products used like Google Talk, but got dumped when they wanted to do their own proprietary stuff. It feels like Matrix will be less likely to get dumped like that since they are just a general purpose global DB.
Seems like a better idea given the failure of XMPP. XMPP was a communications protocol lots of products used like Google Talk, but got dumped when they wanted to do their own proprietary stuff. It feels like Matrix will be less likely to get dumped like that since they are just a general purpose global DB.
> Why are there so many clients with different supported functionality?
If a client has different functionality from the spec, then it simply means that the client is unfinished.
It's not like XMPP where different servers/clients implement different XEPs.
A client either implements the spec and is complete or it does not and it is "beta".
If a client has different functionality from the spec, then it simply means that the client is unfinished.
It's not like XMPP where different servers/clients implement different XEPs.
A client either implements the spec and is complete or it does not and it is "beta".
That page could have (much) better UX - n.b. that it defaults to showing you only Linux clients; you have to click around to filter by other platforms. It also is outdated and misses many of the newer exciting clients such as http://dittochat.org/ or https://github.com/kiliankoe/nio. A more comprehensive view can be found at https://matrix.org/docs/projects/try-matrix-now/. Updating all this is on the todo list, but writing software >> writing website atm.
Matrix successfully competes with XMPP. It even features a more fractured mess with a lower number of clients in a shorter time span!
One big reason is that the core matrix protocol is incredibly simple to implement. With a good http library, it's a few lines of code to get a basic plaintext client going. However, there is a lot of surface area to cover. So that's how you end up with a lot of 1h/week projects that implement just what the single author cares most about.
> we have decided to replace IRC with Riot/Matrix, hosted by Modular.IM.
Looking at the pricing on modular.im[1] it starts at $10/month for up to 5 "active users," $73/m for up to 50, on and up..
Though modular's credentials look good, it seems like there'd be scope for some serious price gouging if Matrix had more takeup.
The standard (android) client's default servers are patchy enough to make this worth looking into, IME.
1: https://modular.im/services/matrix-hosting
Looking at the pricing on modular.im[1] it starts at $10/month for up to 5 "active users," $73/m for up to 50, on and up..
Though modular's credentials look good, it seems like there'd be scope for some serious price gouging if Matrix had more takeup.
The standard (android) client's default servers are patchy enough to make this worth looking into, IME.
1: https://modular.im/services/matrix-hosting
The announcement mentions only two features: safety and accessibility, but places no emphasis on the technical merits of the choice for the majority of users. That is disappointingly irrational for a technology organization.
I don't feel comfortable with the strong emphasis on "progressive" concerns that mozilla (and the rust community) have. It's not inclusive: I have normal liberal views (I'm from a European country and under 40) and I don't think I'd feel comfortable working for one of those organizations because I suspect the progressives there would be angry or offended with my reluctance to embrace the identity politics dogma. I didn't even feel comfortable posting this under my usual account, such is the atmosphere.
Accessibility is clearly important. But "safety" concerns have become overblown: reasonable concerns have become polluted by the politics of the "safe space" contingent, and the sorts of people that are closing down legitimate debate in the name of progressive/identity politics. And technical suitability for the 95% of modally-abled users is still an important consideration.
I don't feel comfortable with the strong emphasis on "progressive" concerns that mozilla (and the rust community) have. It's not inclusive: I have normal liberal views (I'm from a European country and under 40) and I don't think I'd feel comfortable working for one of those organizations because I suspect the progressives there would be angry or offended with my reluctance to embrace the identity politics dogma. I didn't even feel comfortable posting this under my usual account, such is the atmosphere.
Accessibility is clearly important. But "safety" concerns have become overblown: reasonable concerns have become polluted by the politics of the "safe space" contingent, and the sorts of people that are closing down legitimate debate in the name of progressive/identity politics. And technical suitability for the 95% of modally-abled users is still an important consideration.
Disclaimer: I work for Mozilla, and I was quite happy with IRC personally.
The announcement may not mention it, but there were trial instances of a number of messaging apps set up, people could use them and submit feedback, and that feedback was in fact considered as far as I know. Accessibility and safety were not the only criteria at all.
As far as "safety" concerns being overblown... I personally had approximately zero problems with IRC that way, though some of the random spammers who sounded like foul-mouthed 12-year-olds could be annoying at (rare, in my experience) times. But I absolutely have co-workers whose IRC experience was a lot less pleasant. And if moving to a different system lets us get rid of that unpleasantness for them, that is a _very_ strong reason to consider such a move, both on general moral grounds and on purely business-reasons "people who can get their work done sanely get more work done" efficiency grounds.
Note that we're not talking about safety from debate or opposing viewpoints or whatnot. We're talking about people being able to discuss a bugfix with others without being constantly spammed with invective and threats in the process. _That_ is what "safety" means in this context.
The announcement may not mention it, but there were trial instances of a number of messaging apps set up, people could use them and submit feedback, and that feedback was in fact considered as far as I know. Accessibility and safety were not the only criteria at all.
As far as "safety" concerns being overblown... I personally had approximately zero problems with IRC that way, though some of the random spammers who sounded like foul-mouthed 12-year-olds could be annoying at (rare, in my experience) times. But I absolutely have co-workers whose IRC experience was a lot less pleasant. And if moving to a different system lets us get rid of that unpleasantness for them, that is a _very_ strong reason to consider such a move, both on general moral grounds and on purely business-reasons "people who can get their work done sanely get more work done" efficiency grounds.
Note that we're not talking about safety from debate or opposing viewpoints or whatnot. We're talking about people being able to discuss a bugfix with others without being constantly spammed with invective and threats in the process. _That_ is what "safety" means in this context.
Accessibility was actually as far as I understand an argument in favor of staying on IRC (but also in favor of Matrix) since there are IRC clients which work very well with screenreaders (I think weechat for example). It is the proprietary solutions which have poor accessibility.
> technical suitability for the 95% of modally-abled users is still an important consideration.
Are you saying that we should give more advantages to people who already have the advantage of having no significant disability, while adding difficulty for people who already have extra difficulties (or at best making only token efforts toward accessibility)? That seems unreasonable to me.
Fortunately, with an open system like Matrix, everyone can have a client that works well for them.
Are you saying that we should give more advantages to people who already have the advantage of having no significant disability, while adding difficulty for people who already have extra difficulties (or at best making only token efforts toward accessibility)? That seems unreasonable to me.
Fortunately, with an open system like Matrix, everyone can have a client that works well for them.
Very excited for this; It's the one worthy successor to IRC.
Self plug: it also makes me more motivated to return to https://github.com/Ericson2314/matrix-client
Self plug: it also makes me more motivated to return to https://github.com/Ericson2314/matrix-client
IRC has the advantage of being usable without any specialized software (although the usability is not as well as if you do have specialized IRC software, it is still at least usable).
Which server does modular.im run? Synapse? Ruma?
In their hosted service description (https://modular.im/services/matrix-hosting#what-you-get), under the section Open Source, they mention Riot.im and Synapse.
synapse. ruma is pretty alpha, alas.
As a fan of the matrix protocol, this is great news to hear about Mozilla's decision!
Can I access the network from Emacs? I use ERC as of now.
yup. https://github.com/alphapapa/matrix-client.el is your best bet (it probably doesn't support SSO though, but should be pretty easy to add).
Thanks for sharing. Actually, I searched MELPA before posting my question. It is time to support this package to get included into MELPA/ELPA.
webboynews(2)
dzypa(7)