How to Build Your Own Decentralized Twitter

“Hello Alan, how are you?”

“Hello Beth, I am fine”

Within the written conventions of a novel, you can understand that two people are talking to each other when you come across these two lines. There may also have been a narrator, and there had to be an author.

With social media, the lines are not reported speech, but posts from live protagonists in real time. The narrator becomes the social media platform. So, holding the conversation together when a platform does not have a controlling position is challenging.

The Difference Between Federated and Distributed

In my experience, federation is much mentioned but little practiced in the software world; attempting orchestration between two separate entities is brittle. We understand Twitter to be the owner of its information, the controlling organizer and the source of truth. The term “social graph” when applied to a social network mixes the relationships of the users posting, with the posts themselves. Either way, we know Twitter owns its social graph.

With disruptions to our favorite blue bird app, some attention has gone to Mastodon (and to a lesser extent projects like the IndieWeb). If Twitter is a central authority platform, then we can say that a federated network has multiple centers, while a distributed network has no center at all. If you want to examine the meaning of these two things, think of “distributed” as a quality. The perfect example of federation is Mastodon. It has many server instances, owned and moderated independently, that communicate with other like-minded servers. The relationship between the user and the server is very familiar, whereas the firmly distributed Indieweb expects participants to independently maintain their social data on their own web domains.

Perhaps the ultimate comparison is provided by the zombie apocalypse movie. Society is either made of small precarious communities, or every man fends for himself behind barbed wire and guns. Life won’t be quite that bad after Twitter goes down.

At its core, the founding concept in the alternative models is that the conversation and your identity are not (or not exclusively) controlled by one single platform. I will take this concept a little beyond the normal limits and explore the issues of conversation ownership using a code project that I’ll outline in a series of articles, starting with this one.

Architecture of a Twitter-Like App

For familiarity, I’ll refer to a message on our experimental graph as a tweet, the user as a tweeter and the equivalent of the platform as a tweet viewer.

The architecture we will use gives the tweet viewer the job of going to the participating tweeters and fetching their tweets, in order to sew them together to form the social graph. This is close to the ultimate in distribution, where the tweeters control more or less everything and the tweet view platform holds only the permissions needed to collect the tweets. Each user owns and stores their own tweets in a store — represented as a file in the project. A tweet view platform checks which identities it knows, and goes to the tweeter’s store to recover their tweets. I use JSON as the data format.

The purpose of this example code base is to show what it means for a social graph not be owned by any one body, like it is on Twitter. Instead, the display of tweets is pulled in from the users’ store of tweets and reconstructed every time it is requested.

To “own” your tweet means two things here. Firstly, I can do anything I like to my tweets (edit, erase, add) because I own them. Secondly, it means that a tweet view platform needs my permission to use my tweets. This implies that the graph may be in a permanent state of damage or fragmentation, because no central authority has the right to enforce structure. This further implies that a degree of mitigation is required when presenting the graph to a user. We’ll experiment on these cases later on.

I’ve used a Visual Studio solution because it’s easy to build and then run the separate projects. You can download the solution and build it yourself, or just follow along. There are two runnable projects: TweetApp that populates a tweet store, and TweetDisplay that shows the tweets that the tweet viewer platform would show. The code is mainly concerned with reading and writing to a JSON file, and ordering the tweets for display. Remember that you can play around by adjusting the JSON data directly.

I make several assumptions to make the project simpler and to focus on the issues:

• The tweet stores and view platforms should clearly be separate independent services, but in the project, they sit cozily together. So all the possible problems of communication between these services are elided.
• Because the data is co-located in the project, the Tweet App can conveniently create tweets in any tweeter’s store.
• The threading is very simplified, and you can only reply to the last tweet made.

Let’s Start Building

First, let us look within the project at the basic Tweet structure:

public struct Tweet
{
 public string Text { get; set; }
 public long Replyto { get; set; }
 public long Time { get; set; }

 public Tweet(string text, long replyto)
 {
 Text = text;
 Replyto = replyto;
 Time = DateTimeOffset.Now.ToUnixTimeSeconds();
 }

 ...
}

You will notice there is no name — that’s because you can have a different identity on each tweet viewer platform. I use the unix time (the number of seconds since 1970, January 1st) as both a unique id and the creation time. Here is an example of a tweet in JSON format in a tweet store:

{
 "Text": "Hi there, anyone listening?",
 "Replyto": 0,
 "Time": 1668435369
},

The Reply-to field is 0, meaning it is the start of a thread.

The relationship between a user and a tweet view platform is defined in the Identity:

public struct Identity
{
 public string Name { get; set; }
 public string StoreFile { get; set; }
 public bool Permission { get; set; }
 public short Id { get; set; }

 ...
}

The Identity structure sets the name for a user within the specific tweet platform. What should be a permission token that allows the tweet platform to read tweets from the specified tweet store is just a bool. Here is the identity for Alan:

{
 "Id" : 1,
 "Name" : "Alan",
 "StoreFile" : "AlansTweets.json",
 "Permission" : true
},

Before you start playing with the solution, change the BASEDIRECTORY in JsonServices.cs so that it matches where your installation is. Later, you can move all the .JSON files to another directory and point to that.

const string BASEDIRECTORY = "/Users/username/Projects/TheNewStack/";

So let’s run the tweet viewer app to see our current conversation, featuring the three tweeters the viewer platform has identities for, and the tweets already in their stores:

👁 Image

Here is the result:

We can use the tweet id (the long number in brackets) to add a reply tweet. So let’s make Cath add a conspiratorial tweet to the end of her thread about cars. The end is the tweet with id 1668634367.

Switch to the Tweet App and run that:

👁 Image

This is the result:

So now when we run the Tweet Display we have this:

So we have set everything up for more experimentation. But let’s do that in subsequent articles, as there has been quite a lot to take in with laying the groundwork. For now, download the project and play around.