3 ms·

I've been on-and-off hosting for a while and I avoided synapse because it seemed to rely on a lot of different services and python packaging is hell. Seems like

I've been on-and-off hosting for a while and I avoided synapse because it seemed to rely on a lot of different services and python packaging is hell. Seems like dendrite is dying (which I did not know until now), conduit and siblings are very much beta and not close to being stable. If I read this correctly there is just one server worth actually using (synapse) and two client libraries (matrix-rust-sdk and matrix-js-sdk, both maintained by the same org/people). At the same time most of the bridges to other protocols (which was one huge selling point of matrix) are either broken, outdated, alpha (and by that I mean really, really alpha) or beta (usually in a stagnant state or alpha-ish). One of the goals (perhaps the primary?) of matrix was to build a protocol that is supported by multiple servers, clients and bridges but that does not seem to have been realized. I just listened to the keynote on matrix 2.0 and... I used to be a huge proponent of matrix, but I really feel like the potential has not been lived up to.

Arathorn 2y ago
There are loads of SDKs which work well - as well as matrix-rust-sdk and matrix-js-sdk there's also excellent fully-featured indie libraries for Dart, Kotlin, C++, Go, Python (and many other others which don't have full parity). You're right that Dendrite is currently stalled, but it's not a reflection on the protocol, but just the reality that writing and maintaining two servers simultaneously is expensive. Meanwhile most of the good stuff in Dendrite has already made it back into Synapse. Bridge development has also stalled for the same reason (exacerbated with hostility from those being bridged) - but then 3rd party bridges like heisenbridge are doing fine. On the other hand, conduit/conduwuit/grapevine look to be bubbling away at an impressive rate (entirely independently of Element), even if they're currently beta. So, I don't think the potential has been lost - instead, the core team has ended up focusing our energy on a smaller set of projects while making sure we get a small set of things really excellent rather than being spread too thin, which is a major improvement over the past, imo. Meanwhile the broader community is busy hacking away too.
- SahAssar 2y ago
  > Meanwhile most of the good stuff in Dendrite has already made it back into Synapse But that still means there is only one actual trusted server implementation, right? I thought the point of dendrite was to be able to prove that MSCs were implementable independently before they became part of the spec. It seems like the actual spec is just whatever MSC synapse has implemented. > Bridge development has also stalled for the same reason (exacerbated with hostility from those being bridged) Some open protocols like XMPP (which would seem like a natural fit) do not have stable bridges. Other open protocols like email are quite limited in that they require you to act as a full service provider (actual email server instead of a bridge between an email account and matrix). Others like SMS have no stable implementation. Those are just the ones that cannot be hostile to bridging. Many of the bridges to proprietary services listed on the site have not had any activity for 2+ years (which in itself is not bad but if they interface with a moving target or changing protocol it probably is). Is the "One chat protocol to bridge them all" goal abandoned? > the core team has ended up focusing our energy on a smaller set of projects while making sure we get a small set of things really excellent I'd love to see that. I'd especially love to see it stabilize and simplify enough that we have a multitude of servers, clients and bridges that are stable and useful. I'm just not seeing it right now. Thank you for taking the time to reply
  - Arathorn 2y ago
    > But that still means there is only one actual trusted server implementation, right? Nope? Dendrite works. It's just stuck in beta for now due to lack of manpower. > I thought the point of dendrite was to be able to prove that MSCs were implementable independently before they became part of the spec. It seems like the actual spec is just whatever MSC synapse has implemented. The spec is not "whatever MSC synapse has implemented". The spec is... the spec, and the compliance test suites (sytest, complement) which go with it. Currently we require one implementation of MSCs to prove their validity before landing in the spec - and that could be in synapse, dendrite, conduit or wherever. Just because the core team only has $ to actively progress a single server implementation right now doesn't devalue the spec at all. If anything it makes 3rd party implementations like the Conduits even more important, in terms of showing that the spec isn't coupled to the Synapse implementation. > Is the "One chat protocol to bridge them all" goal abandoned? Right now the goal is "have a decentralised open chat protocol whose apps can outperform mainstream centralised products". Bridging is secondary (for now, although Beeper is obviously focused on it). > > the core team has ended up focusing our energy on a smaller set of projects while making sure we get a small set of things really excellent > I'd love to see that. I'd especially love to see it stabilize and simplify enough that we have a multitude of servers, clients and bridges that are stable and useful. The two are mutually exclusive. We can't simultaneously focus on getting a small number of implementations excellent... while also working on a multitude of implementations. Instead, we can make sure that the implementations that the core team works on at Element are great, solve problems, simplify things and unlock everyone else to be able to build better ones too - which is precisely what we're doing.

Arathorn 2y ago

There are loads of SDKs which work well - as well as matrix-rust-sdk and matrix-js-sdk there's also excellent fully-featured indie libraries for Dart, Kotlin, C++, Go, Python (and many other others which don't have full parity). You're right that Dendrite is currently stalled, but it's not a reflection on the protocol, but just the reality that writing and maintaining two servers simultaneously is expensive. Meanwhile most of the good stuff in Dendrite has already made it back into Synapse. Bridge development has also stalled for the same reason (exacerbated with hostility from those being bridged) - but then 3rd party bridges like heisenbridge are doing fine. On the other hand, conduit/conduwuit/grapevine look to be bubbling away at an impressive rate (entirely independently of Element), even if they're currently beta. So, I don't think the potential has been lost - instead, the core team has ended up focusing our energy on a smaller set of projects while making sure we get a small set of things really excellent rather than being spread too thin, which is a major improvement over the past, imo. Meanwhile the broader community is busy hacking away too.

SahAssar 2y ago
> Meanwhile most of the good stuff in Dendrite has already made it back into Synapse But that still means there is only one actual trusted server implementation, right? I thought the point of dendrite was to be able to prove that MSCs were implementable independently before they became part of the spec. It seems like the actual spec is just whatever MSC synapse has implemented. > Bridge development has also stalled for the same reason (exacerbated with hostility from those being bridged) Some open protocols like XMPP (which would seem like a natural fit) do not have stable bridges. Other open protocols like email are quite limited in that they require you to act as a full service provider (actual email server instead of a bridge between an email account and matrix). Others like SMS have no stable implementation. Those are just the ones that cannot be hostile to bridging. Many of the bridges to proprietary services listed on the site have not had any activity for 2+ years (which in itself is not bad but if they interface with a moving target or changing protocol it probably is). Is the "One chat protocol to bridge them all" goal abandoned? > the core team has ended up focusing our energy on a smaller set of projects while making sure we get a small set of things really excellent I'd love to see that. I'd especially love to see it stabilize and simplify enough that we have a multitude of servers, clients and bridges that are stable and useful. I'm just not seeing it right now. Thank you for taking the time to reply
- Arathorn 2y ago
  > But that still means there is only one actual trusted server implementation, right? Nope? Dendrite works. It's just stuck in beta for now due to lack of manpower. > I thought the point of dendrite was to be able to prove that MSCs were implementable independently before they became part of the spec. It seems like the actual spec is just whatever MSC synapse has implemented. The spec is not "whatever MSC synapse has implemented". The spec is... the spec, and the compliance test suites (sytest, complement) which go with it. Currently we require one implementation of MSCs to prove their validity before landing in the spec - and that could be in synapse, dendrite, conduit or wherever. Just because the core team only has $ to actively progress a single server implementation right now doesn't devalue the spec at all. If anything it makes 3rd party implementations like the Conduits even more important, in terms of showing that the spec isn't coupled to the Synapse implementation. > Is the "One chat protocol to bridge them all" goal abandoned? Right now the goal is "have a decentralised open chat protocol whose apps can outperform mainstream centralised products". Bridging is secondary (for now, although Beeper is obviously focused on it). > > the core team has ended up focusing our energy on a smaller set of projects while making sure we get a small set of things really excellent > I'd love to see that. I'd especially love to see it stabilize and simplify enough that we have a multitude of servers, clients and bridges that are stable and useful. The two are mutually exclusive. We can't simultaneously focus on getting a small number of implementations excellent... while also working on a multitude of implementations. Instead, we can make sure that the implementations that the core team works on at Element are great, solve problems, simplify things and unlock everyone else to be able to build better ones too - which is precisely what we're doing.