Live data from Hacker News

Synchronous Messaging at Mozilla: The Decision

discourse.mozilla.org

141–150 of 258 posts

Re: Synchronous Messaging at Mozilla: The Decision

#141

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

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…

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.

Re: Synchronous Messaging at Mozilla: The Decision

#142
post #28
post #5

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?

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.

Re: Synchronous Messaging at Mozilla: The Decision

#143
post #41
post #7

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.

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!

> 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

Re: Synchronous Messaging at Mozilla: The Decision

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

Re: Synchronous Messaging at Mozilla: The Decision

#146
post #142
post #28

Earlier quoted context omitted.

The last ruma commit was in August, which was after a long period where nothing happened at all. Is the project dead?

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.

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.

Re: Synchronous Messaging at Mozilla: The Decision

#148
post #142

Earlier quoted context omitted.

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.

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.

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.

Re: Synchronous Messaging at Mozilla: The Decision

#149

Earlier quoted context omitted.

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.

Wait, why can't you type a paragraph at a time in IRC?

You can type a paragraph if it is not too long, but you can't write several paragraphs.

Re: Synchronous Messaging at Mozilla: The Decision

#150

Wow this already looks like a fractured mess! https://matrix.org/clients/ Why are there so many clients with different supported functionality?

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?
Post reply on HN