Why not Distributed

The argument against distributed social networking architectures

Quite frankly the distributed software architecture does not really lend itself well to social networking applications (yet). Distributed typically requires the user to download a client which does all of the heavy lifting. While this does eliminate the need for server hosting, and admins, it also greatly complicates browser-based, and multi-device utilization very difficult.

The second reason is that federation protocols, such as ActivityPub protocol are being adopted as standards within the social-web. Adopting standards often translates into being able to reach a wider audience. This is because developers, and users alike, are more prone to use technologies which they are familiar with. Strong/medium-strong adherence to standards also helps to ensure that services are able to talk to one another with less effort than trying to translate between proprietary protocols.

Distributed social-network -is- certainly possible, as Patchwork proves. Built on top of the Secure Scuttlebut platform, it allows encrypted end-to-end communications between users. However, Scuttlebut identifies users by the use of a private key in order to identify a given user. This causes two issues (at least).

1. Users will then have to export, and copy/move their private keys to multiple devices (possibly using insecure methods)
2. The timelines will have to be moved as well. OR stored somewhere (no longer "distributed"), and allowed accept connections from multiple places (possibly masking private key/account hijacking).

Both of these issues may already have solutions, but are written according to the authors understanding of the aforementioned technologies.

In the future Banjo might be crazy enough to try, and engineer something in his "spare" time just to prove it to himself. Hell, he's already probably come up with something... for now, we would simply like to stick with federation ;)