Ask HN: What should replace XMPP?

This is the only other alternative to date I've found that gets those things which I want. It's quite amazing all they're trying to accomplish as it is.

I'm a fan of Matrix.org and very slowly working on an implementation of the client-server API in Rust[1]. In the process of doing so I'm also doing my best to help them improve and clarify the spec. I'd love to see nice native clients for Matrix implemented for the various major platforms. Right now there is vector.im, but I'm personally not a fan of using a web browser for applications I leave running all the time, like chat.

[1] https://github.com/ruma

I really don't want XMPP to die, but I'm worried that it can only go down hill after the big players ditched it.

Is it possible for XMPP to make a major come back without their support? Would big players ever come back or are they too concerned with walled gardens?

  - In the modern world, people are afraid of XML
      - 95% of people still don't understand XML namespaces

I guess that's one way of saying that something is too complicated :)

  - Non XML namespace supporting parsers: these are xml parsers people throw together without paying attention to the fact that attributes starting with "xml" are special and *must* be rejected.
      - This results in people trying to shim namespaces in after the fact; which rarely goes well.
  - There are two syntaxes: `<foo xmlns="urn:example"/>` vs `<myns:foo xmlns:myns="urn:example"/>`. Most people get caught up in the latter without understanding it, and you end up with *lots* of implementations that depend on `myns`, which is meant to be arbitary and can change between serialisation/deserialisation
  - The W3C style for namespace inheritence forces each element to keep a reference to it's parent: a nightmare for simple data structures.

I think the issue of running our own servers would be non-existent if we could run XMPP in inexpensive $5 a month digitalocean servers. It is my biggest drawback for XMPP.

I don't think even more XEPs will solve the problem that there are already too many incomplete / incompatible clients (and servers).

What you clearly forgot were features basically everyone is using today that don't work with XMPP: sending pictures, sending voice messages

> - Federation is good

I think it actually isn't. You're locked in to one server with your account. The server might shut down totally. The server might shut down federation (just like google did). Registering is another step hindering usage, Peer to Peer should be the way to go.

There are two things you need servers for: collecting messages while you're offline and later pushing them to you, having a registration service for a nickname.

At least the first one doesn't require accounts to be bound to servers at all. A model could be that message bouncing servers are run by the app developers. Friends computers that are running could act as bouncers.

Which brings me to xmpp addresses. They're there to be able to initiate contact with someone you haven't contacted before. Nobody is using the username scheme anymore, because it really sucks. Facebook uses a) real names, where you can search somebody with the real name and more importantly uses b) the friends of your friends in suggesting who you could add. You can easily implement the latter feature also for p2p messenger protocols. Other messengers often use other verified usernames like phone numbers, that users already have in their contact book. I don't see how this is possible for a p2p messenger protocol.

> In the modern world, people are afraid of XML

It's just mapping very badly to native data structures in any programming language except xslt. This makes working with XML lots of work. Sometimes this is justified, as XML is a really good fit for the data structure of the document. That's generally the case when you have some text with markup, like HTML or for word processor files. Otherwise it's just an unneeded strain on developers.

Nice list.

> What XMPP did right:

> - Any chat protocol must be extendable

That is a theoretically desirable technical property, but there is a strong argument to be made that extensibility, and the interoperability issues that result, is the Achilles heel of XMPP.

Of course, there is risk the other way around too: by over-specifying, you constrain your use cases, which may hurt adoption.

I'm skeptical that there will (or should) ever be "one protocol to rule them all." There is such a diversity of use-cases, anything that delegates its raison d'etre across multiple specs is going to encounter the same flavor of problems that XMPP has.

> - Federation is good

Definitely another desirable property. Unfortunately, the choice whether or not to federate is often a policy decision, not a technical one. And those policy decisions are not always made simply to keep users siloed: there can be a sound technical basis for them. For example, to mitigate abuse, to immediately extend the service with new features, and to have end-to-end control of user experience without concern for interoperability. Interoperability with arbitrary network elements is often the most frustrating and most expensive part of standards implementation.

For federation to be taken as the default, you need critical mass, and no single IM service has ever achieved critical mass. While it would certainly be nice to have IM standardized like E-mail, telephone calls or IPv4, that comes at the cost of glacial progress forward, and you will be stuck supporting the lowest common denominator for a long time. So there will always be operators trying to short-circuit that baggage by introducing new (and often proprietary) services. The problems of standardization (or lack thereof), in their broadest strokes, are never going away.

> What could have been better

> - Regular users don't want to run their own server

> - Logging/history is important

Those seem like implementation details and not anything intrinsic to the protocol.

What do you mean by "commit log style"? I couldn't really figure it out when looking at the MIX spec.

It you need that, why wouldn't you just tunnel your new protocol over Tor?

Edit: metadata protection, I mean. I'm not disputing the need for encryption.

> Strong, deniable, end-to-end encryption should be mandatory.

Strong end-to-end encryption with perfect forward secrecy should be mandatory. Deniable authentication (https://en.wikipedia.org/wiki/Deniable_authentication), however, seems like a potentially interesting option but not one that the protocol should mandate. Sometimes you do want authentication that remains valid after the conversation ends, so you can subsequently authenticate the messages in it.

Pond uses Tor for metadata protection. Vuvuzela is another recent messenger that protects metadata.

The IM protocol that runs over SIP is called SIMPLE and it's anything but.

Would it be worth it to try to replace XMPP with something very similar but using a JSON based protocol and clean up its worts in the process?

SIP is a signaling protocol (and XMPP can also be used that way). It doesn't really have much to do with voice & video other than it gets used to initialize a connection.

Also SIP is horrible.

XMPP development started in 1998 and so predates JSON. And while it's true that XML is more verbose than JSON, I don't think it's worth redesigning the protocol over.

XMPP predates the first general articulation of JSON by at least 3 years.

> Not to mention XML's main advantage over many other formats is having hierarchical relationships--but how does that help in a chat protocol?

Extendability. Transporting Messages in other messages. Transporting hierarchical data instead of only text.

> - No way to log all messages sent to a database so that users could retrieve them on subsequent logins

This is what MAM does.