Dan Wineman lights up the federation crew by asking for a federated Twitter. Dan outlines the benefits as well as the problems when it comes to a decentralized, federated, real-time, social communications app.
“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?
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).
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.”
A few of the comments related to Dan’s post include:
You’re assuming a single conversational thread, but the key value of twitter
is the semi-overlapping publics that mean we don’t have to read all
responses to a post in order, just those from people we choose to
follow. Chronology is violated by Twitter, explictly by retweets and
quoting. They favour monotonicity instead, but this does lead to
Monotonicity is a display choice at the client.
See http://j.mp/twittertheory for more on semi-overlapping publics.
See SWAT0 for discussions fo ow to test and achieve this: http://www.w3.org/2005/Incubat…
So tired of this conversation. Blogging type software with 140 character
constraint + PubSubHub + An aggregator = Distributed
Microblogging/Twitter service. It’s easy.