XMPP was nice. Especially in the old times when Google Hangouts and Facebook Chat were also XMPP based. Being able to talk to people on another service without needing an account there was a nice thing to have for a few months.
What you maybe see as overengineering, I see as a prerequisite for wider adoption.
These days aren't the old days any more, when you only ever used a native app without e2ee on a computer.
Matrix has a for-profit, venture funded company (Element) that is effectively behind the reference/flagship server and client implementations.
xmpp is far less centralized. Virtually all of the modern clients are single developer projects that live off day jobs and grants.
There are different ways to look at it. Matrix has done a great job at organizing resources to push the platform forward. xmpp has an impressive ecosystem and some incredible client implementations on a shoe string budget, that would probably look/function better and have lots more features given funding parity.
I think as we've seen with other projects like Immich, organizing and recruiting resources is an important part of delivering the modern experiences that users expect today from open source projects. Open source and self-hostable can't be an excuse for missing features.
The accusations of it being overengineered come typically due to the Synapse server implementation being slow. This is basically an artefact of Matrix being quite complicated to provide a byzantine fault tolerant decentralised equivalent to WhatsApp or Slack etc - and time has gone into fixing stability and usability rather than performance. Meanwhile performance is getting better, but progress is slow due to tragedy-of-the-commons related funding challenges. We will get there in the end, though.
Yes it's unfortunate how much Synapse's unperformant implementation has decreased general confidence in the protocol itself. I'm confident it will get better
[1] Conversations for Android and Gajim for Debian.
For the End to End I could try my best to implement it using existing libraries as pieces I can use, but I'm not comfortable doing that.
[0]: https://github.com/snikket-im/snikket-sdk [1]: https://git.sr.ht/~anjan/honeybee
It doesn't have OMEMO in the native builds yet, but that will be happening this year.
We do have voice in the native builds but not video yet.
seems like to contain a reimplementation of the Signal Protocol in Rust - apache licensed.
Also of interest, OpenMLS [1]
So your own code would still be under Apache, and people could follow only the Apache conditions if they only use your code. But combined with the APGL part, the project as a whole would of course have to follow the APGL conditions.
correct