Atproto reply to unbridged post gets bridged to AP

[TomCasavant]

https://fed.brid.gy/r/https://bsky.app/profile/did:plc:dzh2pohi5hgfrtf5r572zqqq/post/3kyjzxmery222 (https://bsky.app/profile/globetrotters.bsky.social/post/3kyjzxmery222)

My assumption is that it's because I @ mentioned my account though I'm not certain

[snarfed]

Hmm, the in-reply to post looks bridged to me, I see it if I search for https://fed.brid.gy/r/https://bsky.app/profile/did:plc:xhcl6cbefxy7nsgq6x6ht67f/post/3kyjgdlullp26 in a Mastodon instance.

[TomCasavant]

If it was bridged then the issue is I'm not getting notifications for that accounts' replies, but I'm pretty sure he just bridged his account sometime last night so I assume searching for the post would cause it to bridge to AP?

Same thing happened with this one: https://bsky.app/profile/zayne.bsky.social/post/3kyhp24obhx2j

[snarfed]

Ah, you're right! Looks like zayne.bsky.social bridged their account at 7/31 03:12:17 UTC, and that post was at 7/30 18:23 UTC.

The root cause here is probably that "is this post bridged" is well defined for AP => Bluesky, since Bluesky requires us to proactively translate and push a post to their relay to make it visible, but that's not true for Bluesky => AP. When someone bridges their Bluesky account, we don't retroactively deliver their posts to the fediverse - since they don't yet have no followers at that point, so we don't have anywhere to deliver them - but historical posts do become available in AP, eg fediverse instances can fetch them if a user searches for them.

So we don't have an explicit record of whether any specific Bluesky post has been "bridged" into the fediverse, so our reply check of "has the parent been bridged?" doesn't really apply. Hrm.

I guess I could hack it by comparing the parent post's timestamp to when the account was bridged. Not ideal, but it's something.

[qazmlp]

Mastodon should be fetching the parent post automatically already (see https://github.com/mastodon/mastodon/blob/f6dc8ae8e39cbc626b001cd1026a6fa2de8f4215/app/lib/activitypub/activity/create.rb#L90-L91 and https://github.com/mastodon/mastodon/blob/f6dc8ae8e39cbc626b001cd1026a6fa2de8f4215/app/workers/thread_resolve_worker.rb#L13-L14).

For this to work for yet unknown statuses, I assume Bridgy Fed has to trigger bridging by the post fetch (not just on WebFinger) and also has to block the incoming fetch until it has done so. Otherwise, the first instance(s) the reply gets pushed to will fail to fetch the parent and (in Mastodon's case) regard the reply as the start of the thread from then on.

[TomCasavant]

In this specific case I think my reply shouldn't have been bridged because the account I replied to hadn't opted in yet which is probably easier to check than checking if the post has been bridged

Your scenario would be:

1. Unbridged bluesky account A posts
2. Unbridged bluesky account A opts-in
3. Any Bridged account replies to (unbridged) original post

Which should be solved by mastodon attempting to get the parent post (though I think this is a common issue in mastodon in general or at least was an issue?)

This scenario is:

1. Unbridged bluesky account A posts
2. Bridged bluesky account B replies with @ mention to bridged fediverse account
3. Fediverse account sees the @ mention reply but doesn't see the post it replied to (because original account still isn't opted in)

Unless I'm confused about the timeline?

[snarfed]

Good points! Looks like you're not confused about the timeline. Your reply was at 07/31 00:14:44 UTC, 3h before zayne.bsky.social bridged their account at 7/31 03:12:17 UTC.

Your original hunch was right: the only AP inbox we delivered your reply to was https://tomkahe.com/users/tom/inbox , since you @-mentioned that account.

I don't know the ideal answer here. On the one hand, the original post was from someone who wasn't (yet) bridged. On the other hand, you @-mentioned someone who was bridged. BF delivered your reply to the @-mentioned user, and nowhere else.

If I understand right, in this case, you think the reply shouldn't be delivered anywhere in the fediverse? Totally ok if so, just checking.

[TomCasavant]

If I understand right, in this case, you think the reply shouldn't be delivered anywhere in the fediverse? Totally ok if so, just checking.

Yeah that's my thinking. Not sure if anyone has any other thoughts on it ( I can see the benefits of getting a notice whenever you're mentioned ) but I feel like it would just end up causing a lot of confusion- unless you noted somehow that there's an unbridged reply.

Also for the same reason I don't like how any @ ed user in Mastodon becomes part of a DM etc, I think it's just unexpected behavior. And then if you end up in a chain of replies it could get weird

• Unbridged post
• Bridged reply
• Unbridged
• Unbridged
• Bridged

etc.

[qazmlp]

Just happened to me too (because I @-mentioned my Mastodon account two posts down).

Maybe the answer is to, while an account isn't bridged, serve the inReplyTo.id pointing to one of its posts suffixed with ?bridged=false and then unconditionally serve a tombstone from there? It could say something like "Referenced an ATProto account that isn't bridged to ActivityPub. It's possible that this account or post never existed. You can try to view it on Bluesky.". It would have to be attributed to a valid account, but you could use a similar ?bridged=false version that just reflects a placeholder without performing a lookup.

(I don't think Mastodon could recover a thread that's been detached in either case. It's likely prudent to not redirect-to or serve the ?bridged=false version for the unbridged ID without it, as otherwise something might erroneously persist that redirect. Serving placeholders with a single static ID would likely be a bad idea too, as Mastodon would attach all the dangling data there then and make it browsable that way.)