I wish the Matrix team would have more focus. They’re working on all this new experimentall stuff - a new client, a new server etc all the while the existing stuff is severely broken in many ways.
16
arathornMatrix.org project lead2 months ago
|
link
I think you’ve entirely missed the point: we’ve focused specifically on fixing the existing severely broken stuff by writing a client to replace the old broken client. We haven’t written a new server; we added an API to the existing server via a shim, so we could focus and implement faster. There are no new features in Matrix 2.0 (other than native group VoIP) - everything else is either removing stuff (the broken old authentication code in favour of Native OIDC), or fixing stuff (the horrific performance problems, by introducing Sliding Sync and Faster Joins).
With the new server, I was thinking of Dendrite. It’s good you’re fixing Element with Element X, but it feels like it’s been in beta forever, while people keep running into problems with the old Element.
1
arathornMatrix.org project lead2 months ago
|
link
Synapse (the 1st gen server) has simply had the most focus, by far - Dendrite has ended up being a test bed for experimentation. Synapse has improved unrecognisably over the years and now is basically boring stable tech.
What about issues related to e2ee and verification? Some of these have been open for a very long time, and I’ve personally experienced many of these, for years. It definitely gives the impression that the Matrix team has lost focus when problems like these exist in a core feature for Matrix (e2ee).
There are tons more of these issues in your bug tracker, some even reported against the new rust crypto thing, these are just some of the ones I am subscribed to. Is functional E2EE a priority for Matrix?
I can’t remember when I last had this issue because of matrix doing something wrong. So maybe it’s just not happening that often. I personally wouldn’t say it even exists from my experiments..
1
arathornMatrix.org project lead2 months ago
|
link
We rewrote e2ee on a single audit-ready rust codebase rather than chasing the combinatoric explosion of bugs across the various separate web, ios & android implementations, which took ages, but has finally landed with the exception of Web, which should merge next week: https://github.com/vector-im/element-web/issues/21972#issuecomment-1705224936 is the thing yo track. Agreed that this strategy left a lot of people in a bad place while the rewrite happened, but hopefully it will transpire to be the right solution in the end.
I’m a bit surprised by the negative comments here. The sluggishness of Element is one of the worst problems for adoption. I am very glad it’s being worked on.
And indeed, I just tried out Element X, it’s very fast and comparable to Whatsapp and co, very impressive!
Its a step in the right direction, but i think many feel burned by the performance of element. Since switching to fluffychat my view of matrix is totally changed for the better. Cleaner ux and far better performance when fetching updates on already joined rooms, rivaling that of sliding sync.
1
arathornMatrix.org project lead2 months ago
|
link
it’s a bit unfortunate if folks won’t try Element X (which is lightyears ahead of both Element and FluffyChat) because of bad experiences on Element. :/
The only thing that those next gen chat services brings is chat history.
And multi-line comments, and editing, and threading, and embedded media and… all the stuff IRCv3 was supposed to bring but which never turned up because IRCv3 is the definition of second-system syndrome at this point.
And an authentication mechanism in the protocol. And a way to authenticate by doing anything other than sending your password in plain text to the server. And a way of integrating with video / audio chat. And a good way of sharing files. And end-to-end encryption.
IRC always felt like a protocol designed by teenagers. SILC fixed the security bits but not the usability.
And an authentication mechanism in the protocol. And a way to authenticate by doing anything other than sending your password in plain text to the server.
IRC supported SASL for more than a decade, including client TLS certificates.
Both. Regarding SSO it’s true it’s lacking, but some servers support LDAP and there’s work on OAuth. Nothing on proper SSO like OIDC though, and no one has expressed interest in designing or implementing it.
It probably was designed by teenagers, but in their defense, it was designed in the 90s.
From memory, I believe there are still networks that consider the use of an identifying-preserving service like NickServ as weak sauce. If you don’t have the fortitude to stay online to defend your nick, you don’t deserve it.
I mostly spent my IRC time on Freenode (pre-Andrew Lee) which was considered a boring network for grownups.
So far I’ve been enjoying Matrix, the protocol. Although I have yet to find a client, especially on mobile, that I particularly like - Element X seems very close but it’s still missing the ability to read previous chats and the chat list doesn’t seem to be ordered chronologically which is… odd. On desktop I’m opting for the Cinny webapp since Element Web is just too cluttered. None of the apps I’ve tried have satisfactory session verification consistency, but that could also be in part from my use of the Conduit server rather than their Synapse or Dendrite implementations.
I wish it had more adoption but it’s still in a state where I actually don’t really want to push people to use it, especially when it’s “competing” is Discord and their UX (sidenote: I wish Discord didn’t cripple third party clients so we could get a real bridge to Matrix. imo the “killer feature” of Matrix is the bridging functionality).
I wish the Matrix team would have more focus. They’re working on all this new experimentall stuff - a new client, a new server etc all the while the existing stuff is severely broken in many ways.
I think you’ve entirely missed the point: we’ve focused specifically on fixing the existing severely broken stuff by writing a client to replace the old broken client. We haven’t written a new server; we added an API to the existing server via a shim, so we could focus and implement faster. There are no new features in Matrix 2.0 (other than native group VoIP) - everything else is either removing stuff (the broken old authentication code in favour of Native OIDC), or fixing stuff (the horrific performance problems, by introducing Sliding Sync and Faster Joins).
With the new server, I was thinking of Dendrite. It’s good you’re fixing Element with Element X, but it feels like it’s been in beta forever, while people keep running into problems with the old Element.
Synapse (the 1st gen server) has simply had the most focus, by far - Dendrite has ended up being a test bed for experimentation. Synapse has improved unrecognisably over the years and now is basically boring stable tech.
What about issues related to e2ee and verification? Some of these have been open for a very long time, and I’ve personally experienced many of these, for years. It definitely gives the impression that the Matrix team has lost focus when problems like these exist in a core feature for Matrix (e2ee).
https://github.com/vector-im/element-android/issues/5305
https://github.com/vector-im/element-android/issues/2889
https://github.com/vector-im/element-android/issues/1721
There are tons more of these issues in your bug tracker, some even reported against the new rust crypto thing, these are just some of the ones I am subscribed to. Is functional E2EE a priority for Matrix?
I can’t remember when I last had this issue because of matrix doing something wrong. So maybe it’s just not happening that often. I personally wouldn’t say it even exists from my experiments..
We rewrote e2ee on a single audit-ready rust codebase rather than chasing the combinatoric explosion of bugs across the various separate web, ios & android implementations, which took ages, but has finally landed with the exception of Web, which should merge next week: https://github.com/vector-im/element-web/issues/21972#issuecomment-1705224936 is the thing yo track. Agreed that this strategy left a lot of people in a bad place while the rewrite happened, but hopefully it will transpire to be the right solution in the end.
I’m a bit surprised by the negative comments here. The sluggishness of Element is one of the worst problems for adoption. I am very glad it’s being worked on.
And indeed, I just tried out Element X, it’s very fast and comparable to Whatsapp and co, very impressive!
Its a step in the right direction, but i think many feel burned by the performance of element. Since switching to fluffychat my view of matrix is totally changed for the better. Cleaner ux and far better performance when fetching updates on already joined rooms, rivaling that of sliding sync.
it’s a bit unfortunate if folks won’t try Element X (which is lightyears ahead of both Element and FluffyChat) because of bad experiences on Element. :/
The only thing that those next gen chat services brings is chat history.
IRC was fine for a long time, and I don’t understand why it’s being replaced with all those things, who are often quite bloated and commercial.
And multi-line comments, and editing, and threading, and embedded media and… all the stuff IRCv3 was supposed to bring but which never turned up because IRCv3 is the definition of second-system syndrome at this point.
And an authentication mechanism in the protocol. And a way to authenticate by doing anything other than sending your password in plain text to the server. And a way of integrating with video / audio chat. And a good way of sharing files. And end-to-end encryption.
IRC always felt like a protocol designed by teenagers. SILC fixed the security bits but not the usability.
IRC supported SASL for more than a decade, including client TLS certificates.
the protocol or the servers ? Because I’ve never found something like this in the wild - you want real SSO support for campus networks.
Both. Regarding SSO it’s true it’s lacking, but some servers support LDAP and there’s work on OAuth. Nothing on proper SSO like OIDC though, and no one has expressed interest in designing or implementing it.
It probably was designed by teenagers, but in their defense, it was designed in the 90s.
From memory, I believe there are still networks that consider the use of an identifying-preserving service like NickServ as weak sauce. If you don’t have the fortitude to stay online to defend your nick, you don’t deserve it.
I mostly spent my IRC time on Freenode (pre-Andrew Lee) which was considered a boring network for grownups.
So far I’ve been enjoying Matrix, the protocol. Although I have yet to find a client, especially on mobile, that I particularly like - Element X seems very close but it’s still missing the ability to read previous chats and the chat list doesn’t seem to be ordered chronologically which is… odd. On desktop I’m opting for the Cinny webapp since Element Web is just too cluttered. None of the apps I’ve tried have satisfactory session verification consistency, but that could also be in part from my use of the Conduit server rather than their Synapse or Dendrite implementations.
I wish it had more adoption but it’s still in a state where I actually don’t really want to push people to use it, especially when it’s “competing” is Discord and their UX (sidenote: I wish Discord didn’t cripple third party clients so we could get a real bridge to Matrix. imo the “killer feature” of Matrix is the bridging functionality).
Nothing about cryptography or adopting MLS? Too bad
The MLS announcement is here: https://matrix.org/blog/2023/07/a-giant-leap-with-mls/
Oh nice. I must have missed that. Huh, paid for by the German military. Well, I guess that’s money well spent. Thank you!
What about cryptography would you like them to say?
“It’s a waste of time in this context”