Federated Social Protocols: Nostr, Secure Scuttlebutt, Farcaster, ActivityPub

Nostr has been getting a lot of attention lately. With the support of former Twitter CEO Jack Dorsey, the client Damus once entered the top ten downloads in the Apple store, and its registered users are said to have exceeded one million. A few days ago on the Web3 101 podcast, I talked about it and Farcaster, Secure Scuttlebutt, and ActivityPub, several federal social protocols, just to write down some background and ideas.

Nostr

Nostr was initiated by anonymous developers in the Bitcoin community. Many early developers and users are Bitcoin supporters, and some clients have also integrated Bitcoin's Lightning Network. This caused some people to mistakenly think that Nostr is based on the Bitcoin network, and it also made many people pay attention to the Bitcoin ecology.

The network structure formed by Nostr is federated, which is the same as that formed by several other protocols. A federated network consists of many servers that join freely, and users connect to one or more servers through their own clients. The email system is a federated network, and so is the blockchain, but servers are called differently in each system. It is called relay in Nostr, hub in Farcaster, pub in Secure Scuttlebutt, and instance in ActivityPub.

Nostr's design is extremely simple, at the expense of flexibility. The basic idea is that the communication between clients uses the relay server (relay) as a bridge to confirm each other's identities through cryptography. The relay server is online 24 hours for the user, but because the identity is obtained by the public key, it is very easy for the user to replace the server, and multiple servers can be used at the same time.

Its most special place is that there is no communication between servers. This means that two users can only communicate with each other if they are using the same server. This aspect simplifies the protocol, does not require global consensus, and does not require trust between servers. On the other hand, this also means that the server will have a strong Matthew effect, because people can only communicate when they share the same server.

Compared with Nostr, another recently emerging protocol, Farcaster, is much more complicated and has many more problems to solve.

Farcaster

In Farcaster, the servers communicate with each other through the gossip sub protocol , and jointly maintain the state of the social network by updating the delta graph . Delta graph is a data structure designed by Farcaster and a new consensus algorithm, which allows the entire network to have a consistent state, and each server only needs to save part of the data.

In addition to the delta graph, another interesting aspect of Farcaster is its identity system. Through integration with Ethereum, user identities in Farcaster consist of Ethereum addresses and ENS-like domain name systems, as well as an ID in Farcaster smart contracts . This ID is designed to allow users to retrieve their identities through social relationships and other means when they lose their private keys.

Whether it is a new consensus algorithm in Farcaster or a distributed identity with a built-in retrieval mechanism, they are very ambitious, but the actual effect is still unknown. Another protocol, Secure Scuttlebutt (SSB), has gradually matured before the concept of Web3 emerged.

SSB

The design of SSB is very elegant and ingenious, loved by many developers. It is mainly designed for point-to-point communication. The network nodes are all users' clients, which store the information of users and friends locally, and send and obtain information through the gossip protocol. In actual use, users often follow each other with supernodes called " pub ", which relay information and discover new content for users. This actually forms a federated structure similar to Nostr, except that users can still communicate peer-to-peer.

The design of SSB for point-to-point communication makes it more complicated than Nostr, which increases the threshold of the client on the one hand, and on the other hand increases the constraints on the usage scenarios of federalism. For example, if the client is a web page, it is necessary to greatly change the idea of local priority of the SSB client. Those scenarios where SSB is truly irreplaceable are more extreme, such as when the Internet is completely unavailable, its peer-to-peer communication is still available.

The first version of SBB was released in 2014, and it has had a stable user group for many years, and it is conducting real exchanges, rather than just focusing on the products and protocols used. However, from the perspective of landing scenarios and users, the more successful protocol is ActivityPub, especially the software Mastodon that uses ActivityPub.

ActivityPub

The first version of ActivityPub was released in 2018. It was designed with the experience of software such as GNU social in Fediverse and protocols such as OStatus, and it is a recommended standard of W3C. Now, Mastodon alone has more than 6m users, and people can find active communities formed around various topics on it.

The idea of ActivityPub is simple and straightforward. Each server (instance) is similar to an email server, helping users receive and send letters, and host identities. It standardizes the communication between servers, allowing freely joined servers to communicate with each other; it also standardizes the communication between clients and servers, allowing users to access different servers on the same APP. This gives server operators and users a lot of freedom.

The problem with ActivityPub is that the user's identity and data are bound to the server and are difficult to migrate. Servers are generally run on a volunteer basis, have no business model, and are not very durable. Once the server is stopped, the user's identity and data are lost. In contrast, the other three protocols all use the user's public key as the identity, and save data in multiple servers, and migration is relatively easy.

ActivityPub / Mastodon has another feature, each server is a community; the community is a very effective way of self-organization, but the server as the foundation of the community raises the threshold for creating a community, because creating a community means operation and maintenance server. As a result, the community diversity on Mastodon is still not as high as that of centralized products such as Reddit and Douban.

However, the other three protocols mentioned here have not yet evolved into a community. In theory, SSB's pub and Nostr's relay can also be used as a community, but this will also face the problem of community threshold.

What kind of protocols are valuable for distributed applications?

Both the Matters team and users have put forward ideas on how to transform Matters' social network into a confederal structure, allowing users to set up their own servers to join. A natural question is how people and content interact across different servers. Before Nostr, the most reliable way is ActivityPub, the standard is mature and widely used.

Nostr brings a new idea: different servers do not need to interact. The social network is split into many overlapping but independent slices, and users can choose which slices they want. Where global state is needed, it can be supplemented by other protocols and technologies, such as referencing media files through content addressing, or running economic systems and content discovery through blockchains. Nostr has not had time to mature in practical applications, but the high simplicity of the design means that it has enough room for evolution.

However, for applications that already have users and communities, there seems to be no incentive to adopt Nostr. With Nostr, functional iteration is limited by Nostr's current standards and clients, and users are more likely to migrate to other clients or servers; at the same time, it does not expand the original social network, nor can it add new functions for users .

On the other hand, the use of ActivityPub, especially the communication standard between servers, can expand the original social network; because it can communicate with other servers, users can reach more people. However, in order to realize a global identity system and content network that is user-independent and easy to migrate, ActivityPub must be greatly changed, and part of the ability to interoperate with other clients has been lost. However, most of these problems can be made up by other more mature protocols, such as Ethereum address as identity and IPFS fingerprint as content ID.

The design idea of ActivityPub comes from Fediverse , a social network that has existed since the beginning. The idea is also very simple: a group of servers form a divided network to send and receive information to each other. This line of thought, from different software such as GNU social to Mastadon, and from different protocols such as OStatus to ActivityPub, has accumulated nearly two decades of people's experience in exploring distributed social networks, and has strong scalability.

The popularity of Nostr only lasted for a short time, and the topics and content that appeared in a short period of time still did not break away from Nostr itself. The usage scenarios are not real enough, it is difficult to explain how much Nostr meets the needs. However, more than 1M people tried it in a short period of time, which shows that many people have suffered from the traditional centralized social network and are looking for new options. This is a prerequisite for the development of a distributed social network, and it is the most interesting point in the story of Nostr's outing.

The extreme simplicity of Nostr itself also makes this experiment worthwhile. Regardless of whether a new social network paradigm can be formed in the end, it has already done what the ingenious design of Secure Scuttlebutt and the capital investment of Farcaster failed to do, and provides an extremely simple idea for distributed social applications.