Hacker News Reader

Comment by pmoriarty | Hacker News Reader

I haven't tried Matrix yet, but I've tried some other chat platforms like Telegram and Discord, and was really disappointed with them compared to IRC.

I had to use their closed-source, bloated, binary blob GUI clients, couldn't logs the channels I was in (and so relied on having to log in to their servers to get backlogs, which was super annoying), and needed invites to get in to channels.

Apart from the superior multimedia capabilities of these clients, I saw absolutely no advantage of them over IRC clients (which could do useful things like logs all mentioned URLs and mentions of my nick to separate, logged tabs, and which I could run from the terminal and even from within Emacs).

I really hope Matrix is better in this regard, and I'm trying to keep an open mind, but so far attempts to create next generation chat services have been really underwhelming.

View on HN

I find it compares favorably to IRC and XMPP. File transfers and offline messages and encryption "just working" without having to check if my client, other persons client and the server(s) support it (or having to bring helpers into the mix) is worth a lot.

Except you do have to check, as almost no clients support encryption fully.

using matrix via weechat using the new python weechat-matrix (https://github.com/poljar/weechat-matrix) plugin should give a very convincing IRC on steroids experience; it even has e2e encryption landing. The emacs matrix client (mclient.el) is also in active dev again.

Riot is also good, but probably too bloated for your tastes :)

It's a shame that the Matrix website listing clients[1] don't mention weechat-matrix and instead mentions the outdated Lua plugin[2] that doesn't support Megolm at all.

I've been using Riot for a few years and it's nice, but it would've been nice to know that there is a modern Weechat plugin implementation (I was half considering writing one myself).

It's also super neat to see that they wrote their own Python Matrix client library[3], which is something I also needed for another idea I'm working on (the library linked to from the Matrix site also seems to be less suitable than this one).

[1]: https://matrix.org/docs/projects/try-matrix-now [2]: https://github.com/torhve/weechat-matrix-protocol-script [3]: https://github.com/poljar/matrix-nio

Looking over the list of Matrix-related projects [0], what I'm finding a bit concerning is that only one of the server implementations (the official Synapse codebase) appears to be anywhere close to production-ready. All the others look like they're either abandoned experiments, or barely in early dev (Dendrite).

The feature blurbs and API specs make it sound relevant to a project I'll be working on, but I'm concerned that there's only one viable-ish server implementation. I'd feel a lot better if there were several valid working servers in various languages by now.

[0] https://matrix.org/docs/projects/try-matrix-now

The Rust server isn't dead at all, the maintainer is active but not proceeding until async / await is fully stabilized.

I'm the creator of Ruma, and so I can confirm this. :}

For anyone interested, a detailed list of what is blocking or slowing progress can be found here: https://github.com/ruma/ruma/issues/189

Up until very recently we'd been postponing work due to immaturity of both Rust and the Matrix spec. Now that all the Matrix specs have had stable releases, the main blocker is the maturity of async/await and support for it in the library ecosystem. Since Ruma uses nightly Rust currently, we don't need async/await to be stabilized to proceed, but it does need to be far enough along that it has been adopted by all the major components of the Rust HTTP ecosystem. I'm guessing we've got about six months left until this happens.

I appreciate the update.

Putting my "tech lead evaluating tools" hat on, I like the idea of a single-file binary that can be easily deployed. That said, seeing that the last commit was 2 years ago isn't encouraging :( Given that I'll likely be seriously evaluating potential approaches for our system design within the next 2-3 months, it doesn't look like Ruma would be a viable option for our situation.

The reason why alternative server implementations are lagging behind is because there was a very recent push to 1.0 the entire spec (specifically because of the French government deployment discussed in TFA). They said they'd emphasise alternative implementations afterwards in the FOSDEM talk Arathorn gave earlier this month.

Thanks for pointing this out - the website is updated now to include poljar's work. (We did feature it on the blog but important to keep the projects list updated too!)

There are several competing Python libraries, those you mentioned plus https://github.com/tulir/mautrix-python. We'll do a round-up and review of the options soon.

Matrix is totally open sourced. Server side and the official client (Riot) can be deployed anywhere under your own control.

Also, deploying a bridge you can connect Matrix and IRC rooms, creating a hybrid channel mixing Matrix and IRC clients in the same room. It's pretty cool.

While most of your complaints is valid for Discord, it doesn't hold for Telegram, which IMO has high quality clients, in terms of native look&feel, lightweight, and general UX.

Matrix on the other hand is like having everything half-baked. This made it an non-option for daily use and I ended up moving to other IMs and a bouncer for IRC.

you may be surprised at how much it's improved in Riot 1.0, but ymmv :)

I don't think you need to use binary blog GUI clients for Telegram. Here's the source to many clients: https://github.com/TelegramOrg

Reply on news.ycombinator.com