# 'The ecosystem is moving' by [[Moxie Marlinspike]] ## Reflections: The ecosystem is moving Main post from [[Signal]] blog: https://signal.org/blog/the-ecosystem-is-moving/ - Talk on [[YouTube]] https://www.youtube.com/watch?v=Nj3YFprqAr8 Software exists as part of an ecosystem, and the ecosystem is moving. The platform changes out from under it, the networks evolve, security threats and countermeasures are in constant shift, and the collective UX language rarely sits still. As more money, time, and focus has gone into the ecosystem, the faster the whole thing has begun to travel. All of this means that the set of expectations users have for social and communication features are evolving rapidly. Anyone building software today knows that it is not possible to stand still. One of the controversial things we did with Signal early on was to build it as an unfederated service. 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. ### Stuck in time In some circles, this has not been a popular opinion. When someone recently asked me about federating an unrelated communication platform into the Signal network, I told them that I thought we’d be unlikely to ever federate with clients and servers we don’t control. Their retort was “that’s dumb, how far would the internet have gotten without interoperable protocols defined by 3rd parties?” I thought about it. We got to the first production version of IP, and have been trying for the past 20 years to switch to a second production version of IP with limited success. We got to HTTP version 1.1 in 1997, and have been stuck there until now. Likewise, SMTP, IRC, DNS, XMPP, are all similarly frozen in time circa the late 1990s. ==To answer his question, that’s how far the internet got. It got to the late 90s.== ==That has taken us pretty far, but it’s undeniable that once you federate your protocol, it becomes very difficult to make changes. And right now, at the application level, things that stand still don’t fare very well in a world where the ecosystem is moving.== Indeed, cannibalizing a federated application-layer protocol into a centralized service is almost a sure recipe for a successful consumer product today. It’s what Slack did with IRC, what Facebook did with email, and what WhatsApp has done with XMPP. ==In each case, the federated service is stuck in time, while the centralized service is able to iterate into the modern world and beyond.== ==So while it’s nice that I’m able to host my own email, that’s also the reason why my email isn’t end-to-end encrypted, and probably never will be.== By contrast, WhatsApp was able to introduce end-to-end encryption to over a billion users with a single software update. ==So long as federation means stasis while centralization means movement, federated protocols are going to have trouble existing in a software climate that demands movement as it does today.== Early on, I thought we’d federate Signal once its velocity had subsided. ==Now I realize that things will probably never slow down, and if anything the velocity of the entire landscape seems to be steadily increasing.== ### Extensible federation XMPP is an example of a federated protocol that advertises itself as a “living standard.” Despite its capacity for protocol “extensions,” however, it’s undeniable that XMPP still largely resembles a synchronous protocol with limited support for rich media, which can’t realistically be deployed on mobile devices. If XMPP is so extensible, why haven’t those extensions quickly brought it up to speed with the modern world? **Like any federated protocol, extensions don’t mean much unless everyone applies them, and that’s an almost impossible task in a truly federated landscape. What we have instead is a complicated morass of XEPs that aren’t consistently applied anywhere.** ==The implications of that are severe, because someone’s choice to use an XMPP client or server that doesn’t support video or some other arbitrary feature doesn’t only affect them, it affects everyone who tries to communicate with them.== It creates a climate of uncertainty, never knowing whether things will work or not. In the consumer space, fractured client support is often worse than no client support at all, because consistency is incredibly important for creating a compelling user experience. For example, even [[GitHub]] has problems with consistency and control right now. They introduced [issue templates](https://github.com/blog/2111-issue-and-pull-request-templates), but a number of third-party GitHub clients don’t support them, so even after creating a [thorough issue template](https://github.com/signalapp/Signal-Android/blob/master/.github/ISSUE_TEMPLATE.md) for the Signal Android repository, we still get people who post “it doesn’t work please help,” because their client never even showed them the template. That makes me annoyed with GitHub, even though I use the official GitHub clients. It’s a potential opportunity for a GitHub competitor that can display issue templates consistently. ### Federation and metadata One potential benefit of federation is the ability to choose what provider gets access to your metadata. However, as someone who self-hosts my email, that has never felt particularly relevant, given that every email I send or receive seems to have Gmail on the other end of it anyway. Federated services always seem to coalesce around a provider that the bulk of people use, with a long tail of small scattered self-hosting across the internet. That makes sense, because running a reliable service isn’t easy, but it’s an outcome that is sadly the worst of both worlds. **If anything, protecting metadata is going to require innovation in new protocols and software.** Those changes are only likely to be possible in centralized environments with more control, rather than less. Just as making the changes to consistently deploy end-to-end encryption in federated protocols like email has proved difficult, we’re more likely to see the emergence of enhanced metadata protection in centralized environments with greater control. ### Federation and control On some level, federation is appealing precisely because it _does_ freeze protocols in time. It’s great when centralized clients and servers roll out features that benefit us, but they could just as easily roll out features that don’t. Federation gives us more collective control over what changes we accept, but that comes with an unacceptable inability to adapt. **Given that federated services always seem to coalesce around a provider that the bulk of people use, federation becomes a sort of implicit threat.** ==Nobody really wants to run their own servers, but they know that it might be possible if their current host does something egregious enough to make it worth the effort.== However, over the past six years, we’ve also seen the user cost of switching between centralized communication services reduced substantially, particularly given the tendency towards addressing with user-owned identifiers like phone numbers. **The device’s [address book is now the social network](https://signal.org/blog/contact-discovery), so using phone numbers as an identifier has reduced switching costs by putting a user’s social network under their control.** In a way, the notification center on a mobile device has become the federation point for all communication apps, similar to how older desktop IM clients unified communication across multiple IM networks. The effect has been visible in the messaging space, where market leaders have come and gone, new popular apps come out of nowhere, and even the most successful players seem compelled to continue iterating and improving their services as quickly as possible. This reduced user friction has begun to extend the implicit threat that used to come with federated services into centralized services as well. Where as before you could switch hosts, or even decide to run your own server, now users are simply switching entire networks. In many cases that cost is now much lower than the federated switching cost of changing your email address to use a different email provider. An open source infrastructure for a centralized network now provides almost the same level of control as federated protocols, without giving up the ability to adapt. If a centralized provider with an open source infrastructure ever makes horrible changes, those that disagree have the software they need to run their own alternative instead. It may not be as beautiful as federation, but at this point it seems that it will have to do. ## Further analysis by [[David Rosenthal]] https://blog.dshr.org/2020/09/moxie-marlinspike-on-decentralization.html Is mostly just a summary of Moxie's video presentation (which differs from the written blog post slightly). The most pertinent paragraph + concluding remarks: ==Finally, if the decentralized system is implemented, deployed and becomes successful, it needs to stay decentralized. As we see with by far the most prominent decentralized technology, blockchains, this never happens. As I described in 2014's [[Economies of Scale in Peer-to-Peer Networks]], very powerful economic forces drive centralization of a successful decentralized system.== As you can see, Marlinspike's arguments are based largely on technical issues, whereas mine are based largely on economic issues. But we agree that the fundamental problem is that decentralized systems inherently provide users a worse experience than centralized systems along the axes that the vast majority of users care about. We each place stress on a different set of factors causing this. Marlinspike makes a strong case that they provide a worse experience even along the axes that the decentralized advocates claim to care about. I make the case that even if they defeat the odds and succeed, like blockchains they will not remain actually decentralized. ## Rebuttal by [[Matrix]] https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom ##### "On Privacy Versus Freedom" From my perspective, the main points proposed in ‘The ecosystem is moving’ boil down to: - Decentralised systems are harder to design and build than centralised ones, as coordination is harder if you don’t have a single authority to trust. - Decentralised systems are harder and slower to evolve than centralised ones, as you can’t force participants to rapidly roll out (or even agree on) new features. - Users in federated systems tend to coalesce around the best/biggest server that the bulk of people use - which means that server typically gets to see a disproportionate amount of communication metadata (who’s talking to who, and when), and has disproportionate power over the network, which could bully others away from running their own deployments. - If users don’t trust their app provider, they can always go switch apps, which gives them freedom. - Open systems are less secure because you have no control over the quality of the implementations - if anyone can bring their own client or server to the table, all it takes is one bad implementation to compromise everyone in the vicinity. Now, all of these points are valid to some extent. **HOWEVER: all of this completely ignores one critical thing - the value of freedom**. Freedom to select which server to use. Freedom to run your own server (perhaps invisibly in your app, in a P2P world). Freedom to pick which country your server runs in. Freedom to select how much metadata and history to keep. Freedom to choose which apps to use - while still having the freedom to talk to anyone you like (without them necessarily installing yet another app). Freedom to connect your own functionality - bots, bridges, integrations etc. Freedom to select which identifiers (if any) to use to register your account. Freedom to extend the protocol. Freedom to write your own client, or build whole new as-yet-unimagined systems on top. It’s true that if you’re writing a messaging app optimised for privacy at any cost, Moxie’s approach is one way to do it. However, this ends up being a perversely closed world - a closed network, where unofficial clients are banned, with no platform to build on, no open standards, and you end up thoroughly putting all your eggs in one basket, trusting past, present & future Signal to retain its values, stay up and somehow dodge compromise & censorship… despite probably being the single highest value attack target on the ‘net. Quite simply, that isn’t a world I want to live in. We owe the entire success of the Internet (let alone the Web) to openness, interoperability and decentralisation. To declare that openness, interoperability and decentralisation is ‘too hard’ and not worth the effort when building a messaging solution is to throw away _all_ the potential of the vibrancy, creativity and innovation that comes from an open network. Sure, you may end up with a super-private messaging app - but one that starts to smell alarmingly like a walled garden like Facebook’s Internet.org initiative, or an AOL keyword, or Google’s AMP. So, we continue to gladly take up Moxie’s challenge to prove him wrong - to show that it’s both possible and imperative to create an open decentralised messaging platform which (if you use reputable apps and servers) can be as secure and metadata-protecting as Signal… and indeed more so, given you can run your server off the grid, and don’t need to register with a phone number, and in future may not even need a server at all. ## Comparison of both arguments https://www.stormfree.cloud/blog/decentralized-vs-centralized ##### "Centralized vs Decentralized: The Future of Encrypted Communication (Part 1)" There aren't many original insights in this one ## [Comments](https://twitter.com/TheBlueMatt/status/1211387967966785537?t=bSpZBsuXISOUsLU49tAE2Q&s=19) by [[Matt Corallo]] Good thread on the benefits of centralization. If you don’t *really* need the change-resistance and shutdown-resistance of decentralization, why bother with all the drawbacks? Ecash failed until it was decentralized due to shutdowns/biz failures, but E2E encrypted msging is fine Sometimes you can even split the difference. Tor has centralized dirauths cause it’s important for them to be able to react to attacks (see new network-health team), but actual relay operation is open, cause those need to be hard to shut down and carry legal risk. ## [Comments](https://twitter.com/SarahJamieLewis/status/1211706508305526784?t=IIIJ4Jny4kcTo1jL_YrVJQ&s=19 ) by [[Sarah Jamie Lewis]] Urgh this is complicated. Some of these thoughts echo my own e.g. https://t.co/neTUakMiL3 but I fundamentally disagree with the approach that Signal is taking. Moxie conflates federation & decentralization. And ultimately Signal will suffer because it isn't flexible. This is one of those protocols > applications. Moxie argues that centralization of power over both is necessary for usability, but this ultimately means that only those with power are allowed to change the system, are allowed to decide what usecases and risk models are worthy. The arguments around signal metadata protection are, quite frankly, wrong & nothing to do with (de)centralization. Most of signals protections devolves to trusting sgx which is demonstrably flawed. The others just straight up don't protect metadata from the service. Ultimately, moxie's approach to privacy requires concentration of power and trust, with few safeguards against abuse. That is untenable. I think hybrid p2p systems utilizing newer maths to limit power from actions is a better path towards inclusive privacy tech.