Tag: twitterspy

I’m listening to the 8/2/2008 episode of the Gillmor Gang where Steve is talking with Dustin Sailings of Twitterspy. As they are talking about Twitter and Identi.ca and such, a realization hit me. Because I know nothing about how any of these microblogs are implemented this might be naive and redundant but let me throw it out there.

Microblogs absolutely need GUIDs. Particularly if we are talking about federating together identi.ca powered services that exchange messages, it is highly important that we be able to uniquely identify them. Since every microblog post originated somewhere, I believe this GUID should almost always be the URL of the individual message on the originating service.

For example, I make a tweet on Twitter. FriendFeed picks that up and aggregates that in my feed. That FriendFeed message should have a GUID that is the original Twitter URL. If I have a ping.fm or TwitterFeed or any other reposting type service running, they should all pass in the GUID as they do the push from Twitter to other services. If I post originally to Identi.ca and it pushes to Twitter, just reverse that notion. Then in cases like where your blog automatically posts messages to Twitter, the GUID should be the permalink of your blog post. This would enable easy deduplication. For example, now FriendFeed could see that the Twitter notification of the blog post is something it has already seen from the blog itself. It can only show a single occurrence, not the avalanche of duplicate messages we now see.

The same basic principle would hold with Flickr entries that get posted to Twitter or similar services. Use the Flickr page as the GUID so that it is easy to tell that the notification from Twitter, Plurk and FriendFeed are all the same thing so whatever interface you are using should show it only once. I think the benefits of this fall out very quickly. This seems like it would be simple to add in if it doesn’t already exist, simple to add to every bit of message flow and simple to use at all the user interface ends. If the idea is that in the future these services will be distributed and federated, this sort of thing should happen sooner rather than later.