Let's assume for the sake of discussion that XMPP has died or is at least on its last legs. What could we learn from XMPP that would help us find its replacement?<p>There are a few key questions that need answering. What did XMPP do right and could be copied? Why did so many big players ditch XMPP? What would it take to get big players to adopt it? What are the existing resources for creating protocols similar to XMPP? Is it possible to simplify a chat protocol or is it complex in nature?<p>I briefly tried working on an existing XMPP server implementation but found the protocol and all the extension overbearing and very hard to grok.
What XMPP did right:<p><pre><code> - Any chat protocol must be extendable
- Federation is good
</code></pre>
What could have been better<p><pre><code> - Regular users don't want to run their own server
- Overcomplicated specs with optional bits (MUC, Pubsub)
- Encryption should be mandatory from the start
- Logging/history is important
</code></pre>
Other lessons<p><pre><code> - Device sync is important
- If you have multiple devices or clients; commit log style is best (see new MIX spec vs MUC spec).
- In the modern world, people are afraid of XML
- 95% of people still don't understand XML namespaces
</code></pre>
-------------------<p>But XMPP isn't dead (and doesn't have to be).
New interesting XEPs are being working on:<p><pre><code> - MAM
- MIX aka MUC2
- OMEMO</code></pre>
<a href="https://matrix.org/" rel="nofollow">https://matrix.org/</a> — Matrix is increasingly looking like the only sensible player; they get so many things right:<p>* Federated<p>* Fault-tolerant<p>* Cryptographic attestations of messages
As you know, there's a lot of good in XMPP. The part that I think causes the most difficulty is that it's based on XML. I don't mean this in the typical knee-jerk XML bashing sense. It's just that XML is ill suited for a stream-based protocol.<p>XML is amenable to extensibility, with its innate namespacing features. But this also made it difficult for beginners to use well and was easy to get wrong. The XML decision was really just a consequence of the times in which it was developed. It was a natural choice. If it were done again, it would be REST-based and use JSON as the data format.
I was under the impression that XMPP was alive and well, it's federation that's dead. Because as it turns out, the big players aren't really interested in interoperability, they want their own walled gardens because that's where you can actually make money.
XML was probably a mistake. Strong, deniable, end-to-end encryption should be mandatory. The Axolotl ratchet is the current state-of-the-art: maybe it does asymmetric things we don't need, or maybe that's helpful.<p>Looking forward: metadata protection. This is a much more difficult-to-solve problem, but existing tools such as Tor are partially successful.
Encryption would be a massive thing to figure out. More precisely, end-to-end encryption with proper multi-device support.<p>That's also something all the other established players haven't solved, so it would be a great advantage to get users.
Putting the format and security aside, isn't the main issue that XMPP was so good that we tried to bite more than it could chew?<p>- Local Federation is great, but Global Federation doesn't benefit the big players<p>- Extensibility is great for domain-specific problems, but it leads to more fragmentation<p>- It tried to handle data streaming, but it's inherently suboptimal at it<p>I mean, it was a great protocol to explore the IM design space, but it was bound to be replaced once we clarified our needs (for the most part, multiple devices and media streaming).<p>As a side note, I often get showerthoughts about mixing IM and blockchain techs. I'm not sure where that would lead us.
We are developing an open protocol, which take the best of XMPP and improve it :)<p>We are for decentralization, the extension of the protocol, but without harm for the users.<p>For web and native clients use thin client connecting to the server via websocket and CBOR. Why not JSON? This allows you not to have problems with sending binary files unlike XMPP.<p>Also thinking about using WebRTC for the transmission of all messages, files and audio/video, but today WebRTC is not supported everywhere.<p>The server has the ability to transport other protocols.
Can any of the new secure-text-messaging protocols, such as the one used by Signal, work in a federated manner? Many of those protocols currently use a central server; which ones actually require that, and which ones don't?
A few weeks ago I replaced a XMPP chat architecture with socketio. It's so much better for my needs (website with realtime chat).<p>There were 2 main reasons in the end:<p>- No way to log all messages sent to a database so that users could retrieve them on subsequent logins
- No way to edit/delete messages, especially in multi-user chats.<p>Maybe these things are possible, but I couldn't find how to do it. Now, with socket IO on nodejs, I have a < 400 line chat server with DB integration that is much more suitable for my needs.<p>I guess XMPP's focus was too narrow.
Would something like ProtocolBuffers[0] or FlatBuffers[1] be a good replacement for XML? The data could then be transmitted in either binary or JSON formats.<p>[0] <a href="https://developers.google.com/protocol-buffers/" rel="nofollow">https://developers.google.com/protocol-buffers/</a><p>[1] <a href="https://google.github.io/flatbuffers/" rel="nofollow">https://google.github.io/flatbuffers/</a>
BEEP on TCP - RFC 3081<p>Any day now...<p><a href="https://en.wikipedia.org/wiki/BEEP" rel="nofollow">https://en.wikipedia.org/wiki/BEEP</a>
IRC - because dead simple & extendable<p>Tox - because fully decentralized & encrypted<p>SIP - because rock solid for voice & video<p>Chat & IM is not the web. It shouldn't be running on HTTP with HTTP APIs.
It's of course possible to simplify a chat protocol. For instance, I'm not sure why the XMPP designers decided to go with XML; it's much more verbose than most formats, and typically slower and more complicated to parse in my experience say versus JSON.<p>What advantage did it have? Unless someone is sniffing unencrypted XMPP packets and finds that XML readability handy, I don't really see the point. And that's an edge case. Not to mention XML's main advantage over many other formats is having hierarchical relationships--but how does that help in a chat protocol?<p>I'm sure someone could very well have counter points to the above, but those are the things off the top of my head that made me question why XML was the top choice here for an IM protocol.