support for backfilling conversations between bs and fediverse

[lucajet]

Sorry to use a schema, but explaining issues and features it's getting harder with time

case scenario

bluesky user A, bridged, mutual connection with me on mastodon
bluesky user B, bridged, mutual connection with me on mastodon

A start a conversation, the post appear in my mastodon timeline
B reply to the conversation, B post don't appear in my mastodon timeline
I reply to A , without reading (my friend's) B answer

Following B, I'm expecting to receive also B replies, if they are to someone that's bridged too, especially if i do know A

I notice because both post are visibile on bluesky web interface so i can go watch the whole thread there.
But sometime BS people that are bridged to fediverse has such bs settings that you can see their messages just if you saw them from mastodon (and that is wierd by its own)

[snarfed]

Yes! This is #1218; more background in #639 and #1382.

We've gone back and forth on reply delivery a lot. In general, this is the age-old incomplete replies problem on the fediverse, not bridge-specific, right? https://www.w3.org/TR/activitypub/#inbox-forwarding . Some fediverse software does go to extra lengths to fill in missing replies, and there are standalone tools like https://github.com/nanos/fedifetcher - they asked us for a similar thing just recently in #1739 - but at the end of the day, those will always be band-aids.

Having said that, I could consider sending all replies to all followers' instances. I worry a bit about the cost increase, but we could definitely still try it.

[lucajet]

I'm not sure i understand it like "fediverse reply missing" issue.
Those missing branches on fediverse happen because B don't know who are A followers.

Should be simpler than fedifetcher.

In this case B knows who i am.
Do we need to backtrace the whole thread ?

What's the difference in ATproto between an original post and a reply ?
Shouldn't B send me all his public stuff, regardless of A ? If A is bridged even if i'm not following, isn't B's reply a public message like another?
Maybe i won't see to whom was addressed B reply.

just asking

[snarfed]

The technical answer here is, this is AS2 audience targeting. It's a complicated spec, but it does more or less fully define which actors you should send a given activity to, including for replies.

Having said that, AS2 audience targeting is complicated enough and niche enough that I don't know of many fediverse servers that even try to faithfully implement it, or even know much about it.

Also, part of the reason we don't currently deliver replies to all followers is cost. I haven't done an accurate estimate, but if we did, I suspect it would significantly increase our load.

Anyway, this is definitely a good idea, and you're right, it would make more replies visible in more places in the fediverse! Let's continue to track it in #1208.

[Tamschi]

I do think this is a Bridgy-Fed-specific issue rather than ActivityPub reply visibility issues. ActivityPub servers generally deliver a post visible to followers to all followers (including posts that are replies, and not just self replies), so this particular case is not a problem.

AP servers are more likely than Bluesky to show replies in the home feed where the follower isn't following the OP though, compared to Bluesky where this is suppressed in some cases. In terms of parity, delivering to AP servers where (also) the OP author has a follower may be enough, which hopefully wouldn't cost much since Bluesky post data includes the OP id that can be truncated to the user's.
Missing posts in-between would be fetched automatically by most AP servers.

[snarfed]

ActivityPub servers generally deliver a post visible to followers to all followers (including posts that are replies, and not just self replies)

Out of curiousity, do you have more information here? Is there a survey on this, or other research? Or just general consensus from...somewhere? I don't disbelieve you, at least not entirely, but I'd love to know more detail.

[snarfed]

Duplicate of #1218