Monday, July 16, 2012

Twitter Alternatives (Rough Draft)

The beauty of Twitter is that it's simply 140 characters of text. Shorter than an SMS text message - akin to a headline. Any other payload in the message is a hyperlink which is also text.

Why only 140 characters per tweet? Because it was designed to fit into a 160 character SMS message preceded by the sender's user name:
"@joemoreno: Just arrived at the Top of the Rock."

Which begs another question: Why only 160 charters for an SMS? Because the inventor of SMS, Friedhelm Hillebrand, typed out random sentences and noticed that they fit into 160 characters.

Worthy Competition
There have been some alternatives to Twitter, but they're just copies. What's the point of making a copy of Twitter if it still suffers from the same Achilles' heel: a centralized single point of failure controlled by one corporation?

A worthy competitor to Twitter requires fundamental integration into the Internet's infrastructure. This shouldn't be too difficult, after all, it's just text --- or another way to think about it, it's just TXT.

DNS? Seriously?
The Twitter alternative that I'm proposing simply uses DNS. In other words, a tweet would simply be stored as a DNS TXT record. Since it's widely recognized that DNS is the Internet's single point of failure, it has multiple, redundant and distributed, servers to keep it running. DNS servers have impeccable uptime stats because, without DNS we have no practical Internet connectivity.

1. No additional servers required. Simply add a new DNS record for each TXT tweet.

2. Redundantly propagated across multiple DNS servers.

3. Server load distributed to ISP DNS caches. In other words, massive traffic for a single tweet would not need to go back to the authoritative DNS server. Set a long TTL for the TXT tweet, say 24 or 48 hours, and each local ISP should only hit the authoritative DNS server once every day or two to refresh a particular tweet's TTL.

1. Can't easily delete tweets since they're cached at each ISP's DNS server, especially if added with a long TTL.

2. Tweets would need to be inserted into TXT records using a robust API - the only one I'm aware of is Amazon's Route 53 API.

3. Each TXT tweet would need to be a linked list to the previous tweet; or, perhaps, a double linked list to both previous and next TXT tweet.

4. Each TXT tweet would need an embedded timestamp (either UNIX timestamp: 1342472514 or a human readable dateTime object: 2012-07-16T20:38:00Z).

5. TXT tweets, unlike Twitter tweets, can be edited.

6. TXT tweets can expire after the TTL timesout.

TXT Tweet Proposed Standard
The format of the TXT tweet uses pipe | delimited text:

Timestamp | GPS Encoding | TXT Tweet | Previous Chronological Tweet Host Name | Next Chronological Tweet Host Name (optional)

(White space added around pipes only for readability purposes.)

Since the TXT tweets are a single (or double) linked list, we need to know where to start. The logical place to start is with the most recent (i.e. last) TXT tweet. That could be defined in the domain's root TXT record which can be found via the dig command:

dig -t txt   1 IN TXT "2012-07-16T20:38:00Z|"

So, the most recent TXT tweet is at (A simpler naming convention could be host names with integers, such as,,, etc.)

dig -t txt 86400 IN TXT "\"2012-07-16T20:38:00Z | 40\16150'16.8\"N74\16127'57.6\"W | 31 years ago, today, Harry Chapin left us. | |\""

TXT tweet points to as the previous TXT tweet.

dig -t txt 86400 IN TXT "2012-07-16T20:36:00Z | | Yahoo has named Google executive Marissa Mayer as its new CEO. | |"

Practically speaking, we might be limited to 254 characters in a DNS TXT record in order to support older DNS servers. It's a tight fit, but it works with the timestamp, GPS encoding, 160 character TXT tweet, plus the previous and/or next TXT tweet host name.

Left for the Student
Several services need to be built on top of this proposal. Displaying a single user's TXT tweets can be rendered by a simple script running on a web server to display a specific user's feed. Mixing different user feeds, chronologically, is a little harder, but very doable.

However, where it gets challenging is how to handle "follows" and "mentions." In both cases, a server would need to either push or pull these notifications in real time. Pulling could be simple polling, like an RSS feed query. But, push notifications can be a bit more challenging. I'll have to think about how this part would work.

No comments: