
The perils of federated protocols (2016) - Volundr
https://lwn.net/SubscriberLink/687294/f0e0d89fe4a77b4d/
======
msla
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.

~~~
rglullis
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?

~~~
upofadown
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...](https://en.wikipedia.org/wiki/Comparison_of_instant_messaging_clients#XMPP-related_features)

~~~
stevenicr
> 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](https://news.ycombinator.com/item?id=19216077#19223912)

someone pointed out this chart here:
[https://compliance.conversations.im/](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)

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

------
est31
> 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](https://github.com/signalapp/Signal-Android/issues/6732)

~~~
dTal
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/](https://signal.org/blog/goodbye-encrypted-sms/) [2]
[https://silence.im/](https://silence.im/)

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

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

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

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

