Hacker News Reader

Comment by cyphar | Hacker News Reader

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

View on HN

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.

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

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.

Reply on news.ycombinator.com