1. 7
  1. 5

    federation is hard != federation is impossible

    The author’s argument that standard protocols like HTTP and SMTP have stayed static for 25 years is actually an argument against his theory. When you compare websites or email in 1995 or 2000 to what we have today, one can clearly see that the manner and type of information exchange can evolve rapidly over a static protocol.

    In some ways, yes, the static protocol with it’s decades old built in assumptions can make it harder to write a client and/or server, but in many other ways, it gives you a very solid base on which to build incrementally more complex interactions and push the protocol in ways the authors never intended.

    1. 4

      I’m still not buying that argument.

      Just to start with this, to make it very clear: Federation does not necessarily mean multiple implementations. There is no reason federation would require that.

      Now, I am totally on-board with the fact that XMPP is terrible, but…

      • Signal is basically not changing anyway so they don’t even really need that property.
      • Matrix is achieving a decent amount of ecosystem change by providing canonical clients. (Not that Matrix is particularly great but at least that aspect seems to be working well.)

      So it really seems like, if you want to make a federated system (with alternative implementations):

      1. Make an implementation for every platform, so you can point general users to one which gives a good user experience. It will also be a standard for alternative implementations to be measured against.
      2. Don’t introduce a lot of changes. This actually seems to be plausible for messengers because they are very well known by now. It’s also to some degree required because if your system is too much of a moving target alternative implementations may not be able to keep up.
      3. Make it easy for people to figure out how to create an implementation and to be notified of changes they need to make.
      4. Make it easy for people to figure out when an implementation does not support something. To make this more manageable, go for a simple system with increasing version, avoid add-ons and optional features. (Or, you know, just rename things into Email 2.0 or whatever.)
      1. 3

        As soon as you let other people host server software, you get several implementations, at least “the old version” and “the new version”, because you cannot force people to update (nor can you expect that everyone would update in any reasonable amount of time).

      2. 3

        There’s also a video (2019): “36C3 - The ecosystem is moving” https://www.youtube.com/watch?v=Nj3YFprqAr8