Hacker News Reader

Comment by olah_1 | Hacker News Reader

> Imagine if every WP site automatically came with its own Matrix room or community? Imagine if all content in WP automatically was published into Matrix as well as the Web?… Imagine there was an excellent Matrix client available as a WordPress plugin for embedding realtime chat into your site?”

I want to imagine it, but I really struggle to. Matrix is just too slow, bloated, and heavy. I cannot even fathom what a snappy experience with Matrix would be like. I look forward to something like this if it happens though!

View on HN

The main Matrix.org homeserver is pretty slow because it's usually overloaded: https://matrixservers.anchel.nl/783115140

This is IMO mainly because they've stuck with the main implementation of the homeserver (Synapse) being written in Python. Had they've gone through with developing Dendrite as the main implementation, or perhaps even gone with one written in Rust, all of this would feel much snappier.

In a way, Dendrite is now being primed to be compiled to WASM and used in a p2p setup of Matrix, but hopefully we'll also see it running on servers instead of Synapse one day.

Although, to be fair, you can't really blame them too much though, they're a casualty to the Coronavirus effects like a lot of similar services are currently.

There are a bunch of Dendrites already running serverside on the public network there - it's almost out of alpha.

Meanwhile Conduit (http://conduit.rs/) is a new implementation in Rust which is making spectacular progress (it's overtaken Dendrite in some places already).

Both of them are unrecognisably snappy, relative to Synapse - even when Synapse isn't completely overloaded.

Very interesting! I hadn't heard of Conduit before.

So, if that's available, why not use Conduit as a candidate for the p2p-matrix? Wouldn't it be a better choice than Dendrite? AFAIK Mozilla is already heavily pushing Rust into the WASM territory so perhaps that would make a lot of sense.

Conduit doesn’t federate yet, but Dendrite does - and Dendrite is working surprisingly well for p2p already. But in future could use Conduit too; it’d probably be way smaller footprint.

Conduit looks fantastic, I might start using it and possibly contribute.

On that note, is hosting a git GUI a trend? If I want to contribute I have to sign up. I’d have dozens of logins if projects started doing this.

I wonder if matrix could work as a decentralized git.

You might be interested in https://radicle.xyz/

Hi, you should be able to log in with your GitHub account on this page: https://git.koesters.xyz/user/login

There's also a few servers running Construct (https://matrix.org/docs/projects/server/construct), a homeserver written in C++, on the network as well.

I don't use it myself, but I hear it's quite snappy too.

Just want to say this is my experience. I’ve tried a few times to set up a Matrix server and federating with and joining any room that’s larger/has more history is an exercise in frustration. High CPU usage, frequent timeouts. And this is with years between attempts; nothing really seems to have improved. And I’m still getting Matrix-related HTTP requests a month after taking the server down, which is a little annoying.

Obviously distributed and encrypted not an easy problem, but if this is what it is, it’s just not fit for purpose for me.

Joining big rooms is still slow because you currently have to check the keys of every server in the room before you know whether to trust the events in that room; we're fixing this with MSC1228 (using keys as identifiers so you don't have to separately check the keys).

Once you're in, though, performance has improved 2-3x over the last year, and there's easily 10-100x more improvements to be made one way or another. We're also about to add active/active clustering in Synapse at last, which should make bigger servers zippy.

In terms of receiving traffic after you've torn down the server; this is equivalent to getting people trying to talk SMTP to you on port 25 years after you've taken down your MTA. You can mitigate it by explicitly leaving all the rooms on your server before you tear it down, though; i've just filed a bug at https://github.com/matrix-org/synapse/issues/7551 to track maintaining a script to do so.

Sorry you've had a crap time so far though :(

This is the MSC you mentioned? https://github.com/matrix-org/matrix-doc/blob/rav/proposal/r...

I love the idea of using public keys as identifiers, but to be honest the current proposal does NOT give me a warm fuzzy feeling inside.

First, you’re having the server generate keys for the users. This is at best a “code smell” —- even if it works for your particular security goals, it sure feels weird. Zoom recently got absolutely blasted (and rightly so) for doing something similar. Why not have the user generate their own keypair, and then the server can sign the public half, essentially giving you a cert.

Second, there’s a lot of places where you have a layer of indirection between old @user:domain id’s and the new public keys. As an attacker, I would see every one of those places as extra attack surface where I might be able to exploit some confusion.

I hope this doesn’t come off as excessively negative. Matrix is awesome and you’re all doing a great job tackling some huge problems.

Yup, that's the right link, but I think you've misunderstood the intention of MSC1228.

The user identity keys are not used for encryption, let alone end-to-end encryption. These are of course only ever created on clients, and never leave the clients.

Instead, this is just a proposal for how to determine what servers are allowed to host a given identity. The proposal also predates E2E - nowadays we might also sign the keys with your E2EE keys to lock the chain of trust to the client.

I get why the whole indirection from @foo:bar.com through to new public keys might also feel weird, but in practice we have that indirection today - as you resolve (say) an email address to a matrix ID. It's basically making the old matrix IDs equivalent to today's 3rd party IDs (email or phone number or whatever).

So yup, understood that it smells funny, but I think the concerns aren't entirely well-founded here. That said, the proposal is ~2 years old, and we'll be dusting it off and sorting it out in the coming months in order to support P2P and speed up room joins, and that might be the point where we tie it into E2EE keys (or not).

Ah ok that does make me feel better. I’ll try to take a closer look when I have time. Thanks!

Reply on news.ycombinator.com