cinny VS matrix-spec-proposals

Find more about Cinny at https://cinny.in/ Join our channel at: https://matrix.to/#/#cinny:matrix.org Github: https://github.com/ajbura/cinny Twitter: https://twitter.com/@cinnyapp

got fixed by https://github.com/matrix-org/matrix-spec-proposals/blob/mai... fwiw

that's pseudo IDs; MSC4014 (https://github.com/matrix-org/matrix-spec-proposals/blob/keg...).

it got implemented in Dendrite, but hasn't made it into Synapse (or the spec) yet.

Thanks for the positive feedback :) There's still a lot of polish (and features) planned out for Element X, so it should only get better!

> I thought we agreed on “security key” for a while, but I do like this name better

Yes, sorry for flipflopping on this. On the plus side, we've finally locked down encryption terminology and are going to get it in the spec to ensure that UX is consistent between clients: https://github.com/matrix-org/matrix-spec-proposals/blob/and...

In terms of clients for other platforms - it's worth noting that GNOME Fractal uses matrix-rust-sdk and so benefits from all the work that goes into Element X on the rust-sdk side, and so is shaping up increasingly well :)

We did improve things massively (like, 5x) with Faster Remote Room Joins: https://github.com/matrix-org/matrix-spec-proposals/pull/390... and https://element-hq.github.io/synapse/latest/development/syna....

We did all the super-hard groundwork to make non-atomic joins possible - but then ran out of time & $ to go further (plus none of the Element paying customers are complaining about it). There's another order of magnitude speedup to be had there, though.

Between this and https://github.com/matrix-org/matrix-spec-proposals/blob/mat... we should be able to fix things unrecognisably, but just haven't got there yet.

> Matrix is mostly a victim of the government forks taking up their time in different directions instead of having just one app like signal.

It's a double-edged sword. On one hand, it generates $ to work on Matrix. On the other hand, it means that if none of the $-payers care about faster remote room joins, they get deprioritised :|

this is very very confused.

the key you use in Matrix to get at your historical messages /is/ your security passphrase/key (assuming you set it up).

the vector.im identity server is just a phonebook to let people discover you based on email address if you so desire.

the UX in Element is clearly a disaster, given nightmarish confusions like this. we have tried to fix it in Element X and stuff like https://github.com/matrix-org/matrix-spec-proposals/blob/and... which is looking promising

Not only are they actually very closely linked, in that Element operates matrix.org, but to a new user (told to try Matrix -- what is this Element thing?) there's no difference.

I onboarded a family member onto my Matrix server with FluffyChat as the client. This person is a power user, fairly technical, yet still refers to the chat as "FluffyChat" and although I've explained several times that choosing FluffyChat was maybe a mistake and they should use Element, it never seems to really click that multiple clients are possible.

And really, they aren't possible. They have different subsets of features.

If you want to see a trash can fire, just try to follow the discussion for adding custom emoji to Matrix: https://github.com/matrix-org/matrix-spec-proposals/pull/195...

it's been going on for years. It's a feature the competitors have had for half a decade, as long as this discussion has been ongoing. I've been watching this issue for half a decade thinking "surely they'll decide on something" but mostly all I've been convinced of is this: Matrix is design by committee in all of the worst aspects and at every level of design. If anything gets done at all, it's a convoluted mess, and it's a miracle that it even happens.

I wish community software developers would focus their attention.. somewhere else.

So Matrix also has account portability (almost) - https://github.com/matrix-org/matrix-spec-proposals/blob/keg... and https://github.com/devonh/matrix-spec-proposals/blob/cryptoI..., implemented in Dendrite. Unfortunately dev is paused on it currently thanks to lack of $ though.

The AP approach (prioritising portable identities over portable account data) is cute though, and perhaps we should have prioritised that as an alternative to fullblown cryptographic IDs & account portability.

Luckily, it doesn't matter what individuals expect. There is written documentation on what the foundation is supposed to do or not to do: https://github.com/matrix-org/matrix-spec-proposals/blob/mai...

Notably, "Code Core Team members must arrange their own funding for their time", which I understand as such that the Foundation does not pay directly the developers (same as other standards organizations like IETF).

Main tasks of Matrix.org Foundation is maintaining the spec, documentation, owning IP, promotion and the matrix.org home server. The home server is "generously hosted" by UpCloud (i.e. is not using New Vector EMS), at least according to the matrix.org website.

Looking again at MSC1779, I noticed it says that one function of The Matrix.org Foundation is "Owns the copyright of the reference implementations of Matrix (i.e. everything in https://github.com/matrix-org). By assigning copyright to the Foundation, it’s protected against New Vector ever being tempted to relicense it." That protection apparently wasn't very effective, but also notably, New Vector and their leadership clearly have shown to not stand behind the goals of the Foundation. As the leadership of New Vector is also part of the leadership of the Foundation, I see some huge potential for COI here.