Being able to edit something that someone has already retweeted seems ripe for abuse.

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".

That's a recipe for disaster. You don't edit SMS, why should you be able to edit tweets?

I can see the use case if it's a extremely short edit window.. something like 30-60s, basically to catch that stupid typo. That doesn't solve the abuse angles but it gives a much smaller opportunity for it to happen.

Short of [mega star], few tweets see much favoriting/RTing in that window.

Exactly! I'd say I am strongly against the ability to edit tweets. I'd even put it higher than the strict reverse chronological flow of tweets that I prize so much that I still allow Twitter to send me tweets by SMS.

Edit seems much harder to implement. This basically adds some metadata to the Tweet model instead of embedding it within the body text. That's a change and it needs to be implemented all over, but it is pretty backwards compatible.

It seems that one of the fundamental assumptions is that Tweets are immutable. Changing that could break all kinds of things and would probably their systems significantly more complicated.

Even Facebook has an edit feature for a long time now with a revision history of posts/comments. No issues of abuse. This isn't rocket science.

Facebook has had abuse from pages that got likes, and then later changed their title and purpose.

You can do this on any social media though.

Facebook posts aren't as public-facing by default. AFAIK there's no FB equivalent to the retweet, in that the content of a FB share is not quite the same as the relation between a retweet and the original tweet.

You can do a share with zero added text = retweet You can also do a share of a link post keeping "the original post"

Hashtags and @-replies could also theoretically be moved from the message body and into metadata fields.

That should be nice, I need that option.