11 ms·
Why federated protocols don't work (2016)
- tptacek 5y agoHey, once again: you can't editorialize titles like this on HN. The title of this post --- and it's an extremely well-known post at this point --- is "Reflections: The Ecosystem Is Moving".
- jsnell 5y ago(2016) but equally relevant today. Edit: I originally claimed there was no previous HN discussion, but it was on a different URL.
- detaro 5y agohttps://news.ycombinator.com/item?id=11668912 https://news.ycombinator.com/item?id=11668912 also in talk form some years later: https://news.ycombinator.com/item?id=21904041 https://news.ycombinator.com/item?id=21904041
- deleted 5y ago[deleted]
- AnonC 5y agoThis needs 2016 in the title. Signal can spin stories about why federated protocols don’t work, but the simple explanation behind this is Signal doesn’t want to do certain things. Signal’s unwillingness to avoid doing certain things shouldn’t construed as “hard to do” or “not worth doing” or “too much hassle”. Take every position that Signal takes with a pinch of salt. It is, after all, a centralized platform that benefits from centralization.
- detaro 5y agoyep. for better or worse (it is security-wise), a federated platform has taken over way more of my chatting than Signal ever reached, and Signals insistence on "we know what client people want" plays a large part in that.
- bogota 5y agoI have yet to see a federated chat app my tech illiterate family can download and use. Sure I have set some up to test out but the UX is terrible on all of them. Matrix was the most polished but still horrible compared to signal. Everyone loves to rag on signal here it seems. They would rather something be correct in ideals than help the largest amount of people. It’s a strange and holier than thou stance to take in my opinion.
- stormbrew 5y agoI mean, there was a while there where XMPP-based and federated chat clients (particularly google chat, along with early facebook messenger) were becoming dominant, and were widely used by "normal people" without even knowing it was a thing. So I don't think "it's impossible to make a non-shitty federated client" is really a valid argument. That's not to dispute real problems with wide-open federation or XMPP, because they absolutely exist, just that "the clients are hard to use" seems more an artifact of the resources of the people making them than anything to do with technical merit.
- thfuran 5y ago>So I don't think "it's impossible to make a non-shitty federated client" is really a valid argument. Perhaps not, but it's definitely a strawman.
- deadlyllama 5y agoI wonder if some of what went wrong with XMPP was the big platforms (Facebook, Gmail) adopting it, then dropping it. Coupled with the rise of smartphones and the cloud. Previously you ran your chat app on a desktop PC and it stored your chat history/etc. I imagine federated chat means more opportunities for your users to avoid seeing ads too... Just use someone else's server!
- vel0city 5y agoWere things like Google Chat and Facebook chat actually federated, or did they just allow for XMPP clients to authenticate and have some marginal functionality of the platform? If I was a member on some XMPP server, could I send a message to either platform without having a Google or Facebook account?
- eximius 5y agoYou managed to not address any point in the article, instead insinuating poor motives by the author. I want federation to work. But this is a fair critique of the tradeoff and competition between centralized and federated services - and the dynamics of network switching instead of host switching.
- deleted 5y ago[deleted]
- notriddle 5y agoPlease make actual arguments, and not just Bulverism. After all, building a centralized system and an organization that can run it is the behavior you would expect from someone who sincerely thought it was a better way to make a messenger.
- phkahler 5y ago>> but it’s undeniable that once you federate your protocol, it becomes very difficult to make changes. He opens by talking about how everything keeps changing, the denigrates the stuff "stuck in the 1990s" then complains that you cant change a federated protocol. Not sure what he's in favor of.
- api 5y agoHe is arguing that decentralized systems are incapable of keeping up with the times due to inability to herd the cats. As evidence I would submit that it's 2022 and we are still using IPv4. A centrally managed Internet could have upgraded to IPv6 in one day. Send out update. Everything updates. Done. There is a genuine and IMHO very significant problem here. If this problem can be solved it will require a different approach from the ones already tried. Pretending the problem doesn't exist doesn't help.
- Plasmoid 5y agoI like your optimism but even in centrally managed systems people won't upgrade. I've been harassing other employees to move away from our old Prometheus instance to our new one and it's been a real uphill battle. The only work is (1) copy over the alerts they want to keep to the new storage location. By copy, I mean literally copy. (2) Change the datasource pointer in grafana to the new prometheus location
- Godel_unicode 5y agoCounterpoint, basically everyone who runs them runs up-to-date Chrome and iOS. This is more an argument that some centralized systems are poorly (or perhaps weakly?) managed. Could you not copy their alerts and use DNS aliases and/or load-balancing to migrate them?
- Plasmoid 5y agoWe're trying to slowly reduce the amount of technical debt we've built up. It's not a naive copy and paste for us, since it's possible they've done silly things, but for teams they will understand what the alerts are for. That said, I've had teams forget they had alerts at all or outright deny they owned alerts on their service.
- kixiQu 5y agoSee also the response from the people who are working on the federated protocols: https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom
- dane-pgp 5y agoAnd another response from another person who worked on a federated protocol (Daniel Gultsch, the main developer of the Conversations XMPP client): https://gultsch.de/objection.html https://gultsch.de/objection.html
- tptacek 5y agoIt feels like the steady march of time has convincingly refuted this objection.
- dane-pgp 5y agoI would say it's Marlinspike's position that has aged badly. Despite the supposed innovation benefits of centralised control, Signal still requires phone numbers, and its main "innovation" has been adding a pump-and-dump crypto-coin, which users are forced to have the code for in their clients whether they want it or not, because he refuses to allow non-official clients to connect to Signal's servers. In fact he even objects to people installing the official client from F-Droid.[0] So it seems that in his mind, progress is "whatever direction I decide", and what we call freedom is what he would call "dangerous fracturing of my ecosystem". [0] https://old.reddit.com/r/fdroid/comments/q1jnbb/why_isnt_signal_at_fdroid/ https://old.reddit.com/r/fdroid/comments/q1jnbb/why_isnt_sig...
- hiq 5y agoWhat do your points have to do with the centralized nature of Signal, or the drawbacks of federated networks pointed out by the article?
- 5y ago
- Apreche 5y agoWhat if you allowed federation, but you centralize updates? Make a protocol. Make a server for it. As the central authority updates the protocol, they update the official server software. If someone installs it, it auto updates by default. If someone runs an alternative server software, or doesn’t update, then they will be broken by everyone else’s updates, and that’s just too bad for them. Keep up, or get left behind.
- hbogert 5y agoFederation is also about autonomy, which is at least somewhat at odds with auto-updating. If you all are forced to use the same server software, it's not federation, it's just a distributed app.
- arka2147483647 5y agoWhat if a bunch of servers decide together to stay on the old version? What if somebody decides to clone the software, and manages to keep up? Who pays for the center, and keeps it running, if you have no access to users?
- tommiegannert 5y agoI like that Matrix has a separate system/acceptance test that any implementation can run against to check compatibility: https://github.com/matrix-org/sytest https://github.com/matrix-org/sytest I want any government to help the community set rules, and provide transparency. As opposed to encouraging or implementing mono/oligopolies. One way of using an acceptance test could be to centrally name and shame/fame the various implementations. (Like caniuse.com for web tech.)
- Andrew_nenakhov 5y agoThey absolutely do work, as proven by email.
- notriddle 5y agoYou can use it for communication, and it remains popular by first-mover advantage, so I suppose it “works” technically. But almost everyone is on a few, huge servers that can dictate the standards to everyone else, it’s not E2E encrypted and the few attempts to add E2E encryption are unusable, the anti-spam systems are so strict and flakey that it’s a crapshoot if any email actually arrives in someone’s inbox, and routing emails is based on domain names, which are a terrible way to manage data portability. In other words, it didn’t accomplish what any pro-Federation activist actually wants to accomplish.
- Andrew_nenakhov 5y agoOh again this obsession with e2ee!! Email can be e2e encrypted easily if you want it. The fact is that you generally don't, because you want to access your mail from any device and you want a server-side search. All of this is made impossible by a proper e2ee. Also, proper e2ee requires identity verification of your contacts, where you check their key fingerprints using an uncompromised channel. If you skip this part, all e2ee you use is just a security theater.
- karatinversion 5y agoHow can it be “easily” e2e? The protocol does not allow the sender to synchronously communicate with any host the receiver influences.
- dane-pgp 5y agoProbably the best example of easy end-to-end email encryption (EoEE2EEE?) is Delta Chat[0] which uses Autocrypt[1]. [0] https://delta.chat/en/ https://delta.chat/en/ [1] https://delta.chat/en/help#which-standards-are-used-for-end-to-end-encryption https://delta.chat/en/help#which-standards-are-used-for-end-...
- deleted 5y ago[deleted]
- danShumway 5y agoI think my main criticism of this article is that Signal today isn't proving that this is true. Yes, federation makes all of this stuff harder. Of course it does. There are problems you have to solve in federated systems that you don't have to solve in centralized systems. And it used to be easy to point at platforms like Matrix/Element and say that they were still struggling to get encrypted chat turned on by default, and that was proof that federation didn't work. But in the years since this article was written things have started to change. And now the interesting stuff going on with Matrix isn't E2EE chat, it's P2P encrypted chat, it's using Matrix as a drop-in securely encrypted data-transfer for web apps. It's all of the innovation on how metadata gets encrypted that Moxie claimed was going to come out of centralized platforms, and never did. Meanwhile, Signal is still trying really hard to decide whether or not usernames should exist. It seems clear to me that federation isn't the entire picture, because the federated apps I'm paying attention to are seeing more active development and iteration on user-facing privacy features than Signal is. Separately, I think Moxie's argument that switching costs between networks aren't an issue has not aged well. And I also think Signal itself demonstrates this point; there's a reason why Signal falls back to relying on one of the most insecure messaging protocols in existence, and there's a reason why Signal makes privacy concessions like tying itself to phone numbers and announcing to you when other contacts join Signal. It does that because actually switching costs are very high, and even Signal can't get people off of SMS unless it maintains compatibility with that network. Even Signal as a centralized platform hasn't been able to get people to switch off of literally the worst messaging service we have today on almost every technical level. So my main criticism of Moxie's take is that I see federated systems that are overcoming some of the problems he talks about, and I don't see Signal innovating in that space to the same degree (not that they're doing nothing, just that they're not doing nearly as much). And my secondary criticism is that I think he's dismissive of some of the downsides that come from centralization, including downsides that have hurt Signal's adoption rate among ordinary users. The main reason I like Signal so much is that it is highly audited by security professionals that I trust, that it's been around for a while and proven that it is secure, because it is a small app with less attack surface, because it's seamless on top of SMS, and because I think Moxie is a good, trustworthy coder with solid moral principles about privacy (part of why I'm disappointed to see him leave the company). And all of that is still true today, but since this article was written I haven't seen the level of supposed innovation that I was told was going to happen. It's the federated platforms doing the exciting stuff, and meanwhile Signal is good because it doesn't change much and it still just kind of reliably works the same way it always used to. It's ironically almost the opposite of the situation Moxie claimed was going to exist.
- 6510 5y agousers and consumers are different creatures
- upofadown 5y agoThis doesn't seem all the controversial or even interesting to me. It is perfectly true that a standalone project is easier than one where you have to communicate and negotiate a specification with other people. The idea here was to showcase an approach to cryptography. The Signal project has done a good job of that. It is up to us to decide if we want to modify any of the existing systems based on those ideas. Moxie was explaining why he was doing what he was doing. I doubt it was ever intended as some sort of manifesto.
- jlkuester7 5y agoWas recently reflecting on this excellent piece comparing and contrasting p2p/federated/centralized systems: https://changelog.complete.org/archives/10216-the-hidden-drawbacks-of-p2p-and-a-defense-of-signal https://changelog.complete.org/archives/10216-the-hidden-dra... The drawbacks for p2p and centralized systems seem to be mostly inherent to the technical requirements necessary for things to function. The downsides of federation are more practical (who/how deploys and maintains the servers). Good reminder that organizational structures like technical "communes" need more emphasis!
- jmbwell 5y agoHe writes “don’t work” but he seems to mean “aren’t easy to monetize.” The protocols “work” just fine. It’s making money that seems to require centralization, even by his own examples. And if the making-money part doesn’t happen, the commercialized/centralized service goes away. But guess what keeps running. The open federated protocols. I made this point in another thread. The point of openness and federation is not to prevent failure, but rather to facilitate continuity when central/commercial interests … lose interest. Besides. Try building Signal /without/ using IPv4, or HTTP, or email, or git. And then maybe /thank/ federated protocols for making this little blog post even possible.
- deleted 5y ago[deleted]
- mindslight 5y agoMoxie jumped the shark when he started arguing for reliance on Google Play for better end-user security. He's just got a completely different threat model that focuses on getting users the first 90% by forgoing the last 10%. I personally am less concerned about drive by attackers (oh no, I might have to change my credit card number one additional time), and more concerned about APTs (advanced persistent threats) like Google.
- baryphonic 5y ago> Try building Signal /without/ using IPv4, or HTTP, or email, or git. And then maybe /thank/ federated protocols for making this little blog post even possible. Extremely underrated point. The problem is more a prisoner's dilemma w/r/t monetization than some intrinsic problem with federation.
- jasode 5y ago>but he seems to mean “aren’t easy to monetize.” Signal is a non-profit entity.[1] E.g. Billionaire Brian Acton "donated" (aka 50-year loan at 0%) about $105 million to keep Signal running. If Signal has a monetizing agenda, they're going about it in a convoluted way. [1] https://twitter.com/chrisjbakke/status/1348319406028296192 https://twitter.com/chrisjbakke/status/1348319406028296192 EDIT to reply: >, and from what i've read, Signal does monetize. In precise terms, how exactly does Signal monetize? Every source I found says they're still running on donations: https://www.google.com/search?q=signal+technology+monetize+messenger https://www.google.com/search?q=signal+technology+monetize+m... It's worth calling this out specifically so I can evaluate gp (jmbwell) accusations of Marlinspike's motives to write the essay for commercial gain rather than outline the technical pros/cons of federation.
- namecast 5y agoThe subject line doesn't seem to match with the the post it links to - perhaps it's been updated since being shared here? The blog post right now is titled 'the ecosystem is moving', and in the first paragraph states: "Nothing about any of the protocols we’ve developed requires centralization; it’s entirely possible to build a federated Signal Protocol-based messenger, but I no longer believe that it is possible to build a competitive federated messenger at all." ...which is is a far cry from "why federated protocols don't work". A more accurate headline summary might be "why we believe federated protocols are not competitive for this use case", which has a different ring to it.
- tedunangst 5y agoThe title hasn't changed. HN just likes to twist things around to get worked up about them.
- Naac 5y ago@dang please change the title to `Reflections: The ecosystem is moving (2016)` EDIT: Not sure why I am downvoted, editing is against the site guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html This particular title also feels extremely clickbaity.
- unethical_ban 5y agoThat is far less descriptive.
- deleted 5y ago[deleted]
- nine_k 5y agoWhy email, DNS,.BGP, etc don't work? One can wonder! It's good when the clock strikes 13 in the very title of an article; saves time :-/
- jshen 5y agoIt’s clear you took the time to comment, but didn’t take the time to click the link and commented purely on the HN title which is different than the articles title and point.