There is currently no way for Twitter clients to exchange information. The primary need for this functionality is between desktop and mobile clients.

Consider this scenario:

1) A user is reading tweets using their desktop client in an office. They have a read up to a certain position in their timeline. 2) The user shutsdown their desktop machine and leaves their office. 3) While waiting for a bus, the user opens a mobile client and starts to read tweets.

At this point, the mobile client does not know where the user was in the timeline. An API to create an arbitrary hash of values would allow the client in step #1 to record information and the client in step #3 to read it.

At the very least, the option for applications to update a last_read counter per-user would suffice.

Probably better to call it last_id since it's not necessarily something that's tied to "reading". Some users want it to represent the highest ID from the last batch the client has pulled down, others will want it to represent the ID of the tweet that's currently selected.

If something like this is to be added it must have fixed semantics or two arbitrary clients will not be able to use it to communicate effectively. Overloading the meaning of a field in an API is not a good move. Hence names like last_read_id or last_read_date are far better, and more developer-friendly.

That said, if Twitter will be storing this value then realistically the clients need never be exposed to it - there could be a 'catch up' extension to the timeline API methods to achieve the same goal. This would avoid the risk of broken clients updating it wrongly and save a small amount of bandwidth in the process.

This issue has been recoreded in the future roadmap: http://apiwiki.twitter.com/V2-Roadmap

Marking "Invalid" so these issues don't clutter the main view of issues. All are tracked on http://apiwiki.twitter.com/V2-Roadmap

Given the different ways you can browse your follower's timeline, a simple last_read_id would not necessarily bring a lot of value. Would rather see an API that would allow to synchronize (in the cloud) all the tweets read for a single user.