|
|
Subscribe / Log in / New account

The perils of federated protocols

The perils of federated protocols

Posted May 20, 2016 16:36 UTC (Fri) by aemerson (guest, #104509)
Parent article: The perils of federated protocols

I don't agree with Mr. Marlinspike's claims. Even the supposedly factual ones that federated protocols can't evolve and are stuck in the nineties are surprisingly false. People are evolving IRC (people other than Slack, I might add) it's a better experience with a modern client on a modern server now than it was inthe nineties. It's even better than it was in the twenty-naughties. There have been changes to DNS, changes to HTML, changes to HTTP...

Bringing IPv6 up is just a red herring. Non-Federated Internet Protocol would run the network in some circle of Hell.

Open, multiple-implementor protocols get developed quickly enough, it's the adoption of new work that can be slow. As usual, Network Effects Ruin Everything. Some things, like end-to-end encryption, really can't and shouldn't be negotiated. A flag day really IS the best way to do that.

And federated protocols CAN do that. Developers can remove support for old, insecure fallbacks. (Like SSL libraries have done.) providers can declare flag days and say they'll only federate with the new version of the open, interoperable protocol that has much better security properties so everyone knows when the deadline is coming.

(The claim that federated protocols 'rally around' large providers actually vitiates the rest of Mr. Marlinspike's argument. If there are a small number of large providers they can coordinate. Or a single provider can take the initiative and refuse to support older versions, making the others support them. All the disadavantages of ederation disappear. I'm not necessarily convinced 'large providers' are unavoidable, but if Mr. Marlinspike is, he should throw the rest of his anti-federation views in the garbage.)

Centralized protocols of course have their own problems. You may have noticed, but there isn't much in the way of running Signal on something other than a smart phone (There is an application built into Google Chrome but by all accounts it isn't very good.), or if you have no phone at all. This kind of sucks.

If someone wrote a GTK+ client for Signal or a client to run in a terminal, would Mr. Marlinspike say he doesn't want THEIR project connecting to HIS servers? And he's already ruled out federation? That sucks too, doesn't it?

If I want to make Signal the input or output to a complex pipeline, say filtering piles of messages into interesting places, using some to update displays on my desktop and queueing up some for later examination, extracting information from others, populating an Org mode document with times I plan to meet people, can I? No? Not unless I convince Mr. Marlinspike and the other Signal developers to implement it? (Sure, I could implement it myself, but they do not want Other Projects aon Their Servers and they won't talk to any other servers.) That kind of sucks, too.

Stuart Cheshire turned DNS into an awesome zero-configuration/service discovery (yes DNS-SD can and often does run over regualr DNS not just mDNS) protocol without having to convince the Centralized DNS AUthority to let him. Avahi reimplemented Cheshire's protocol and talks to the original and other implementations. It works wonderfully. They didn't have to talk anyone into it or get told that nobody would interoperate with them. (And people store all kinds of other things in the DNS, too, more variety every year.)

Google sends and receives email from anyone, and they do all kinds of things with email that RFC 822 never mentions (making your flight itinerary automatically pop up on your phone?) and they didn't have to convince the Central Email Authority to implement it for them.

The Suckless people shatter IRC into a whole pile of FIFOs that you can run through the Unix meat grinder however you like. They didn't have to ask the IRC authority.

And where are the awesome centralized protocols of the 2000s? Surely with advantages like these and a popular Internet they must have evolved quickly, leaving everything else in the dust, making ICQ and MySpace the dominant platforms in the market today....?

Thank you, no. If someone starts a project to fork Signal and create a federated version that isn't so wedded to the phone (heck, if they make an open version that let's me use something other than a phone number as an ID, I'll write the desktop client), I will happily donate to a kickstarter or send paypal or anything else to hurry it along.

I'll leave centralized network paradigms to do what they have done throughout history: suck and die.


to post comments

The perils of federated protocols

Posted May 20, 2016 18:03 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

> And federated protocols CAN do that. Developers can remove support for old, insecure fallbacks.
No, they can not. Clients _can_ remove support for _some_ bad fallbacks, after years of gradual deployment. Servers are usually stuck pretty much for a decade (e.g.: SSLv3 deprecation).

So if in your book a decade to make a change is quick, then I don't want to know what is "slow".

> If I want to make Signal the input or output to a complex pipeline, say filtering piles of messages into interesting places, using some to update displays on my desktop and queueing up some for later examination, extracting information from others, populating an Org mode document with times I plan to meet people, can I? No?
You can, nobody stop you personally. However, you should be prepared for your scripts to break at any moment if Signal makes an incompatible change.

That might be OK for a homegrown project that nobody cares about, but if you try that with actual real-life users who depend on your tools...

The perils of federated protocols

Posted May 26, 2016 5:58 UTC (Thu) by madhatter (subscriber, #4665) [Link] (4 responses)

> Clients _can_ remove support for _some_ bad fallbacks, after years of gradual deployment. Servers are usually stuck pretty
> much for a decade (e.g.: SSLv3 deprecation).

# rcsdiff -r1.45 /etc/httpd/conf/httpd.conf
1113a1114
> SSLProtocol All -SSLv2 -SSLv3

I'd have the check my daybook to be sure, but my memory is that it took me less than a decade to type and commit the above change.

The perils of federated protocols

Posted May 26, 2016 6:02 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> I'd have the check my daybook to be sure, but my memory is that it took me less than a decade to type and commit the above change.
Duh. You probably don't have an expensive middlebox in front of your server doing load balancing.

The perils of federated protocols

Posted May 26, 2016 6:35 UTC (Thu) by madhatter (subscriber, #4665) [Link]

I agree that code that's baked into firmware (especially on platforms that are infrequently upgraded by the manufacturer) is much harder to upgrade than code that's deployed in software, but that's equally true on client (eg, think weird android-esque tablets) as on server platforms. That's a pretty good argument for using general-purpose computing platforms for as much as possible, but I'm not sure it argues specifically against servers.

The perils of federated protocols

Posted May 26, 2016 8:18 UTC (Thu) by chojrak11 (guest, #52056) [Link] (1 responses)

> my memory is that it took me less than a decade to type and commit the above change.
Said last person in the world still using RCS routinely...

The perils of federated protocols

Posted May 26, 2016 8:24 UTC (Thu) by madhatter (subscriber, #4665) [Link]

We could certainly have a discussion about the pros and cons of localised-lightweight vs centralised-heavyweight source control, and it might even be interesting, but here is probably not the right place to do it. If you think that my choice of source-control applications has any bearing on my underlying argument, please feel free to argue your case. Do, however, bear in mind Pirsig's dictum that "the world's biggest fool can say the sun is shining, but that doesn't make it dark out".


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds