I personally really like Matrix, but there are a few outstanding complaints about it. The biggest one is that the reference implementation everyone uses by default is known to be bloated and slow, and poor at scaling. Server admins have had a huge challenge of supporting a large amount of data for things like room history, which in the past required propagation to every server hosting every participant. The protocol itself has been described by some developers as overtly complex.
Some of this seems to be improving, particularly with development of a Go-based backend implementation, Dendrite.
It’s funny. When I was typing my original response, I was under the impression that Dendrite was Rust-based! 😂 I’m really glad I checked before posting!
Good to know. I signed up for beeper.com which seems cool. I am a bit concerned about data collection and privacy, so I’m trying to set up my own instance.
@deadsuperhero
> development of a Go-based backend implementation, Dendrite
Also Rust-based homeserver implementations like Construct and Conduit. Both of which are usable, although missing a few nice-to-have added features. Eg Conduit is still working on;
“E2EE emoji comparison over federation (E2EE chat works)… Outgoing read receipts, typing, presence over federation”
I’m not even close to an expert, but from what I have heard, matrix collects quite a bit of metadata depending on the server you are using/federating with.
Yes, it does not protect metadata great. It is visible that you and your interlocutor are talking together and when.
But noone figured out how to prevent that in federated systems. You rather have less metadata in centralized place for everyone or more metadata but only for small subset of people.
@smileyhead
> But noone figured out how to prevent that in federated systems
You’ve basically got a choice been a centralised service where metadata can be limited but E2EE is mostly pointless (you have to trust the service operators’ E2EE deployment), or a decentralised network where E2EE is reliable, but it’s harder to limit metadata.
Which one is best depends on the situation/ threat model.
I just learned about Matrix recently. Seems like something that’d be good. What sucks about it?
Besides the main implementation synapse being slow, the new implementation dendrite is unfinished but progressing.
But technical standards aside, the hassle of managing encryption keys is too buggy and confusing IMO. That’ll deter most people I feel.
I want it to be great but it just isn’t there yet.
I personally really like Matrix, but there are a few outstanding complaints about it. The biggest one is that the reference implementation everyone uses by default is known to be bloated and slow, and poor at scaling. Server admins have had a huge challenge of supporting a large amount of data for things like room history, which in the past required propagation to every server hosting every participant. The protocol itself has been described by some developers as overtly complex.
Some of this seems to be improving, particularly with development of a Go-based backend implementation, Dendrite.
And if dendrite fail, we wait for the rust-based backend implementation. :)
It’s funny. When I was typing my original response, I was under the impression that Dendrite was Rust-based! 😂 I’m really glad I checked before posting!
Fun fact. I didn’t made a joke. There is a rust based version in alpha state. But I don’t remember it’s codename.
Edit: okay, it has no codename:
https://github.com/matrix-org/matrix-rust-sdk
Oh, I thought that was just a client SDK. Is it an actual server backend?
Good to know. I signed up for beeper.com which seems cool. I am a bit concerned about data collection and privacy, so I’m trying to set up my own instance.
@deadsuperhero
> the reference implementation everyone uses by default is known to be bloated and slow, and poor at scaling
This doesn’t seem to stop the fediverse growing (*cough* Mastodon *cough*).
@Terevos
@deadsuperhero
> development of a Go-based backend implementation, Dendrite
Also Rust-based homeserver implementations like Construct and Conduit. Both of which are usable, although missing a few nice-to-have added features. Eg Conduit is still working on;
“E2EE emoji comparison over federation (E2EE chat works)… Outgoing read receipts, typing, presence over federation”
@Terevos @Samsy
I’m not even close to an expert, but from what I have heard, matrix collects quite a bit of metadata depending on the server you are using/federating with.
Yes, it does not protect metadata great. It is visible that you and your interlocutor are talking together and when.
But noone figured out how to prevent that in federated systems. You rather have less metadata in centralized place for everyone or more metadata but only for small subset of people.
@smileyhead
> But noone figured out how to prevent that in federated systems
You’ve basically got a choice been a centralised service where metadata can be limited but E2EE is mostly pointless (you have to trust the service operators’ E2EE deployment), or a decentralised network where E2EE is reliable, but it’s harder to limit metadata.
Which one is best depends on the situation/ threat model.
@AngryDemonoid
Yeah, I have been concerned about that. Looking into self-hosting matrix.