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. http://epics3.com/piqk"
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.
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.
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.)
dig -t txt joemoreno.com
joemoreno.com. 1 IN TXT "2012-07-16T20:38:00Z|tweet4.joemoreno.com"
So, the most recent TXT tweet is at tweet4.joemoreno.com. (A simpler naming convention could be host names with integers, such as 0.joemoreno.com, 1.joemoreno.com, 2.joemoreno.com, etc.)
dig -t txt tweet4.joemoreno.com
tweet4.joemoreno.com. 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. http://blog.joemoreno.com/2011/07/harry-chapin.html | tweet3.joemoreno.com |\""
TXT tweet tweet4.joemoreno.com points to tweet3.joemoreno.com as the previous TXT tweet.
dig -t txt tweet3.joemoreno.com
tweet3.joemoreno.com. 86400 IN TXT "2012-07-16T20:36:00Z | | Yahoo has named Google executive Marissa Mayer as its new CEO. | tweet2.joemoreno.com | tweet4.joemoreno.com"
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.