Bluesky edits aren't visible (blocked on bsky.app)

[snarfed]

https://bsky.app/profile/snarfed.org.web.brid.gy/post/3kps4z7ve6hg2 is federated from https://snarfed.org/2024-04-10_52782 . I originally posted (and federated) it without u-photo, so the image didn't appear in ATProto. I added u-photo and re-federated it, and the photo appeared in the fediverse, but not in Bluesky. Not sure if updates aren't working, or images, or both.

[snarfed]

This might be a bsky.app issue. I tried again with just a text post and edit, and atproto.tools shows both the create and the update as valid, https://atproto.tools/records?did=did%3Aplc%3Abg5udl25mvzg3rt7l5n2hzet&collection=app.bsky.feed.post&rkey=3krh65hkwbp42 , but bsky.app only shows the original create: https://bsky.app/profile/snarfed.indieweb.social.ap.brid.gy/post/3krh65hkwbp42

[snarfed]

^ if so, the answer here is probably to add this to the docs.

[snarfed]

(Oh and images have worked in original AP => ATProto posts, so it's an update thing.)

[snarfed]

Updated docs, will be visible at https://fed.brid.gy/docs#bluesky-edits soon.

[njlarsson]

I edited a reply twice in Mastodon. The first two versions got picked up as different replies in Bluesky, but the third and final version never appeared. I understand that I can’t expect editing to work properly, but I thought this was strange behavior that might be interesting. This is the reply I edited: https://mastodon.nu/@avadeaux/112469287039821443

[snarfed]

Whoa, that's definitely odd! Thanks for reporting, I see them both on https://bsky.app/profile/avadeaux.mastodon.nu.ap.brid.gy/post/3ksuc7mn4vhn2 . Will look.

[bnewbold]

Yeah, things will just be very janky in the Bluesky app around this until we properly implement post editing at the UI/UX level.

As you can tell, how to update a record is pretty clear. What we want to support is keeping the old versions of the record around in the repo in some way (eg, a repo path extension with the CID as another path segment), and then clarify/specify what the behaviors of things like a "reply to a previous version" or "liked a previous version" should be after an edit.

For now, you might find it more robust/functional to delete the record and then re-create it with the same rkey and overall AT-URI, in separate commits, instead of doing an "update" in a single commit? This is sort of just a stab in the dark.

[snarfed]

What we want to support is keeping the old versions of the record around in the repo in some way (eg, a repo path extension with the CID as another path segment), and then clarify/specify what the behaviors of things like a "reply to a previous version" or "liked a previous version" should be after an edit.

Oh man, true. prev is dead, long live prev, eh?

For now, you might find it more robust/functional to delete the record and then re-create it with the same rkey and overall AT-URI, in separate commits, instead of doing an "update" in a single commit? This is sort of just a stab in the dark.

Lol true! Good idea, like Mastodon's "delete and redraft" but under the covers. This isn't high priority for me right now, but if it bubbles up before you all figure this out on your end, I can definitely try this. Thanks!