See also the response from the people who are working on the federated protocols:<p><a href="https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom" rel="nofollow">https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom</a>
This 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.<p>Moxie was explaining why he was doing what he was doing. I doubt it was ever intended as some sort of manifesto.
Hey, 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".
>> but it’s undeniable that once you federate your protocol, it becomes very difficult to make changes.<p>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.
The 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:<p>"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."<p>...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.
Was recently reflecting on this excellent piece comparing and contrasting p2p/federated/centralized systems: <a href="https://changelog.complete.org/archives/10216-the-hidden-drawbacks-of-p2p-and-a-defense-of-signal" rel="nofollow">https://changelog.complete.org/archives/10216-the-hidden-dra...</a><p>The drawbacks for p2p and centralized systems seem to be mostly inherent to the technical requirements necessary for things to function.<p>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!
I think my main criticism of this article is that Signal today isn't proving that this is true.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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).<p>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.
What if you allowed federation, but you centralize updates?<p>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.
Why email, DNS,.BGP, etc don't work? One can wonder!<p>It's good when the clock strikes 13 in the very title of an article; saves time :-/
This 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.
He writes “don’t work” but he seems to mean “aren’t easy to monetize.”<p>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.<p>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.<p>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.
@dang please change the title to `Reflections: The ecosystem is moving (2016)`<p>EDIT: Not sure why I am downvoted, editing is against the site guidelines: <a href="https://news.ycombinator.com/newsguidelines.html" rel="nofollow">https://news.ycombinator.com/newsguidelines.html</a><p>This particular title also feels extremely clickbaity.