Hacker News new | past | comments | ask | show | jobs | submit login

What XMPP did right:

  - Any chat protocol must be extendable
  - Federation is good

What could have been better

  - 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

Other lessons

  - 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

-------------------

But XMPP isn't dead (and doesn't have to be). New interesting XEPs are being working on:

  - MAM
  - MIX aka MUC2
  - OMEMO



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


It isn't much different from namespaces in programming languages, which most developers do not have a problem understanding.

They are in XML to avoid naming clash, and they do that well. I haven't really seen a different mechanic to solve that problem.


I think the problem with xml namespaces enters in a few ways:

  - 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.


The concept of namespaces in XML is fine, but the implementation... there's an awful lot of twiddly options and details and implementation/API quirks that come up. Throw stuff like XPath and XSD schemas into the mix, and the pitfalls multiply.


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.


> 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.

IMO anything that doesn't have extensibility built in, will gain it after the fact whether you want it or not.

Better to have clear deliniation of duties and a standards body than a hodge-podge of uninteroperable things.


> Better to have a standards body than a hodge-podge of uninteroperable things.

XMPP has both in spades -- that's where the theory doesn't meet the reality. And XMPP is hardly alone; this is a chronic issue with messaging, because the problem space is so ill-defined.

The most successful protocols have been extremely focused in scope. IPv4 is essentially unchanged from RFC 791. TCP has a very carefully curated set of options that has stayed small. For ~15 years, RFC 2616 was the only spec you needed for HTTP. Notice the layering here -- those protocols don't try to be everything for everyone, unlike XMPP's catch-all design.


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.


> that don't work with XMPP: sending pictures, sending voice messages

Any files, pictures, voice, real-time streams (jingle) are all known extensions of xmpp/jabber. I'm not sure what you mean by "don't work".


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


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?


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


While I agree with you I think there is some good that can come of more XEPs. Eventually the good XEP concepts can be taken to create the baseline for a new protocol such as multi-user, multi-device encryption, push notifications, sync, etc.

XMPP as it stands provides a good test bed to find out what the minimum requirements are.


I think it's good: it allows XMPP to evolve as people learn what is good vs bad.

Even if you don't have full compatibility between 2 given clients; it's a hell of a lot more than two completely different protocols.


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.


It's really easy to. Just install e.g. prosody

I run my XMPP server, and IRC bouncer (weechat in relay mode) + a few other misc things all off a $5 VPS.


Where do you host at? Curious what the spec differences are between your VPS and mine, if you don't mind answering


I use vultr, here have an affiliate link: http://www.vultr.com/?ref=6824304 I feel like vultr's $5 VPS is what DigitalOcean should have been...

But you don't need good specs. I used to run prosody off a microcontroller at home; I only moved to a VPS cause my net connection wasn't stable.


Digital ocean!


There are also plenty of free servers - you don't have to run your own. DuckDuckGo, for example, offers free @dukgo.com accounts.


Prosody runs on the original RaspberryPi, so it should run on even the crappiest VPS. It probably doesn't scale to thousands of users and is missing a fancy web GUI, but that doesn't really matter for a private server.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: