On: Twitter IDs to roll past 53 bits in a couple days (may break javascript apps)

[drawkbox]

Still surprised people use incrementing ints for ids over uuids for web apis that may become immense.

http://www.ietf.org/rfc/rfc4122.txt

uuids are made just for this purpose, string based, never bigger than 40 characters (with dashes and curly braces).

Most products use uuids or Microsoft's name for them guids.

[jonhohle → drawkbox]

I prefer my ID's universally unique. I worry that globally unique ID's won't scale as we begin to colonize other planets. (yes, its a joke.)

[tjpick → jonhohle]

Stating it is a joke kind of ruined the joke.

[ryansking → drawkbox]

we don't use incrementing ids, but needed ids that increase over time (so that you can sort tweets by them). hence, snowflake: http://github.com/twitter/snowflake

[mayanklahiri → drawkbox]

You don't even need to go that far. For non-critical applications (i.e., your web app), you can randomly generate a small string, say 12 bytes, using base-62 characters (A-Za-z0-9) to serve as a probably unique user ID (with VERY high probability).

[wahnfrieden → mayanklahiri]

Heard of GUIDs? Make part of it a timestamp, and the chance of collisions goes down astronomically further.

[mayanklahiri → wahnfrieden]

In some cases, including a timestamp in an ID can be giving away information considered private. Sure, you could just hash the resultant ID, but then you're getting back to random digits anyway.