Allow editing of posts #673
Comments
|
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. |
pfrazee
added
x:on-the-roadmap
|
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. |
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. |
|
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 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.
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 |
|
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. |
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? |
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. |
|
How was editing not in the alpha versions? How has it be "de-prioritized"? Mastodon has had this for 2+ years https://blog.joinmastodon.org/2022/03/mastodon-3.5/ |
Twitter added the ability to edit posts (for some users) in 2022, 16 years after it launched. Mastodon also added the ability to edit posts in 2022, 5 years after it launched. Bluesky, meanwhile, only opened up to the public in 2023, so it hasn't even been 2 years. We'll get there, but the devs can't add every feature requested all at the same time. |
threads shipped editing 3 months after launching |
On the other hand they still don’t have proper two-way integration with other ActivityPub instances. These apps are working with very different constraints and priorities. |
Indeed. Also, Meta said that Threads had a team of about 60 engineers and it's almost certainly grown in the year since that article was published. Afaik Bluesky currently only has 12 engineers working on it. |
|
What was done in the past is not a productive line of discussion. Getting this done in the future is. :) We know what's not been done. Let's focus on getting it done. |
That’s a good point. For those who haven’t seen it, it might be helpful to quote from the 2024 Protocol Roadmap (published May 6, 2024), which as far as I know is the latest “official” thinking from Bluesky on their plans for post editing:
|
Do you know if there's any way to leave comments on it? I think that's a good summary, but it's the details, like discussed above, that matter. Old records of edits should IMHO always be kept (not just "ideally"), so that a history can be viewed and users can restrict which versions they see (e.g. "Don't show any edits made more than X minutes after a post was made"). That's IMHO essential, and I think most everyone here would agree. Also, references to records should reference a specific version of the record, not just the newest one - otherwise, some prankster could write a comment that reads "Kick all Nazis off Bluesky!" under an anti-Nazi post, wait for someone to share it, and then edit their post to be the Fourteen Words over a Nazi flag, or whatnot. Some users may want a config flag to show the newest versions of linked records (e.g. in quote posts), but it's still important that specific timestamped records be linkable. These are things that we need to make sure that the protocol supports. Otherwise a lot of people are going to be upset. |
|
The above examples aren't just theoretical, and to be fair, don't even require editing. It was admittedly quite amusing on Twitter, for example, when Dmitri Rogozin, a Russian Nazi and member of Putin's government, quote-tweeted someone who criticized him with text like "Based on your profile photo, you're a f***ot", and the person responded by changing their profile picture to a picture of Rogozin ;) But this is ideally the sort of thing isn't something we don't want happening. Linked records of all types (indeed, even profile pics) really need to be timestamped. |
You can leave comments on the roadmap in the linked GitHub conversation in the atproto discussion forum. In addition to or instead of that, you might want to create a new conversation thread specifically about post editing. I imagine the Protocol (atproto) section might be best, but that’s up to you :) |
|
fwiw, you can edit records already, and while Bluesky doesn't make it available in the App View or display edits, you can make this work with custom lexicon or alternative UIs today. There are a lot of UI affordances and social contract stuff to think about, but the beauty of ATProtocol is that we can have multiple, competing takes on what those should be. I would advocate for protocol level changes that make the scheme I've outline into atomic edits, because of race conditions https://verdverm.com/blog/adding-record-editing-with-history-to-atprotocol |
|
So I'm not a programmer but I posted a conceptual suggestion to the app that someone there suggested I post here. My thought was that it might be possible to avoid stealth edits and still allow editing by, when an edit occurs, replacing the original post with the edited version, and demoting the original post and all responses to being a response to the new post, maybe with some kind of tagging system as well. I hope that all makes sense and is useful. As I said, this isn't my area of expertise and I have no idea of the technical obstacles or problems involved. |
|
@Turnitup5000db the technical side is trivial compared to the social complexities. Some of them are sketched out in prior comments, however there are a lot of adversarial situation to think through as well as some that I would not consider adversarial (like fixing a typo or mispelling, how would you know if an edit crosses some threshold?)
One thing I really like about GitHub is that you can see the full history with minimal effort, just click the edited dropdown on this comment to see! |
I think all metadata attached to posts AND replies should be split up into A) cumulative and B) historical batches. So if you make a post, 10 people like it, then you edit it, and 5 more people like it therafter, then you edit it again, and another 5 people like it thereafter, then metadata should show you have:
A post detail page is the perfect place to show all of this, even if you don't want to show it in a post list page (i.e., the home feed), and opt to show some simplified subbatch of this metadata. Additionally, if one of your revisions causes previous likers to remove their likes, and additional bit of metadata for removed likes could also be shown, indicating that the revision might have been controversial (but future readers can decide for themselves whether the edit was controversial, since no one can know for certain why the likes were rescinded). So if revision 2 lost 3 likes, then on the post detail page the metadata would look like:
One fundamental feature I think should go hand in hand with editing posts (and replies) is for any user who in any way has interacted with a post (or reply) to receive a notification anytime an update is made to anything they have interacted with (e.g., liked, reposted, quote-posted, replied to, hidden, reported, muted, bookmarked). So if you get a notification, then you can decide if you want to alter any of your previous interactions or actions with the post, reply, or user. And along with the notification should come a requirement to click sometihing to acknowlege you want your like, comment, et al., to apply to the current version of the post / reply, so that your place in the post / reply metadata can be moved up to the metadata for the current post / reply version, otherwise if the interacting user ignores this, then their previous interactions are left in the metadata counts for the respective version they interacted with. In post editing windows You could also possibly add a check box like Wikimedia saying "this is a minor edit" (e.g., for just fixing typos). Then there could perhaps be an item in our account settingss to say "automatically advance my post / reply interactions to the current revision if an edit is a minor edit". This is in case it is too bothersome for users to go manually acknowledge that an edit has taken place, and it can certainly be abused, but ultimately it is stll up to the interacting user to look at current versions of posts and replies and make sure they want their interactions to still apply. So if you liked a post which said "I love orchids", then the user who posted it makes an edit to say "I HATE orchids!" and dishonestly checks the "minor edit" box, users as a whole could still also have the communal opportunity to flag the post / reply for "edit abuse" even if a given interactor has A) configured their account settings to auto-advance their content interactions to current content revisions and B) also ignores the fact that the post / reply has not ontly been editing, but its meaning fundamentally alterted. You have the opportunity to remove your like, or prevent your user settings from advancing your like to the current version, but no one can make you take either course of action, and other users can still moderate other users who routinely abuse any "minor edit" functionality. All of these changes should be protocol level. Other clients should be compliant with protocol-level features. If your alternative client is hiding these features from users, your client should be banned accessing data on this network, and should also be added to a blacklist of undesirable clients if you decide to also just implement your own network for your client to consume and lure unsuspecting new users to. There's no beneficial reason to balkanize this stuff, and any protocol is inherently opinionated, and these features benefit users, they are not mere a la carte garnishes for alt client / alt network devs to ignore, because why would you want to not benefit your users? |
I don't agree with this. While it may make sense for Bluesky records, we can build anything on ATProto and it will not make sense for all applications. The post, likes, and the graph are not protocol level, they are records of Bluesky lexicon a layer above the protocol. Not all record types will have user like and reply interactions. These kinds of discussions and choices are specific to an app.
This is kind of against the open ethos of ATProto and removes the competition in features and affordances. This is because what you are talking about are semantics a level up from the protocol on specific record types and behaviors. Certainly all clients should comply with the protocol spec. I think Bluesky will make their choice, many Bluesky 3rd party clients will strive to keep parity, while others will not. This is ok in my mind. Let the people decide which set of features and affordances they want rather than forcing one corporations choice on everyone (i.e. this is Bluesky's commitment to a credible exit) I'm not sure how technically possible it is. How would you know what client is making the API calls to the public endpoints and PDS instances? |
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
The text was updated successfully, but these errors were encountered: