• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!



Page history last edited by nitin 14 years, 11 months ago




Nitin Borwankar (@nitin)


In 140 characters:


A linkedlist syntax allows a set of tweets to be listed as a sequence and recognized as a sequence. This is useful for threading tweets.




There is a burning need to thread tweets together for many different purposes - this microsyntax allows this to be done and the whole thread to be sent around as a single tweet.  This microsyntax is meant to be primarily machine readable but can be used by humans too.  This is obviously useful to thread ones own tweets together. It also allows creating lists like "my favorite 10 tweets by @xyz" or "my summary of the foobar controversy".   Each of these is an example of a curated set of tweets which may not even be a conversation.  It could just be a random sequence of tweets that are insightful or funny or educational etc.


The format allows "paging" to be incorporated so that an arbitrary number of such lists can be chained. Paging is necessary as the 140 char limit imposes a limit on how many tweets can be in a linked list.


The limitaton on 10 tweets is arbitrary - current status id's are of length ~ 10, the extra 40 characters will allow some preamble such as a hashtag to aid search or a pageid etc. Also it allows length of status ids to grow to maybe 13 or so which is a thousand times now.

Future linkedlists will have fewer permitted elements in the list as id lengths grow, but this will not break older lists which will point to statuses with smaller ids. So this structure is evolutionarily adaptive



Details and Use Cases:


Threaded conversations

There is a very urgent need for threading together tweets that are conversations and to do it preferably in a twitter-friendly standard way.

This would allow tweet threads created in one tool to be shared and sent around allowing content re-use


Curated Tweet sequences

A "tweditor" might be able to filter and curate the real time stream and pick the best (in their opinion) tweets to form a thread that represents either intertwingled opposig points of view or just one side of the discussion or some variation - this format is content agnostic obviously.


Collected tweets from a conference

The format allows "paging" so that a number of linkedlists can be chained and a curated list longer than ten tweets can be created.





Simple LinkedList




where twid is the integer part of a status url such as 2197528354 to represent the following tweet

http://twitter.com/vanderwal/status/2197528354 So each twid is a pointer to a content tweet.


All of this text is sent out as the body of the tweet and can propagate through the normal Twitter channels.


The leading ~~ indicates the start of a tweet sequence, the shape suggestive of a chain. Two ~ characters are used rather than one to avoid picking up the ordinary use of ~.

The trailing * indicates this is a self contained and non-paged tweet.


Chained LinkedList




The only difference here is a trailing double asterisk which indicates that this is a chained list.

In the case of the chained list the last id is not a pointer to a content tweet but is a pointer to a tweet that is itself a LinkedList (containing content in this same microsyntax).  Hence the tail of a chained list point to the start of the next "page" (which is a tweet containing the next 10 tweetids in the sequence).


Note that to be consistent the next page will also have to be a simple or a chained linkedlist.


If the next page is a simple linked list then it is the last page in the chained sequence.

If the next page is a chained linked list then it's last id points to another page etc.

Eventualy every chain ends in a single *.


Clients that ingest and interpret chained linked lists can choose to put limits on number of pages they will accept in a chain - this is to prevent prank infinite chains. Ideally clients that understand this syntax shoud allow the human to indicate that for a trusted tweeter's content, the limit is to be ignored.


[[ Note this is a very early draft and needs critique and feedback, but the basic idea is sound and has been vetted for over the last 4-6 weeks ]]



Comments (2)

Michael D. Ivey said

at 8:06 pm on Jun 25, 2009

How can a tweet know the ID of the following "page" before that page is created?

nitin said

at 9:39 am on Jun 26, 2009

Hi Michael,
Thanks for the question which is a great one. The use cases suggested all have one thing in common they chain tweets after the tweets have been created and already out there on twitter.com This mechanism is not useful for "dynamic" use i.e. where the chaining/paging is being done as the tweets are generated. For the reason you point out - the tweetid is not available in advance, such "dynamic" usage is not part of the possibilities. However future clients may allow users to create a set of tweets in the client, post them all at once and then create a linkedlist as soon as the tweetids becom available (in reponse to status update api requests - one per tweet). So especially for paging etc - the use case envisaged is for curating existing tweets where the tweetid is already available.
So especially for chained pages, the tweets will have to be assembled, posted *backwards* and then pages linked on the client as tweetid's of pages become available
The last tweet to be posted will contain the linkedlist of the first page in the chain.

Hope this answers your question.

You don't have permission to comment on this page.