venomous porridge
I’m Dan Wineman and sometimes I post things here.
You could follow @dwineman on Twitter or App.net, or email me.
Aug
23rd
2012
permalink

Is a federated Twitter even possible?

Toward the end of my last post, I mentioned that I’d like to see App.net move toward a federated architecture. Broadly, what that means is that instead of being a central service that each client connects to directly, it would become a loosely organized mesh of independently controlled nodes. Users and devices would connect to whatever node they liked best — you can run your own if you want — and the nodes would talk to each other in some clever way to collectively maintain the appearance of a single unified social network.

The advantages are numerous and comparable to those of the web itself: no single point of failure, no concentration of power, no risk that the entire network will be sold to Facebook.

But does this work for a service like Twitter? Can the behavior we’ve come to expect from social networks be reproduced in this model?

Let’s find out. Since every good blog post needs a list of three things, here’s a list of three constraints we’ve come to expect of our social timelines:

  • Immediacy: if a post has been made by someone I follow, I can see it in my timeline right away (or close enough that I don’t notice the difference).
  • Chronology: posts always appear in order by time posted.
  • Monotonicity: timelines grow only from the top; older posts are never retroactively inserted.

The problem appears to be that no federated architecture can simultaneously satisfy all three of these conditions. You can have any two: for example, if you let go of immediacy, your node can just wait until it’s received the latest content from every other node before displaying anything. But that’s not very scalable, and it makes real-time conversation impossible, so let’s keep immediacy. Now we have to decide what to do when content from a far-away node arrives late: if we’ve already displayed newer posts, we have to violate either chronology (by posting the older content above the newer) or monotonicity (by inserting it chronologically into the timeline).

Violating chronology is bad because it turns conversations into nonsense, but violating monotonicity means you can’t assume you’ve seen everything once you’ve read to the top of your timeline. Your client will have to maintain read/unread status for every item, and you’ll have to keep winding back in time to pick up things you missed. Which might be fine, but now we’re talking about something less like Twitter and more like email or RSS.

OK, so all of those options suck for conversations. But chronology is really only important within a conversation. So what if instead of replicating Twitter exactly, we shoot for a hierarchical, threaded model? The timeline would be a list of threads, and chronological order is preserved within each thread, but the threads themselves show up in arbitrary order. Oh, and you see a thread if you’re following the person who started it, I guess? Never mind, at least we’re getting somewhere! We’ve invented Usenet.

Oh.

The moral of the story is that the qualities that make Twitter interesting — its mix of conversation, discovery, and one-to-many communication — are direct consequences of its centralized architecture. Without the centralization you can still have something interesting, but it’s a different thing.

I’d love to be proven wrong.

blog comments powered by Disqus