social-app
social-app copied to clipboard
bluesky-social
Allow editing of posts
Is your feature request related to a problem? Please describe.
I make typos and everybody does, and we should be able to fix it. We also make factual or content errors and should be able to correct ourselves; as well as update posts that reflect safety or other time-critical issues. (See below for more safety/accessibility notes.)
Describe the solution you'd like
Editing of posts like on Twitter (paid version) or on recent Mastodon versions. Edited post should be clearly marked with a history of edits available to view.
Describe alternatives you've considered
Delete & Repost (like on Mastodon), but that loses replies/embeds/connections/quotes, etc. However, this could be done in the client as a nice first step as it doesn't need backend/storage/schema changes.
Additional context
- This is a safety issue: certain posts will benefits from updates (e.g. "Update: The shooter has been arrested.") when people see reposts later.
- This is an accessibility issue: people who have mental or physical limitations with typing are more prone to errors.
This is on the roadmap, but for us to implement the edit history we need to update the protocol to include a new kind of backlink to previous versions of a record. We'll prioritize this after other core parts of the protocol stabilize.
fwiw: in some forums, you get a certain amount of minutes to edit. I've recently seen a countdown from 60 minutes.
But of course that would not cover all cases.
This is on the roadmap, but for us to implement the edit history we need to update the protocol to include a new kind of backlink to previous versions of a record. We'll prioritize this after other core parts of the protocol stabilize.
If the edit history is the only thing blocked, I feel it would be valuable to implement editing just with an indicator that it's been edited, & come back to the history display later.
I would like to see editing of ALT text and outside tags first. I don't think these would really need history either so should be a bit easier to implement. Edit history of the post content definitely needs to be a thing though.
Once posts are editable and have a public edit history available, a cool bonus enhancement would be if the original poster could see all of their post interactions (such as views, likes, reposts, quote posts, or any other future analytics metrics) attached to / segmented by the specific post ~version~ that was viewed by the account generating the interaction.
Then for example you could see exactly who all saw your post before you caught your ten typos and fixed them, or before you added the link or hashtag you forgot (and potentially had to cannibalize actual text from your post in order to add retroactively, while these things still consume characters from actual post text).
Another good feauture to add with the addition of editable posts and viewable post edit histories would be an in-app notification system, whereby any user who previously had interacted with a given post would just receive a notification when that post is edited, and then they can decide if te edit really affects their previous interaction or not, and respond accordingly if they feel like it does. This especially would be good for journalists who have accounts, and had previously also embedded a post (when this becomes a feature too) in an offsite news article. Then a journalist or editor could decide if they wanted to retain the embedded post in their article, add a bit of "update" text to their article, etc.
Interactions generating a notification for affected users would include any kind of interaction that is either a feature now, or may become a feature in the future (for example, if eventually users get the ability to bookmark posts within the app itself, as on ex-Twitter and elsewhere ... if you bookmark a post and it is edited, you could then go review the edit).
In my previous comment I wrote off associating specific interactions with specific versions of an edited post. The related aspect of this with notifications particularly for comments/replies is that every commenter in turn has the opportunity to edit their comment if they feel a need to, and their comments themselves would also have their own edit history. There's no need to add 100 more comments to a long thread (especially if the original poster was a high profile account which would naturally generate tens or hundreds of replies), when every existing comment can be edited. To me this a beneficial cascading effect of editing, edit histories, and edit notifications, three separate but related concepts. If people really want to know, they can look at the timestamps of edits of the original post and compare to timestamps of comment edits and see an implicit relationship, without also attempting to directly link comment edit histories to original post edit histories.
Incidentally, everything pertaining to a post should be editable, including the alt text on attached images.
One thing I absolutely think is a terrible idea is setting any arbitrary time limits for editing posts. When you have a visible post edit history, such limits are not even necessary. Moreover, there is a burden on the user making the post, in wanting to be able to modify it as necessary without losing things attached to it such as likes, replies, reposts, et al., but there's no similar burden on any other user reading the post. As long as other users can see the edit history, it's really not reaasonable for them to impose (or ask the devs to impose) a limit of n seconds / minutes / hours / days within which the post can be edited. Editing is a natural and inevitable aspect of content, and edits and edit histories have been a feature of, for example, Wikipedia for decades. No one would ever reasonably expect that a Wikipedia article could no longer be edited after an hour or a year.
Notably, on Twitter when I would click a hashtag, I fully expected to be able to see posts that were years old among other more recent posts (such is the the value of a hashtag for finding related content, regardless of age). So on Bluesky, if 6 or 12 months from now I think of another hashtag that would be appropriate for an OLD post, I'd like to be able to add it, it doesn't hurt any other user for me to add it.
- This specific genre of edit , editing content enhancers rather than editing content, also touches upon a separate issue — namely, hashtags, mentions, et al., should be in, for lack of a better description, separate database tables with a many-to-many relation, not directly in the content of the post itself ... in other words these content enhancers should be 100% decooupled from the actual content of posts ... these things are not content at all)
Similarly, if in the time since I made a post which had one or more links attached to it, and then link rot had occurred, I'd naturally want to be able to update the links if a newer link or even just a similarly relevant link could be found.
You just cannot predict ahead of time all of the possible reasons and edge cases for why someone may want to edit a post at any time in the future, so there's no rational reason to hobble them if it's not going to literally break servers. I think occasionally some people are prone to making statements like "I saw that Threads limited editing time to 100 seconds" and submit that as a suggestion for every other site, without even thinking about how it is a bad feature on Threads.
I've already edited this very comment multiple times now, and I'm glad GitHub allows me to, because the edits were needed.
Would, or could, editing of posts include retroactively turning them into a thread--a reply to another of our own older posts, without textual editing?
@Lucent interesting idea ... makes me think of the simplicity of changing the parent of a "label" in Gmail ... could be useful in the microblog paradigm that makes "threads" necessary at all
I can see the pros/cons of this. I'll vote for post edit with history and includes time limit -with time limit = less notifications -with time limit = less history retention needed
Federation may make this issue more acute, at least for rendering edits if not providing a UI to make them. PDSes can happily allow editing, mine does, but bsky.app doesn't seem to show edits/updates. It always only shows the original record.
Asn an example, I created and then edited a post on my PDS. atproto.tools shows both the create and the update as valid, but bsky.app only shows the original create.
cc snarfed/bridgy-fed#947
I can see the pros/cons of this. I'll vote for post edit with history and includes time limit -with time limit = less notifications -with time limit = less history retention needed
If I may, I think that people are...
~ ｏνＥ𝔯𝐂𝕆๓𝓟Ļι𝔠ａＴι𝓷Ǥ 丅𝔥𝕖 𝐢ᔕѕᑌⓔ ~
.... ;)
Bluesky's principle has always been "let users decide", right? So, fine. Keep a (viewable) edit history, and let the user decide which version they want to see, whether that's the version that was posted with 0 minutes (never want to see any edits), 5 minutes, 60 minutes, infinite minutes, whatever.
Just one user-configurable integer ("When viewing an edited post, don't show edits past this many minutes since it was written"), how long after a post is written (in minutes) to show, and now everyone is happy, right?
And re: sharing posts, isn't the solution obviously just "the preview that shows up of the shared post is the version that was present at the time they clicked 'share'? And then if they click through, they see the most recent one that matches their above max-minutes setting. I mean, we could also let users configure what preview they want to see on shared posts, this could be its own setting ("Show subsequent edits from the author when viewing quoted posts"), and I think that would be great, but at a most basic level, wouldn't just previewing the specific-shared version be good enough for most people?
Federation may make this issue more acute, at least for rendering edits if not providing a UI to make them. PDSes can happily allow editing, mine does, but bsky.app doesn't seem to show edits/updates. It always only shows the original record.
Asn an example, I created and then edited a post on my PDS. atproto.tools shows both the create and the update as valid, but bsky.app only shows the original create.
cc snarfed/bridgy-fed#947
Strong agreement from my side. I just had to delete and rewrite my federated mastodon post due to the lower char limit on Bluesky and the missing edit option for three times. Would be nice to have at least a temporary solution (e.g. without saving the history of an edited post).
