1. Fediverse is a fancy word and has an air of intellectual sophistication. But unfortunately, a small group of people worked on developing the concept and protocols and the rest of us have adopted them without much critical analysis. Indeed some have religious devotion and defend them without any thoughtful reflection. Since there are a lot of new users here and would invariably hear the phrase fediverse, I decided to get on my soapbox.So here goes.

2. First let us settle on what is meant by Fediverse and why it has captured people’s imagination. This is what Wikipedia says: “The Fediverse (a portmanteau of "federation" and "universe") is the ensemble of federated (i.e. interconnected) servers that are used for web publishing (i.e. social networking, microblogging, blogging, or websites) and file hosting, but which, while independently hosted can mutually intercommunicate with each-other.” en.wikipedia.org/wiki/Fedivers

3. Conceptually, it is easy to see why Fediverse is preferable. We can have our own servers and still be able to share our content with others. It is the ultimate “have a cake and eat it too”. No single entity to rule us over and monetize using our data.

4. Unfortunately, if we scratch the surface and peek into details, we see that the objective is undermined in every step. More than a dozen years back, independent of these efforts, I had developed a platform that we can self host and still be able to share content with our friends while owning our data. My objective here is to compare and contrast the two approaches.

5. As we design a fediverse, we need to consider the privacy and security concerns of a specific user A. At any time A can have interaction with her server S1, a friend B, or his server S2. The degree of trust relationship amongst them is context and time dependent.

6. For example, A can trust to share one content with B and not another. A may trust B based on other interactions, but may not trust S2. Finally A’s trust in S1 may change and may decide to change her server altogether. A fediverse must take all these into consideration and accommodate them.

7. Any system of quasi-independent components that agree to federate amongst themselves need to agree on two necessary items: a) how are users identified and how are they authenticated; b) how will the shared content be distributed to other components and how will they be managed.

8. Let me start with the identification and authentication schemes. The standard id format is inspired by email. The general format is name@dn. For example Mastodon’s format is @name@dn; Matrix’s is @name:dn; XMPP and SIP use email format. The id provider is also authenticator.

9. There are problems with these forms of id. For one, if you change the server, the id does not come with you. When A shares content (or email) with B belonging to another server, B’s server has no way to directly authenticate A, but depend on A’s server. The problem with this scheme can be demonstrated with two words - “spam mail”.

11. So the upshot is the first requirement for a fediverse is a user-centric, portable. the id provider and authenticator are independent so that the relying party can select its own authenticator.

12. Next, we need to develop protocols and procedures for delivering notifications and content. A few have already been defined. A more popular choice (for ex. Mastodon uses it) is ActivityPub (w3.org/TR/2018/REC-activitypub). In my opinion it fails in some critical aspects.

13. For example, the spec is not clear whether S1delivers just a notification or the content as well to B/S2. Similarly, when A deletes a content, whether B/S2 will also delete the content. Indeed, it explicitly notes that “there is nothing in the ActivityPub protocol that can enforce remote deletion.” Even a moment’s reflection will suggest that this is not acceptable.

14. There are other instances that need careful consideration so the point made in toot #6. We have designed a social sharing system that incorporates these points, but we are not yet ready to make it public. But 1-1 messaging system is ready for your evaluation. Take a look at www.enthinnai.com.


15. Anand Mahindra and Jaspreet Bindra is looking to create a new kind of Social Network, from India. They prefer that it is built on Blockchain nad uses a different business model, where your data is not sold without your permission. I hope design principles enumerated in this series of toots will help you to develop a proposal for their consideration. twitter.com/Peepul_Social/

· · Web · 2 · 5 · 2
Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!