And Vector is pretty great too. I had the pleasant experience this weekend of making a new chat room to persistently share photos with relatives this weekend using it. And the Android client is really solid as well.
And Conversations is pretty great too. etc...
If you like XMPP's philosophy of passing stanzas around, XML and XEPs, then use XMPP. If you like Matrix's philosophy of eventual-consistent synchronising conversation history, JSON and a monolithic spec, then use Matrix. Different tools for different jobs.
It's like SMTP and NNTP. You can use both of them to have conversations. They look kinda similar. You can build bridges between them. But they are totally different architectures and philosophies however and there's room in the world for both :)
We renamed the Axolotl Protocol and the Axolotl Ratchet because of the confusion between the two (https://whispersystems.org/blog/signal-inside-and-out/), particularly when people just used the word "Axolotl."
Often when people intentionally continue to use the word "Axolotl" now, it's because they're trying to benefit from that confusion. Olm, however, has been clear about being a different protocol.
In terms of study & scrutiny: Olm and Megolm is still alpha, we're even not using it in earnest in Matrix yet. Things are moving forward fast though, and we're getting a security audit booked in which should hopefully significantly improve our study & scrutiny quotient!
(moxie: did you see my mail? any interest in grabbing a beer next week?)
I tried asking in the group chat as well but nobody seemed to know.
[0]: https://matrix.org/docs/guides/faq.html#how-secure-is-this
Conversations is ok, but Vector is already better because they can focus on usability instead of implementing an inane amount of protocol specs.
Also the bridges to IRC and slack are very helpful.
Oh and running your own matrix server is much easier as it only needs to expose the https port.
I use both. Conversations works well out-of-the-box on Android. I use Vector on my desktop, Matrix Console Android, and Vector Android, but none of them work very smoothly. I'm hopeful they will improve as time goes on as I tend to use XMPP more since I have more personal contacts that I can communicate with via that protocol, but I also like and use Matrix.
You don't seem to be aware, but there was an XMPP<->IRC bridge long before Matrix existed. It was about as satisfying as the Matrix version, though that's still improving.
I'm running my own matrix server (synapse), and my own XMPP server (ejabberd), and honestly ejabberd was easier to get off the ground. Again, I'm hopeful that synapse will improve with time, but I really think there's room for both to exist since they do have slightly different use cases.
ejabberd obviously is much more mature than synapse, but i'd be interested to know where synapse had problems getting off the ground - it's been a few years since I've run ejabberd, but it wasn't particularly fun at the time, and I'd hope that synapse can do better! :)
The present state of messaging affairs is that 99.9% of the market is proprietary spy apps that lock users in to one platform to try to force their acquaintances onto said platform for monetization purposes.
That is an undesirable state to be in for anyone advocating for open and private communications.
So you are either splitting efforts between the two, or saying damn one for the others benefit. I would gladly accept an XMPP implementation that could outpace Matrix / Vector's current performance and accept it wholeheartedly - there just isn't one, and as long as Matrix is at the forefront of usable federated open secure extensible private messaging thats who I'm putting my eggs behind, to the degree where I would say "damn XMPP" only insofar as free software developer hours are precious and wasting them are two different implementations of the same thing (much like Tox vs Ring for secret messaging) wastes a ton of effort that could be better spent making one of the two excellent rather than having two working solutions nobody uses.
You say this as if the truth of this statement was obvious to everyone.
> free software developer hours are precious and wasting them are two different implementations of the same thing (much like Tox vs Ring for secret messaging) wastes a ton of effort that could be better spent making one of the two excellent rather than having two working solutions nobody uses.
That's precisely the reason I work on ejabberd/XMPP rather than just throwing everything away and starting from scratch.
The differences are huge: * SIP is geared up for initiating sessions (hence the name), whilst Matrix is for synchronising data. SIP is heavily modelled after the requirements of the old PSTN phone network. * It's quite an old and fragmented protocol and interop can be a pain, especially between IETF and 3GPP style variants * It has many competing messaging systems layered on it (SIMPLE, MSRP, etc). You have to try very hard to extract a modern chat experience out of them - eg synchronised history, let alone end to end crypto. * Matrix is HTTP; SIP is its own dedicated UDP-or-TCP transport.
Looking at https://tools.ietf.org/html/rfc3261#section-4 this seems to be accurate.
> SIP is based on an HTTP-like request/response transaction model.
The protocol wire format is basically identical to HTTP with verbs, headers, status codes etc. Different set of verb etc however.
You can just about reuse the request/response header & mime parsing stuff (most of which is as much SMTP as HTTP), but the actual stack is completely different - supporting transports on unreliable transports like UDP via three-way handshakes (INVITE -> 200 OK -> ACK), both client->server and server->transactions, different kinds of transactions, registration methods, multiple responses, and all manner of voodoo when it gets to handling all the various types of routing headers. There are two entirely separate abstractions of the stack (ignoring the parsing layer) - the transaction layer (handling those INVITE->200->ACK things that look a bit like HTTP requests but aren't), and then the dialog engine on top that actually the lifecycle of a session (e.g. a phone call).
Random anecdote: a few years a large European telco launched a chat/comms service based on RCS (a GSMA set of standards built on SIP, IMS, MSRP etc). We sniffed the wire to see what happened if you sent the three letters "Hi!" from one client to another. Suffice it to say that it involved 85 round trips and and 54 kilobytes of data (all of which was plaintext, comically) - and this ignored the initial SIP registration. In order to send that message it set up about 3 different sessions (one to send the message as SIP MESSAGE, another to do it again by MSRP (including all the MSRP handshakes) in order to include a typing notification, another to receive the read receipt, etc).
This is why the world needs standards like XMPP and Matrix as a more internetty and less telcoy alternative ;)