Firstly, it's not introducing new features - it's just making the current featureset work super-efficiently (while retaining compatibility with today's Matrix). So there should be no fragmentation between Element/Fluffychat/Thunderbird, with the possible exception of the new scalable encrypted VoIP conferencing (but then very few Matrix clients implemented the old VoIP conferencing, plus you can always just embed an Element Call instance to get at it now - as Element X does today).
Secondly, we're explicitly working to protect Matrix from the commercial interests from Element (the company set up by the team who created Matrix, of which I'm ceo/cto as well as Matrix project lead). We already have The Matrix.org Foundation (https://matrix.org/foundation) as an independent non-profit to hold the Matrix IP and maintain its neutrality - but we also just hired Josh Simmons (former President of the OSI) as its independent Managing Director (https://matrix.org/blog/2023/09/introducing-josh-simmons-man...).
So: going forwards, the Foundation increasingly does not have to depend on Element not being evil, but instead has its own independent management to ensure the protocol exists to support everyone in the ecosystem, without fragmentation, as per the guiding principles at https://matrix.org/foundation - under its own autonomy.
I'd say this is is good news for libre software privacy & security type people, but then again I'm biased. Practically, the only thing getting in the way of getting friends & family on Matrix is that Element X requires fancy OIDC-native homeservers for registration, so newbies won't be able to use Element X to join Matrix yet. But the app itself should be an excellent way to get folks on board in the very near future.
> plus you can always just embed an Element Call instance
That sounds like potentially a commercial embrace&extend&extinguish situation, which we need to avoid.
Admittedly the new livekit-based implementation takes us back down to a single implementation for now, but in its defense it’s only a few weeks old (with e2ee). Hopefully others will spin up independent implementations rapidly - although right now it does introduce a potential commercial EEE situation… but from on LiveKit rather than Element.
Eitherway, it’s something we’re painfully aware of… while also trying to ensure we find enough $ to pay for dev on Matrix (and Element) otherwise the whole thing collapses.
the way threads are displayed in the browser versions makes them hard to follow. in our hackerspace, where many are tech minded people, i see regular complaints about that.
scrollback to unread messages often fails. i have never had another chat application where that was a problem. this should just work.
the handling of encryption keys is very confusing. there are to many moving parts, it's not clear what i must save so that i can restore the keys in a new client.
private rooms are also confusing. i want to have a private room be the name of my chat partner, and they want it to carry my name. being able to do that would be very helpful.
i am also missing the ability to use a different nickname in every room. different groups know me under different nicknames. discord and wechat can do it. it would be great if matrix/element could do that too.
Having got Element X out the door, my attention at least is going to swing back to Element Web. In terms of encryption disasters, we are about to switch Element Web’s crypto to the same rust implementation as Element X, hopefully next week - you can track the progress at https://github.com/vector-im/element-web/issues/21972#issuec.... Hopefully this will make a much-needed massive improvement on encryption, while also speeding it up 5x or so. On Element X, encryption failures are almost unheard of (other than when talking to Element Web).
This alone makes Matrix the worse chat platform out there from a users perspective IMO. I invested too much effort in getting things up and running and using it now though, so I'm just hoping that this gets fixed one day, or something better comes along that I can migrate to.
One time I had to manually export and import my own keys to be able to read old messages, which was a task that would have been too technical for most of the people I'd like to chat with, and was supremely annoying for me.
It's just a non-starter. I have a community I've been considering moving to Matrix for literal _years_ now and there are just so many sharp edges.
I've been confused about Matrix's priorities for a long, long time. I am not getting any less confused, to be honest.
The high level plan is:
* Fix all the bugs which cause random undecryptable messages, which was the main thing causing frustration. This is (hopefully) done now by converging on the new Rust implementation.
* Generate a recovery key, rather than confuse the user by asking them to pick two passwords (one for their account, one for their encryption). Impress on the user that if they ever want to recover their history, they'll need it. Expect that most users will lose it.
* When logging in on a new device, scan a QR code on an existing device to transfer over the keys (and thus history). Users are used to this now thanks to WhatsApp and Discord, and empirically they can do it fine. The recovery key is used only as a worst-case scenario if the user has no other devices. The act of logging in (either via scanning another device, or via recovery key) signs that device as owned by you.
* Only accept messages from devices that a given user has signed (i.e. trust on first use for users). If you want to verify that user out of band, they get an green tick too, purely to help you keep track of which users you're sure are legit and which users you've assumed are legit.
* At any given point, encryption is either enabled on your device (i.e. you've signed that device; it can access your encrypted message history; it can store keys for your encrypted message history) or it's not (and you can't do any E2EE). There are no halfway states.
This may sound simple and obvious when written out like this, but each point is a major change from the supremely confusing system we have today. The thing stopping us from having implemented it sooner is the huge amount of effort which went into reimplementing the engine in Rust. But having now (almost) finished that project, next thing up is fixing the UX, at last. The rough timeline is hopefully end-of-year, but, again, timings are contingent on funding pressure.
This is a centralized point for surveillance of metadata. I also do not know how much information is actually contained in the notification itself. In any case Vector has knowledge of every home server with an iOS client, and their approximate traffic levels.
It also requires that you as a homeserver sysadmin a) have a Mac, b) install Xcode, c) know how to modify and compile iOS applications, d) want to deal with rebuilding and reuploading and re-seeking app approval on major API changes because long-un-updated apps are not allowed in the App Store, etc...
If you start by assuming that a perfect solution will always be unattainable, deciding on what tradeoffs are acceptable becomes easier.
Imho it almost always going to be worth trading the large PITA of self-managing APNS infra for the small surface area that routing push notifications through Elements systems.
The problem is iOS's privacy-hostile design (in service of their locked down revenue model), not some unbreakable iron triangle.
On Android, messaging apps can run in the background and periodically talk to their homeserver without an intermediary.
Background tasks on Android can pretty much be killed at any time. I believe only apps with a persistent notification and the native google notification service can remain active at all times. But yes, they can connect to any server while they are running.
Once you're going to push encrypted data through a centralized service, you might as well just run Signal and skip running the homeserver too.
(To be clear, the platform has to be all open source and open standards, actually decentralized, guided by those principles -- not an effectively proprietary play even if nominally open. For example, you should be able to get all the same functionality with Element, Fluffychat, Thunderbird, and other user agents, and with any home server, both now and on an ongoing basis. And the user agent implementation difficulty should become tractable enough, in terms of size&complexity and specification, that one person could write a new one -- not like Web browsers have become, where there's mainly only one, that company has been funding the runner-up, and that company can pretty much dictate 'standards'.)