I just found out about GNU-Social which seems to have a lot of the same goals as what I described in part 1. Before I dive too far into GNU-social let me go ahead and brainstorm about what kind of architecture would be needed to create a free-speech twitter.

Let’s start with the client experience. Obviously the goal would be to emulate the simpleness of twitter’s design – broadcast micro statuses, follow other user’s statuses, communicate with other users. So I wouldn’t change too much about the client UX.

But what happens between the client and the server(s)? That’s where things get tricky.

We’ll start with posting statuses. I imagine that each user could choose from a selection of different servers to post to. The servers could differentiate themselves via uptime/reliability, throughput, etc. There could be paid servers that only support subscribers, free servers that are ad-supported, etc. The servers would then exchange statuses with other servers, eventually all servers would get the same statuses. There would probably be some configuration between the servers that would specify exactly which timelines it wants to pull. Users could belong to a group and all their statuses would be bundled together.

Now that brings up the question of how to retrieve statuses for a user’s follows/lists. If there is no central store for all statuses, then the timeline is at the mercy of the server status dissemination process. So unfortunately timeliness will be an issue. DMs could probably be sent via this federated network (encrypted, naturally) although a direct communication process is probably better.

The timeline data itself (follows, lists, etc) and the user’s profile, could be stored on a designated “home” server, although this data should also be federated so that there’s no single point of failure. The user’s identity is tied into wherever this data is publicly stored, which could be on a dedicated server, or perhaps even on the user’s own server.

Now let’s talk servers. The federated network can rely on dedicated servers, or… what if it followed the bittorrent model and each client is also a server? Especially if DHT (i.e. trackerless), and peer-exchange lists are used – that would truly be a hardened network, as bringing down one or even a whole region of “servers” wouldn’t affect the majority of users. But then that brings up the question of how to package and distribute the statuses.

Let’s save that for part 3.