Multiple other protocols have been proposed for decentralised social networks. It is worth comparing SPXP against a selection of popular alternatives, investigate the differences and discuss why these do not fulfil the design goals we are looking for with SPXP:
- individual sovereignty
- privacy
- security
- simplicity
To see how SPXP addresses these requirements, see here. There is a list of challenges and features NOT supported by SPXP at the bottom of this page.
ActivityPub uses a federated architecture. Users can freely chose their "home instance" from multiple available instance. To participate, the user needs to create an account on this home instances. It is possible to communicate with users beyond the home instance via federation. Data, like profile information or individual posts, is replicated as needed between instances.
- Your ID is bound to the domain of your home instance
- You don't have full control over your own profile
Instance owners can close and delete your profile at any time and at their sole discretion - and sometimes even close the entire instance. All your data and connections will be lost, at least since your last manual backup. Profile migrations are an afterthought and only possible if the instance owner collaborates.
This is a violation of the individual sovereignty we are interested in. - You don't have full control over your own timeline
Instance owners block content from other instances at their sole discretion. Accounts on blocked instances will not be able to interact with you and you won't even see their content. This content moderation has some positive impacts, e.g. for blocking spam and fighting harassment.
However, since you don't have control over this content moderation, it is a violation of the individual sovereignty we are interested in. - The authenticity of your data is not guaranteed
Without real end-to-end digital signatures, it is possible to tamper with existing messages or completely forge them.
This is a violation of the security we are interested in. - Your data is fully accessible by instance owners
This includes absolutely everything and is a severe violation of the privacy we are interested in. - You cannot control how your content is used
As a federated protocol, it requires your data to be replicated between different instances. This also happens outside of your control, e.g. if someone "boosts" (re-tweets) your post. Other instances in the Fediverse will display your content on their website, under their own terms and under their exclusive control.
This is a violation of the individual sovereignty we are interested in. - You cannot limit the visibility of your content
Sure, there is content you are happy to share with the whole world. But there might be other content you only want to share with your friends or your family. This is not supported in ActivityPub. Everything is publicly visible (except DMs).
This does not provide the level of privacy and security we are interested in.
Many of these aspects are caused by the federated architecture. Real privacy can only be guaranteed by end-to-end encryption. But without being able to understand the content, the instance would not be able to organise the content for you.
The Authenticated Transfer Protocol is very similar to ActivityPub. It is using a federated architecture consisting of Personal Data Servers (PDS). Just like ActivityPub, users freely chose their PDS and create an account. Although there are technical differences, we see very similar findings in regards to the design goals we are looking for:
- The handle is bound to a DNS domain
- Although your profile is defined by a DID document, you cannot easily transfer your handle to a new PDS
- You don't have full control over your own profile
Just as in ActivityPub, an PDS owner can decide to close your profile or the entire service at any time.
This is a violation of the individual sovereignty we are interested in. - You don't have full control over your own timeline
Just as in ActivityPub, your personal feed is generated by your PDS.
This is a violation of the individual sovereignty we are interested in. - Individual information pieces are not digitally signed
There is a mechanism to digitally sign the entire profile as a whole, but not for individual messages. - Personal Data Servers (PDS) owners have access to all your data (there is no end-to-end message encryption)
This includes absolutely everything and is a severe violation of the privacy we are interested in. - You can probably not control how your content is used
At this point, there is only one instance of a PDS. How federation between different PDS is going to work is not yet fully clear. As a federated protocol, it is very likely that it will have similar characteristics as ActivityPub. This is a violation of the individual sovereignty we are interested in. - You cannot limit the visibility of your content
This does not provide the level of privacy and security we are interested in.
The AT protocol is pretty new and is currently seeing a lot of changes. It is possible that the above analysis is no longer accurate. We will try to keep up with the recent developments and update this section accordingly.
However, as a federated architecture, it suffers from the same generic problem: Real privacy can only be guaranteed by end-to-end encryption, which prevents the PDS from managing the profile for you.
Nostr (Notes and Other Stuff Transmitted by Relays) is an interesting candidate. It solves many of our requirements in a quite similar manner. However, it only provides public posts and does not go as far as SPXP in terms of privacy and sovereignty matters:
- Profiles are bound to a cryptographic keypair owned by the user, making them portable
- Information is published through relays
You can freely chose an arbitrary set of relays to publish. Other users will receive your updates as long as they listen to at least one of the relays you are publishing on. - Events are end-to-end signed, guaranteeing message authenticity
- All messages are public, except for direct messages
This does not provide the level of privacy and security we are interested in. - You cannot limit the visibility of your content
This does not provide the level of privacy and security we are interested in. - Relays have too much information about you
This does not just includes public messages (obviously), but also metadata of private messages, all profiles you are following and all discussion threads you are reading (via filter conditions).
This does not provide the level of privacy we are interested in. - No guaranteed event durability
Relays can chose to keep events only for a limited period of time - unproven scalability
While this protocol and it's relay architecture is pretty new, it has not yet proven that it can operate at scale. This includes horizontal scalability where clients need to deal with a landscape of thousands of relays as well as vertical scalability where relays need to handle millions of clients concurrently.
In a nutshell: Nostr is inherently open and public (everybody can read messages, everybody can reply to all your posts) while SPXP focuses on privacy and sovereignty (fine grained control over the audience, end to end encryption, full control over replies to your posts).
One of the main critiques with the big established social networks is their vast collection of user data. The same critique applies to Nostr relays. The same amount of data is generated at relays and relay owners can mine, analyse, use and sell this information.
By radically pushing power and control from the network into endpoint devices, we face a new hard requirement:
You need a fat client to fully participate.
It is possible to read and display public content with a very simple client. In order to fully participate with your own profile in connections, to read private encrypted posts and to contribute with comments to other profiles, the client needs to implement a fair amount of logic.
With ActivityPub, a simple web browser is already sufficient. This does not work with SPXP where you either need a client app like the HeyFolks app or you need to sacrifice comfort and functionality when viewing JSON objects in a browser.
There are a couple of features commonly provided by social networks which are either deliberately not available or not available yet in SPXP:
Sharing / Re-tweet / Boost
It is quite common in popular social networks to re-post an existing message on your own account. With digitally signed posts, SPXP
could provide fully authenticated re-posts by including the entire original message.
However, we have not yet made a final decision wether this feature has more good or bad implications. We are interested in scientific research on this topic and it might be added at a later time.
Publishing replies on your own feed
In other social networks, it is quite common that your followers can see your replies to other posts on your profile. With SPXP, we
made the deliberate choice that the entire discussion is "owned" by the author of the original post (like in a discussion forum). It is possible, and likely will be quite
common, that replies to a post are encrypted and only visible to a limited audience.
If your profile is connected with both, the authoring and the replying profile, then you will be able to see the original post and the reply and your client can notify you accordingly.
At mentions
When you mention another profile in a post, it is a quite common feature that the mentioned profile gets informed. At this point,
we decided against this feature to prevent spam. There are already some ideas how we could give profile owners better control
over being mentioned.
See also our Feature Idea Collection.