

Is a federated Twitter even possible? - glhaynes
http://venomousporridge.com/post/30043951343/is-a-federated-twitter-even-possible

======
rabble
Back in the day, 2007 and 2008 there was live running federation between
Twitter and Jaiku. I remember i was sitting in the room when Ralph and Blaine
got it working, at 4am at a foo camp.

Unfortunately Jaiku was bought by google and they spent a long time with it
offline only to come out as Google Buzz which didn't take off.

Many of the early twitter engineers like Blaine Cook and Alex Payne pushed
hard for twitter to be more open and federated, but lost that argument and
left or were pushed out. It's a business not a technology decision which makes
twitter centralized.

------
forgotusername
551 words spilled on a simple question, with a simple, obvious answer: E-mail.

* 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). "E-mail"

* Chronology: posts always appear in order by time posted. "E-mail". Chronology as the author imagines it doesn't even occur for Twitter, likely their machines' timestamps are fuzzy +/- perhaps up to a minute or more.

* Monotonicity: timelines grow only from the top; older posts are never retroactively inserted. So have your client mark a message by the time it's received, provide a second sort order. Ugh. "E-mail"

There are genuine technical challenges to implementing a robust many-many
federated messaging system, this post mentions none of them.

~~~
alttab
A billion dollars to the first company that builds a federated twitter on top
of existing gmail accounts. Go!

~~~
moe
For a 1% downpayment I will start tomorrow and deliver this year, email in
profile.

~~~
alttab
Nice try. If you are successful, you won't need me to pay you. The world will.

------
joshhart
It's both possible and necessary. Think about it - even a centralized service
like twitter or facebook will have many distributed & disparate services that
need to work together to provide a feed. Hence, there probably already is some
kind of federation going on, you just don't know it.

Source: I work @ LinkedIn on these types of problems.

~~~
dwineman
Author here: a few people have raised this point. Perhaps I should have made a
distinction between "federated within the same data center" and "federated
across the internet." They are two entirely different problems.

------
sp332
If it was impossible for a federated network, it would also be impossible for
Twitter. They can either guarantee that messages _only_ show up at the top, or
that messages _always_ show up in order (meaning older posts get inserted into
the middle of the timeline, as you eventually receive them).

~~~
mbreese
Why couldn't the user decide how to view message?

You could easily allow a user to see messages ordered by "send time" or
"received time". You could even add an "unread" flag to messages, so that
unread messages show up first, then migrate to their proper locations in
order.

Ya know... kinda like email.

~~~
sp332
Sure, of course they could. The point is that you can't do both at the same
time.

~~~
rabidsnail
You can if you use vector clocks.

@sp332 You can prevent that by buffering messages. The less you tolerate
messages appearing in-between messages you've seen before, the more you
buffer. If the latency between your host and the host of someone you follow is
high enough that it's taking more than a few seconds for you to get the
message, they're effectively down. Late is better than never.

~~~
sp332
Vector clocks are only a partial ordering. You'd still have old events popping
into the middle of your timeline.

------
Lammy
Isn't OStatus exactly this, or does it fail one of his criteria?

------
rabidsnail
<http://en.wikipedia.org/wiki/Lamport_timestamps>

Edit: More information on how to actually use Vector Clocks (which are sort of
like multi-way Lamport Clocks) in a real system:
[http://basho.com/blog/technical/2010/04/05/why-vector-
clocks...](http://basho.com/blog/technical/2010/04/05/why-vector-clocks-are-
hard/)

------
michaelpinto
Is the web federated? Everyone hosts their own sites and there are several
browsers -- I don't see why we can't have a social media version of this.

~~~
lloeki
The web is not "federated": site A does not communicate with site B. Contrast
with SMTP or XMPP which require federated servers to communicate with one
another to establish dialog between two users. All of them are decentralized
though.

~~~
rhizome
The routers do, though. Through BGP, AS's communicate location information to
the routing infrastructure of other AS's. 15 years ago we saw the decline of
"everybody knows everything" as the routing tables of core infrastructure
simply became too unwieldy.

------
comex
As the post says, with sufficiently slow servers it's impossible to maintain
chronology plus monotonicity, and as it says, since chronology is really only
important within a conversation, the best solution is to ensure each reply has
an in-reply-to field (which tweets already have), then ensure that the
original tweet is fetched before displaying the reply, and accept only
approximately chronological ordering for "threads". But... that doesn't mean
the UI has to change to look threaded, or that you should see an entire
conversation if you're following the person who started it. That's a crazy
leap. With such an algorithm it can still look exactly like Twitter and most
people won't notice the difference.

As an alternative, by the way, since these posts are so short, you could
simply include the entire thread with each reply! A few kilobytes won't kill
any servers.

Also, one of the blog comments raises a good point: IRC has the same problem
and it works fine.

------
jimktrains2
Isn't that what RSS was? I could make a post, and have it syndicated to
whoever wanted to listen to me.

~~~
rabidsnail
RSS doesn't guarantee global ordering, and has very high latency (because of
polling). Both of these can be overcome, but require a new protocol.

~~~
jlogsdon
PubSub solves the problem of immediacy.

~~~
kelnos
... and introduces the problems of scalability and reliability.

(Not that those problems aren't solvable with PubSub, but it does add a lot of
complexity.)

------
taybin
Usenet was federated and seemed to have these properties.

~~~
kennywinker
Depending on where you were connecting from, there could be serious delays in
usenet. Like, some servers synced once a day kind of delays.

~~~
smacktoward
It's important to note though that hardware muscle and bandwidth were both
much, much, much more scarce and expensive back then.

------
pixelcort
Most email IMAP servers provide both Date Sent and Date Received properties
for each message, allowing the client to sort by either. Even in active
mailing list threads, I've found that it's not that common for messages to get
too out of order.

Assuming federated social services keep track of Date Received, it'd probably
be okay to just sort by that.

------
icebraining
_your node can just wait until it’s received the latest content from every
other node before displaying anything._

"Every other node" just means the nodes where the people you follow are
hosted, not every node in the network. For most people, that would probably be
a very small number.

------
gojomo
My hunch is that it's technically possible to go not just federated but
radically distributed. However, there's more money to be made in
centralization, creating defensible toll booths. And right now the sorts of
developers and protocol/system architects who _could_ make a radically
distributed alternative are now fully overemployed doing other lucrative or
beneficial things.

So it's a little harder technically, and lot less lucrative, to make a
radically distributed alternative. And whatever the abuses of the centralized
proprietors, they're still not changing those tradeoffs -- most users and even
platform participants can still make-do under centralization.

A big tech bust freeing more talent to work on ideological (rather than
pecuniary) projects, or enough heavy-handedness from the centralized
proprietors, could change that balance.

~~~
rabidsnail
You're right. Gnutella was developed in 2000, eDonkey in 2000, Freenet in
2000, BitTorrent in 2001.

------
Tichy
I think Twitter also has users distributed on different servers, making it
effectively federated.

------
moe
It hurts a little when the author mentions Usenet - and then doesn't realize
that yes, of course it could trivially emulate twitter.

Regardless I don't find the notion of a federated twitter particularly
interesting anyway. The future is P2P.

------
kniht
Yes. <http://dsandler.org/brdfdr/>

------
kscaldef
Personally, I'm willing to lose monotonicity. I mean, it's only Twitter. If I
don't see every single message because I didn't scroll back far enough, I
don't really care.

------
gojomo
I doubt the single global ordering is as important as the author suggests. If
nothing is in practice delayed for more than a short period, then either
ordering-by-arrival or ordering-by-declared-time-with-'seen'-indicator both
mostly work. It's whatever you get used to.

And I've seen all sorts of micro-failures in Twitter's provision of global
ordering: gaps in my display timeline in one client but not others; tweets
seeming to appear below the 'topmost' position when revisiting the stream;
difficulty reloading recent history that was already local at one point.

A distributed/federated system might be a little fuzzier on some ordering
behaviors... but make up for that in other dimensions.

------
mparlane
I think IRC does this type of mass node interconnection quite well.

------
motoford
FIDOnet

~~~
michaelpinto
I'm so old that remember when the nickname for that was "Fight-o-net"

------
testestestes
status.net already done.

identi.ca etc.

------
thinkingisfun
_"violating monotonicity means you can’t assume you’ve seen everything once
you’ve read to the top of your timeline."_

if that turns out to be such a problem,

1.) you can simply assume that everything fresher than 5 minutes is subject to
change, so you ignore it until it's at least 5 minutes old.

2.) whatever site or app you're using could simply mark unread messages, and
inform you of out-of-order messages.

