5 ms·

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

by olah_1 6y ago

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

justaj 6y ago
The main Matrix.org homeserver is pretty slow because it's usually overloaded: https://matrixservers.anchel.nl/783115140 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.
- Arathorn 6y ago
  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/ 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.
  - justaj 6y ago
    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.
    - Arathorn 6y ago
      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.
  - http-teapot 6y ago
    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.
    - memorythought 6y ago
      You might be interested in https://radicle.xyz/ https://radicle.xyz/
    - timokoesters 6y ago
      Hi, you should be able to log in with your GitHub account on this page: https://git.koesters.xyz/user/login https://git.koesters.xyz/user/login
- auscompgeek 6y ago
  There's also a few servers running Construct (https://matrix.org/docs/projects/server/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.
boardwaalk 6y ago
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.
- Arathorn 6y ago
  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 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 :(
  - cvwright 6y ago
    This is the MSC you mentioned? https://github.com/matrix-org/matrix-doc/blob/rav/proposal/remove_mxids_from_events/proposals/1228-removing-mxids-from-events.md 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.

by olah_1 6y ago

justaj 6y ago

The main Matrix.org homeserver is pretty slow because it's usually overloaded: https://matrixservers.anchel.nl/783115140 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.

Arathorn 6y ago
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/ 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.
- justaj 6y ago
  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.
  - Arathorn 6y ago
    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.
- http-teapot 6y ago
  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.
  - memorythought 6y ago
    You might be interested in https://radicle.xyz/ https://radicle.xyz/
  - timokoesters 6y ago
    Hi, you should be able to log in with your GitHub account on this page: https://git.koesters.xyz/user/login https://git.koesters.xyz/user/login
auscompgeek 6y ago
There's also a few servers running Construct (https://matrix.org/docs/projects/server/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.

boardwaalk 6y ago

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.

Arathorn 6y ago
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 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 :(
- cvwright 6y ago
  This is the MSC you mentioned? https://github.com/matrix-org/matrix-doc/blob/rav/proposal/remove_mxids_from_events/proposals/1228-removing-mxids-from-events.md 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.