The perils of federated protocols

That's a really good point. However stunted and slow the evolution of HTTP has been, the browser environments have evolved quickly. And though complex websites might not render correctly, or at all, on the vast majority of browsers (e.g. think Lynx, Netsurf, etc), all that matters are the browsers from the big 3 or 4: Microsoft, Mozilla, Google, and Apple. And for the most part, at any one point in time it has been one of those vendors leading the way forward.

A new federated framework could pick up steam as long as there was one or a few primary implementations that the vast majority of people used. Those implementations don't have to become bogged down in interoperability as long as there was some kind of tacit understanding by users that interoperability problems were the fault of marginal implementations dragging their feet, as is the case with browsers. An end-user might not have any understanding of the technology, but the vast majority still understand the concept of switching client software. However slow, that's a significantly faster process in reality than administrators upgrading backend software, despite the fact there are far fewer backend systems.

I think the underlying mechanism here relates back to the end-to-end principle. Put as much of the logic as possible at the end nodes, keeping the transport layer as simple as possible. That was one of the flaws of XMPP, IMO. Too much logic exists in the server-side code[1]. But server-side software is much less responsive to user complaints. Corporate and ISP IT departments aren't especially well-known for quickly upgrading servers to support fancy new users features, whereas users will naturally migrate to client software providing the better experience.

OTOH, designing protocols and architecting software which minimize dependencies on intermediate nodes is very difficult. It's just too easy to put logic in the middle, especially when you're on a time crunch. And if you're furthering proprietary interests, well then it's a no-brainer.

[1] For example, I never understood why anybody ever thought it was a good idea to use out-of-band channels for XMPP file transfer and voice, or to use in-band channels which relied on server support. I understand performance concerns, but it was destined for failure rather than failure only being a possibility. Those decisions created dependencies that required a substantial number of server systems upgrading, and upgrading responsively in step with user preferences. The only way intermediate nodes get upgraded like that is when they're centrally controlled.

When XEPs emerged which were more server agnostic, there was no predominate client side software which carried the day. Google's Jingle failed, I would argue, because support was never added to libpurple. If Google was serious about it, they would have added it to libpurple, or forked it and took the lead in pushing features to XMPP clients. Though, my knowledge of the history of this is limited so I'm probably missing critical details. My analysis may be factually wrong, but I think my point is valid.

Quite so.

Marlinspike carefully phrased his mention of HTTP to dance around the fact that HTTP/2 is being deployed right now (and experimental predecessors have been deployed for years). That section of his post is deliberately misleading.

He's right that decentralized evolution imposes costs, including delays. But he's not right that centralized always wins.

The web is a server-to-client protocol, not peer-to-peer. What would the equivalent be for messaging? An app in which I type a message and a receiver and which tries all known protocols and servers to try to deliver it?

Actually, why not? Security and secrecy would be acceptable if both parties wanted it, and you would have the convenience of having one app for all communications. Not much lost: if your partner does not value secrecy, the best protocol in the world will not stop them republishing your message over a different medium.

These things seem to come in waves. Most of the reasons Federation of protocols in RFC's came up was due to the fact of the many walled gardens of proprietary mainframes kept various people from being able to inter-operate. This was the 'cloud' of the 1960's and 1970's where it was really convenient to be able to do something with someone else on a similar IBM 7030 but woah if you tried to communicate with the guys down the hall on the PDP-8 or the Burroughs. And then it became more important when various 'features' you had your system built around changed underneath you. So that feature you had come to rely on for communication on the 360 ? It doesn't work the same way or is a paid upgrade on the 370.. However there was a lot of ability to also innovate and figure out what features were useful and which weren't during this time also.

I expect that once Google does a spring cleaning, figures out a way to charge for certain features that make using their closed garden useful, or it turns out the metadata being shared was a useful sidechannel for the real communication.. then there will be a push for a federated protocols. By that point hopefully the things that people know will be useful or not are known.