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.
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.
Also of interest, OpenMLS [1]
seems like to contain a reimplementation of the Signal Protocol in Rust - apache licensed.
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