The perils of federated protocols (2016) | Hacker News Reader

The perils of federated protocols (2016)

lwn.net

62 pointsVolundr13 comments

The benefit of a federated protocol is the same as the downside: No dictator.

Nobody can say that this good feature is now present everywhere, for everyone, at all times, and nobody can remove a good feature or add a bad feature in the same fashion. You can't mandate end-to-end encryption and you can't mandate that everyone who is using end-to-end encryption will use an algorithm which is backdoored.

It's also sort of like email, HTTP or JSON in that having a clear minimal feature set and good design would have been en extremely nice thing to start with; but everyone is better off for having an open platform to communicate with right now.

What I'd like to see is some kind of unofficial, periodic publishing provided by the (say) top 3 vendors that implement a given protocol where they would spec a common profile and define the basic integration test suite - sort of like the CSS Acid tests.

Let's take the example of XMPP: the top server implementations could agree that in 2019 all of the servers should support XEP-{A, B, C, D}. In 2020, XEP-E and XEP-F could be added. In 2021, XEP-B can be superseded by XEP-G...

As it is now, it seems that most vendors want to compete and try to take whatever little market is left for XMPP. If instead they decided to collaborate, it would help immensely client application developers, they know that the important thing would be to ensure that they support the current profile.

My guess is that could lead to some kind of concentration of power and force smaller vendors into spending resources in Keep-Up-With-The-Joneses mode, just to get close parity. However, given that the protocol is open and most interesting implementations are open source, this doesn't seem too different from other technologies - how many different FOSS http/mail/amqp/ssh/RDBMS projects are there, and how much of a Pareto distribution do they follow?

I think the interoperability issues mostly happen on the client end with XMPP. The popular open source servers support most anything that anyone would want. The problems are with stuff like video and audio chat ... and interoperable end to end encryption for clients that still don't support OMEMO. So you could work on a set of client capabilities for voice/video chat. Such a minimum requirements list would help with all voice/video, not just XMPP.

A relevant grid of XMPP client capabilities:

* https://en.wikipedia.org/wiki/Comparison_of_instant_messagin...

> issues mostly happen on the client end with XMPP.

from what I have seen in comments over the years is that it's been spotty to make it so you could depend on things working / being delivered to the other (federated) clients - as most do not accept the same feature set as each other.

I had suggested that a chart is made of all the clients along with which features are not yet implemented there, along with the programming language they are written in. This way it should be possible to estimate the amount of hours to add all features to all clients, then estimate the cost - and maybe we could crowdsource the amount of money or volunteer hours to get most clients to reciprocate most feature interoperability.

When I mentioned this here: https://news.ycombinator.com/item?id=19216077#19223912

someone pointed out this chart here: https://compliance.conversations.im/

Which I found interesting and was not aware existed.

I'd love to see xmpp, the clients, and matrix and it's clients all get more streamlined and user friendly. (signal too)

It is interesting how the greatness of the conversations XMPP client has sort of created a defacto baseline. You have to go half way down the list before you get below 90% compliance.

The thing with an open protocol is that there is always going to be a vast number of clients that don't support much of anything. We really only need one really good free client on each major platform.

https://xmpp.org/extensions/xep-0387.html is more or less trying that, and I think the active developer teams are following it.

> Those who want to communicate with other Signal users but not with Google servers are shut out.

Note that while this technically isn't the case any more, as you can use Signal without Google services now, Signal still creates a background task which periodically checks for updates and you can't change the frequency. This results in the GMS-free version to be a major battery drain [1]. Ultimately, this was a deal breaker for me and I removed Signal after testing it for a while on my smartphone.

[1]: https://github.com/signalapp/Signal-Android/issues/6732

You know what would be really cool, is if Signal supported encryption over SMS. Then you could communicate without the cooperation of either Google or Signal's own servers! And no battery life impact!

...except it did. And they killed that feature, justifying it with a bunch of really weird arguments [1]. Like that SMS always leaks metadata, when Signal's data protocol also leaked the same metadata - except only to them, instead of a federated network. But don't worry, they promise they don't log it. Honest.

I don't trust Signal at all after that. Use SilenceIM for encrypted messaging [2].

[1] https://signal.org/blog/goodbye-encrypted-sms/ [2] https://silence.im/

With federated protocols, ideally, many would be running their own servers.

In reality, users tend to concentrate in one or two servers. And then federated is about as good as centralized.

Reminder of what happened with XMPP: It got embraced, extended and extinguished... by Google.

We should be moving towards fully distributed architectures. Only when there are no servers is this problem really gone.

This isn't always true. The phone system remains well federated, even within a single country. Email is likewise hanging on, although gmail is very popular. IRC is an interesting case, where "networks" have federated servers that load balance completely transparently.

Well, maybe Marlinspike should consider just not moving so fast. There’s something to be said for stability. (Cue Debian.)

On the other hand, I do strongly agree that the extensibility of XMPP basically killed off Jabber. I’m back to just IRC except for a (non-federated) work-internal server, and occasionally (say twice a month) firing up a Jabber client to get a message through (though I mostly eMail those people instead).

I have always wondered why older social networks like Frienster and Myspace that are in decline not decided to band together and federate their services or parts of it to regain critical mass and stay relevant.

Reply on news.ycombinator.com