Essentially a tweet ID should be a pointer to "latest version", but with historical versions preserved and available at the same visibility level as the parent (typically public) and a small indicator would show that it has been edited and the history is available.

But all of those, "Damn I made a typo or dumb spelling (thx mobile keyboard) and yet it has been replied to or re-tweeted already"... all of that is solved by edit with visible history.

I think it's still ripe for abuse.

Case 1:

I write "I love cats!" You RT it. I edit it to "I am Al Queda." The FBI visits you.

Case 2:

I write "I am Al Queda." I edit it to "I love cats!" before you see it. You like cats, too, so you RT it. The FBI has a slow feed, so they see that you endorsed my Al Queda membership. They pay you a visit.

---

From a systems point of view, when your whole stack is designed around immutability (so you can serve archives of past tweets from append-only CDNs, for example) it may be nigh impossible to add editing.

I think it already happened with a troll baiting racists. He waited for a lot of RT then changed the source of the embedded racist picture with something like "I am a big disgusting stupid racist". Something like that. It was a good one, though.

The original example is gamefaqs introduction of edits. What is your shoe size?

11

Then the question changes to an age related question. What is the ideal age of a prostitute?

Fun fact: this particular example won't work in Japan, where typical shoe sizes are around 25–29.

But there the typical ... nah I won't go there.

Just imagine the gargantuan changes that could be necessary for small tweaks like that. Twitter was built on RoR originally, so it was probably a pretty standard relational model, then they did massive scaling for huge read/write loads, then they did massive scaling for real time features, god knows how hard it would be just to add a foreign key. I really, really, want to take a day and just go through all their engineering blogs after only glimpsing a few..

Honestly, if they only designed to scale and did not anticipate iterating on the product, they deserve to fail. My guess is that this not a trivial change but worth the effort.

No one deserves to fail because of challenges they couldn't have anticipated in the future.

We call that "learning".