The Matrix Summer Special 2022
matrix.org
matrix.org
They have the resources, and they have the backing, something that is rare for such open source projects.
But its time for Matrix and Element to focus on UX.
Because IMO, Element's UX is holding back matrix, from the weird massage order by default, even though it supports chat bubbles, no normal user would know.
The jitsi integration is very limited, but that's getting changed soon.
The three plus signs are confusing, I once told someone to click the plus sign to join a room, and he didn't know which one to use.
The mobile apps are filled with bugs, especially around RTL and mention handling, but I hope this will change with the new "Element X" generation of apps.
People might say there are alternative clients, but they are often late on every feature, so Element is the real one everyone uses.
One wish is for matrix to support multi-domain servers, so it can be easy to use as with email for example.
But that will also require a way to export and import all chat history, which AFAIK still doesn't exist, and also a better way to handle delegation without a website, the SRV way is too complicated, maybe a new TXT record ?
I told them about it, they are aware of it and it may come in Matrix 2.0:
Decentralised/portable accounts are up next as soon as Faster Joins land, letting you migrate between accounts (and effectively providing vhosting) without having to export/import anything. (my bad for not mentioning portable accounts in the blog).
https://github.com/vector-im/element-android/issues/4425
And Quick replies actually replying to the message. https://github.com/vector-im/element-android/issues/5653
I hope the performance problems on Element Android will be fixed as well. Sometimes it takes a second for me for a room to open after I clicked on it. Using Hydrogen in a web browser feels so much better.
- Fast remote joins: I think this treats the symptoms of a problem rather than the cause.
Rooms should not contain so much data. Do users really need a state event per room (+all their history) or can it be optimized to one state event per server? I'm in the process of writing an MSC for this.
Alternatively, instead of half-joining the room, you could add features to room 'peeking' so that you can fully interact with a remote room without persisting the room on the server at all.
For fast remote joins: however you express the state events per room, there’s no excuse to block joining the room on having all the state. In fact, the original driver for fast joins was me implementing peeking over federation in Dendrite and needing a fast way to look at the state in the room.
Unsure that having one membership event per server rather than per user is obviously a win - it’s the same amount of info in the end, plus you’ll hit the 65K event limit as well as increasing chance of races (within the server) if you put all users in the same event for a given server. Feel free to prove me wrong tho :)
On the other hand, we definitely need a way to delete irrelevant old state, and there’s a bunch of work happening around that currently.
Once those issues are fixed, it will be _far_ easier to recommend Matrix to the general public.
This is really coming together as the project that really brings it all together.
The Audio/Video stuff is great and having it fully embedded in the matrix client will be amazing.
P2P is really cool, specially when there is an easy way to have other servers (or your own) temporary hold the message for you when you are offline. Having full local offline matrix with the standard chat client rather then some more specialized tool is a real game changer.
What I would like to see is for Matrix Decentralized Identity to be able to be used as a SSO for other sites.
Great work and great to see that a great business has been built on this technology as well.
We haven’t figured out how P2P Matrix will work with authentication yet - it’s kinda ironic that for normal Matrix we are moving to OpenID Connect (ie shifting SSO to normal OIDC providers)… but at the same time P2P Matrix identity is inevitably linked to owning a private key.
The solution may to be ensure that OIDC itself has a way to log people in based on presenting a private key - be that your P2P Matrix identity or something else :)
Isn't that what the OIDC people are trying to achieve with SIOP (Self-Issued OpenID Providers)?
The work on that extension to OIDC is a bit new[0], but it seems to share Matrix's goal of decentralisation by letting users have portable identities that aren't dependent on big providers.
There is also work to make these SIOP identities integrate with the wider W3C Decentralized Identifiers (DID) ecosystem, through DID-SIOP[1], so that might create some more opportunities for interoperability.
[0] https://openid.net/specs/openid-connect-self-issued-v2-1_0.h...
I mean... don't get me wrong, it's pretty impressive how much optimizations were able to happen, but wasn't Synapse initially meant as some sort of MVP that was to be replaced by a next-gen homeserver implementation like Dendrite?
IIRC Dendrite was intended to be out of beta (and pass 100% of the tests) like... a year ago, right?
Because costumers probably? People are not all just gone switch.
love matrix, and glad to see the notes (at least when I was using a self hosted element not long ago) - noting that going forward with audio / video call can expose end user's ip addy.
Good reminder I need to check for updates. Wonder if there is an 'get email when new update is a thing' somewhere.
Matrix is also a member of Khronos Group, and we’ll be working to ensure glTF supports all of the necessary extensions to have a kickass time in Third Room (and other 3D matrix client!)