4 ms·

It’d be a simple check that anything referenced has to have a lower ID (and hence time stamp). I find this bug more interesting: > Also, it seems like Twitter

by koolba 6y ago

It’d be a simple check that anything referenced has to have a lower ID (and hence time stamp). I find this bug more interesting: > Also, it seems like Twitter doesn't actually care about the username and just resolves URLs based on the tweet ID. I'm sure lots of people already knew that but it's new to me. They’re not validating the parent directory matches the actual tweet. I wonder if that’s an actual bug or intentional to allow for handle renaming to not break existing links.

munk-a 6y ago
That seems incredibly brittle due to making assumptions about the ID format that twitter has no obligations to keep. It just so happens that if your logic had been if(newId > olderId) you would have survived their new format (due to the fact that the timestamp leads the integer) but that'd be a win based on pure luck. The example the engineer came up with was seven years old so it had no way of foreseeing the ID format change.
- amichal 6y ago
  It's a good point but I would suspect that the timestamp being prefix is no accident. If your IDs were sortable in the past it's probably a good a idea to keep them sortable. And since tweets more often than not refer to tweets in the same time range or are paginated together with tweets in the same time range (roughly) having time as a prefix has other advantages
  - zimpenfish 6y ago
    > I would suspect that the timestamp being prefix is no accident. Yeah, it's what they created Snowflake for. https://blog.twitter.com/engineering/en_us/a/2010/announcing-snowflake.html https://blog.twitter.com/engineering/en_us/a/2010/announcing...
numpad0 6y ago
Can’t be unintentional, else they can’t keep up with users changing IDs.
jacquesm 6y ago
This bug actually has some security implications because you can make it seem as though an account has tweeted something when really it was another one. A casual observer might not notice the discrepancy between the name before and after the click.

by koolba 6y ago

munk-a 6y ago

That seems incredibly brittle due to making assumptions about the ID format that twitter has no obligations to keep. It just so happens that if your logic had been if(newId > olderId) you would have survived their new format (due to the fact that the timestamp leads the integer) but that'd be a win based on pure luck. The example the engineer came up with was seven years old so it had no way of foreseeing the ID format change.

amichal 6y ago
It's a good point but I would suspect that the timestamp being prefix is no accident. If your IDs were sortable in the past it's probably a good a idea to keep them sortable. And since tweets more often than not refer to tweets in the same time range or are paginated together with tweets in the same time range (roughly) having time as a prefix has other advantages
- zimpenfish 6y ago
  > I would suspect that the timestamp being prefix is no accident. Yeah, it's what they created Snowflake for. https://blog.twitter.com/engineering/en_us/a/2010/announcing-snowflake.html https://blog.twitter.com/engineering/en_us/a/2010/announcing...

numpad0 6y ago

Can’t be unintentional, else they can’t keep up with users changing IDs.

jacquesm 6y ago

This bug actually has some security implications because you can make it seem as though an account has tweeted something when really it was another one. A casual observer might not notice the discrepancy between the name before and after the click.