Post

ok, deep breath… we're discussing *potentially* adding post editing to Bluesky this year.

i know. it's the #1 thing yall have been asking for. it's a Bluesky meme. every time we post something, people reply "edit posts wen?" we see you. we have always seen you. so why haven't we shipped it?

post editing is easy to build, but it adds a bunch of complexity and risk that's hidden until you look below the surface.

there are various safety and spam risks, but the core problem is this: someone writes "puppies are the best 🐶", racks up engagement, then edits it to say something horrible or swaps in a link to a malicious site. now people look like they endorsed it.

this gets especially ugly with reposts and quote posts. plus, post editing adds more complexity and required tooling for our T&S team. so if we do this, we'll need guardrails.

here's what we're thinking: 1) you have 5 minutes to edit a post 2) you can only edit each posts once 3) images and videos can’t be edited 4) a prominent "edited" badge appears on the post 5) version history is visible to everyone 6) your account has to be at least a week old

some of these are tough tradeoffs. 5 minutes won't catch the typo you spot two hours later. one edit means you can't fix the fix. we know. it's the price of mitigating these risks and keeping people safe here. and this is what might be feasible for our small team.

tell me: - do these limits feel ok? - is 5 minutes acceptable? - why is post editing important to you?

But there are no limits or obvious indications that someone edited their post via goat, pds.ls, etc. Not saying these aren’t good ideas, but about as secure as this gate. How would such a loophole be closed or, if useful functionality to retain, show indications of new CIDs in AppViews?

Realistically, this is an AppView concern (based on the way atproto is designed today). I'm pretty confident this is just relevant to Bluesky as an AppView. Other AppViews have to make their own decisions on how to handle it.

Sure, but my point was that perhaps Bluesky should - or maybe they already are thinking about it - show indications of edits if the CID changes. The AppView could still limit “non-techy” edits to 5 minutes and all that to combat abuse, but always show signs of edits.

Yeah, but if the Bluesky AppView caches the post content based on these criteria, do Bluesky users care if the CID changed? E.g. if I edit my post via PDSls but Bluesky doesn’t show the edit, does that matter? Don’t get me wrong, I’m on board for surfacing edited content when it’s important.

Fair point. At the very least it would provide some deniability.

Deniability? I don’t follow. Deniability for what? 🤔

If someone abused edits to go from a well-liked “dogs are awesome” to something far more terrible…like “cats are awesome”*. No matter how the post was edited, people could at least deny they liked the latter. *) I kid…mostly…but didn’t want to use something truly terrible even as an example.

I see. I think this is still a concern on the individual AppView level, tho. For example, another AppView may just as easily allow unlimited editing, and in that scenario surfacing all exits makes a lot of sense. For Bluesky, where they’re not exposing that level of edits, it’s not so useful.

The challenge (from my perspective) is that the ability to edit records freely on atproto is a boon for some apps (like Cartridge.dev, where pages operate more like wikis). With that in mind, it’s important for each AppView (incl. Bluesky) to define boundaries on how edits will be applied.

NOW, I’ll argue against myself a little bit. Most Bluesky users don’t understand the protocol. They don’t know about PDSls, or other clients and AppViews. They may not be aware that something they liked on Bluesky has been edited to be awful and now displays their like on another app.

I think that’s makes the UX you’re talking about valuable. Something telling users, “Hey, this content has changed and shits awful if you look at it elsewhere.”