XMPP is great, NOT a JSON hellhole, and has its own implementation of Axolotl for private messaging: https://conversations.im/omemo/

And Conversations is pretty great too. etc...

Honestly, there isn't a big XMPP v. Matrix thing (or at least I wish there wasn't). A good example is on the Olm side of things, where the OMEMO guys are investigating whether there's value in using Olm as their double ratchet implementation: https://github.com/anurodhp/Monal/issues/9#issuecomment-2080... etc.

Then why, every time XMPP is mentioned, do droves of people praising Matrix and bashing XMPP show up out of nowhere?

I guess an overabundance of enthusiasm from the wider Matrix community, i guess. Speaking on behalf of the Matrix core team, we genuinely wish the XMPP community the best - for as long as Matrix & XMPP end up interoperating nicely, we're working towards the same goal of open communication. Hell, I spend most of my life atm wandering around wearing an XMPP hoodie!

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 :)

Just to be pedantic, there is no such thing as Axolotl. Olm is a new protocol, different from Signal Protocol, that uses the double ratchet internally for part of its function. However, they've made other design decisions that are different from Signal Protocol and may have received less study or scrutiny at this point.

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.

Just to echo (again), Olm is indeed an independent C/C++ implementation of the double ratchet, and we've been avoiding the overloaded term 'axolotl'. Olm has recently added a group ratchet on top called Megolm which diverges significantly from the Signal protocol, as it's optimised for Matrix's specific use cases of (optionally) syncing and decrypting existing history onto new devices, which obviously comes at the expense of PFS.

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?)

Any news on how the e2e support is progressing? The FAQ [0] says "End-to-end encryption is coming shortly to clients for both 1:1 and group chats to protect user data stored on servers, using the Olm cryptographic ratchet implementation. As of October 2015 this is blocked on implementing the necessary key distribution and fingerprint management." and I can't see much floating around on Github.

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

E2E is our main focus at the moment - sorry for missing the question; we must have missed it. There's nothing on github as the E2E stuff is all hosted on https://matrix.org/git/olm. The FAQ is old - we have finished the 1:1 ratchet and group ratchet and almost all the key distribution stuff. Currently wiring it into all the SDKs and checking it works and then getting it audited. We should be ready to yell about it in N weeks where 2<N<5.

Matrix will eat XMPPs lunch.

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 think both have a place in the world (as another comment pointed out, similar to NNTP vs SMTP). Does it really need to be an "us vs them" eat each other's lunch kind of a deal to you?

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.

What are the main not-working-smoothly problems you're seeing with Vector Web/Android out of interest? Matrix Console is very much a raw dev-focused app on top of the SDKs, but at this point in its life Vector should be relatively polished...

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! :)

Of course. I think competition is good and my words were not meant as us vs. them although in hindsight I see that they sound like it.

> Does it really need to be an "us vs them" eat each other's lunch kind of a deal to you?

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.

> as long as Matrix is at the forefront of usable federated open secure extensible private messaging

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.

To be fair, XMPP and Matrix are very different beasts (even if you can use them both for chat). From the Matrix perspective, it's great that Conversations exists and shows that XMPP works well on mobile. It makes it even more important to have a good XMPP<->Matrix bridge if anyone reading this feels like helping progress one :)

I looked at Matrix before but it was easier to just roll with a custom MQTT server. Obviously this isn't a solution if you need true federation but I'd argue most don't.

Yup, if you don't need federation, message history, e2e crypto, etc then there's little point in Matrix (or XMPP). +1 for using the right tool for the job :)

How does SIP compare to Matrix? Are they even the same kind of thing?

The similarities are that you can use them both to set up federated voip calls and instant messages. SIP is still the standard way for doing interoperable VoIP on the net.

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.

I remember SIP as being very HTTP-like.

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.

Superficially it's HTTP-like, but just enough to give you a false sense of familiarity. (For context, we spent ~10 years writing commercial SIP stuff before ditching it all in favour of Matrix).

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 ;)

Thanks. Matrix seem to to be the way to go, then, at least for text chat. What about audio and video?

Matrix does voip too (Console and Vector implement it using WebRTC as the transport) but it's not as mature as SIP. It's fine for casual use but you wouldn't want to run a telco off it yet :) That said, it's roughly 20x easier to develop on than SIP ;)