[jimray]

I got mine this weekend. It's a solid implementation, a great 1.0 and something Twitter and the engineers who worked on it should be proud of.

When you click the "get my tweets" button, it kicks off a process in Twitter land somewhere. A few minutes later, you get an email with a link to a zip file.

The file contains a full archive of every one of your public tweets, including @replies you've made, but not DM's or replies to you or follower/following information, etc. It's just your public tweets. The tweets themselves are stored as CSV and JSON. Which is actually pretty cool because it means you can build your own apps, or archive apps like Thinkup can ingest your tweets, if you're so inclined.

As the article states, you can explore your archive via a web app that all works client side in a browser, based on Bootstrap, natch. The app works quite well. You can search your archive quickly and easily. It points to the canonical URL of the tweet on twitter.com. There's some pretty basic visualization of your tweet archive.

The javascript that runs the app is all minified so it's kind of hard to explore. The application is named "Grailbird" which I thought was kinda clever ( http://en.wikipedia.org/wiki/Ivory-billed_Woodpecker ).

On a personal note, it was pretty great (though often cringeworthy) to be able to roll back through 6 years of tweets. I found the very first tweet that the woman I'd end up marrying every replied to. The tweets that led to friendships and career changes.

It's a solid first step. Nice work, Twitter.

[graue]

Thanks for this, I was immediately curious what's included and how it works.

Would you be willing to share an example of the JSON structure for a tweet?

[jimray]

Here's my first ever tweet. There's a separate JS file for every month of tweets. The JSON object itself is named according to the month.

  Grailbird.data.tweets_2006_12 = 
  [{
    "source" : "web",
    "entities" : {
      "user_mentions" : [ ],
      "media" : [ ],
      "hashtags" : [ ],
     "urls" : [ ]
    },
    "geo" : {
    },
    "id_str" : "547413",
    "text" : "counting down the seconds until 5",
    "id" : 547413,
    "created_at" : "Sat Dec 02 00:57:17 +0000 2006",
    "user" : {
      "name" : "Jim Ray",
      "screen_name" : "jimray",
      "protected" : false,
      "id_str" : "35623",
      "profile_image_url_https" :   "https://si0.twimg.com/profile_images/1234214846/avatar_normal.jpg,
      "id" : 35623,
      "verified" : false
    } ]

The CSV data is much more basic

  547413,2006-12-02 00:57:17 +0000,counting down the seconds until 5,

[napoleond]

Does anyone know the purpose of having both the "id" and "id_str" attributes?

[russss]

It's probably because modern tweet IDs are larger than a 32-bit integer. Presumably some JSON parsers aren't too hot on parsing bigints, so they give you the option of having a string instead.

[napoleond]

Ahh, that makes sense. Thanks! (And thanks to andrewf as well!)

[andrewf]

http://blog.programmableweb.com/2010/10/19/the-twitter-id-sh...

[hythloday]

In Javascript (as well as Lua and PHP) ints are -- under the hood -- doubles. This means they can only represent a 53-bit int: outside that range they start to alias. You can see this in effect in a JS REPL:

10000000000000001 === 10000000000000000 True