Bridge follows from before bridging aren't bridged

[qazmlp]

Related to #975 but not the same.

When someone follows me on AP, I see this badge on their profile (on their header image):

However, my bridged account doesn't show it:

On AT, I'm mutuals with myself:

I followed @Qazm.tiggi.es.ap.brid.gy before opting in with @qazm.bsky.social.

I know that I could most likely fix this by un- and re-following, but it would be nice if, once someone opts into bridging, the bridge would bridge their existing relevant follows too.

(I'm not sure if there's anti-spam that would trigger if the account did this all at once. It may be good to have it as a background job that cleans up desynchronised relationships slowly over time, but ideally still in order for individual acount-instance pairs.)

[snarfed]

Interesting! Definitely a more advanced feature, but agreed, this would be nice!

[snarfed]

Thinking about this a bit. Bridged accounts aren't normal accounts that you can log into, so having them follow people wouldn't do much. @qazmlp can you think of any user-visible impact of it other than this "follow you" badge?

If that's the only effect, and if doing this "right" would require ongoing synching, it seems pretty unlikely. It'd be a fair amount of complexity for a very minor cosmetic effect.

[qazmlp]

Thinking about this a bit. Bridged accounts aren't normal accounts that you can log into, so having them follow people wouldn't do much. @qazmlp can you think of any user-visible impact of it other than this "follow you" badge?

If that's the only effect, and if doing this "right" would require ongoing synching, it seems pretty unlikely. It'd be a fair amount of complexity for a very minor cosmetic effect.

I think it's relatively rare to have an effect with ActivityPub apps, aside from being able to see posts and post delivery, which both aren't relevant here. Bridgy Fed itself is the only example that comes to mind on that end, though some apps may have algorithmic feeds that prioritise mutuals.

On the Bluesky side it looks a bit different. https://furryli.st is follow-activated (but that account followed @ap.brid.gy during the outage and afaik hasn't retried, so it's not actually available from ActivityPub), https://bsky.app/profile/bsky.app/feed/mutuals is driven by it, it's important for the social proof feature and it probably affects some algorithmic curation in more subtle ways than that.

(If you added user-to-user DM support to Bridgy Fed, then it would be important for that too due to the default follows-only permission, but I personally would frankly not want to deal with that in your place. Too many worms in that can unless you can make it effectively E2EE. Reply controls are not affected in a way that would be relevant with Bridgy Fed's current feature set, either, if I'm not completely mistaken.)

That said, I actually don't think this would require regular syncing outside of outage recovery on the ATProto side. If I look at the Bridgy Fed followers page of my main account, it's clear that the bridge itself already knows about the connection in both directions. I think it would be enough if you processed the existing unbridged outbound follows that you already know about once when someone opts into bridging to the respective network.

I'd be thankful if you could run that process for existing accounts once too, just to get everyone on the same page, because being (not) mutuals may be a source of social misunderstandings if there's a discrepancy, but personally I could live without it.

The part where you may want to do a(n infrequent or slow) periodic sync would be retrieving specifically the e.g. @ap.brid.gy account's followers from the Bluesky appview, as aside from missed follows there's also the possibility of missed blocks there, which in terms of data handling are the larger issue in my eyes.
I don't know if you could just inject corrections for detected differences into your incoming event stream though, or what your approach to appview-based account removals that Bluesky imposes is.

[snarfed]

I think it would be enough if you processed the existing unbridged outbound follows that you already know about once when someone opts into bridging to the respective network.

True! It's still added work and complexity, but you're right, after the initial backfill, we could do it in band, in the existing follow processing, without a separate background synching process.

The benefit here is still pretty minor and vague to warrant the work, so I don't plan to prioritize it myself any time soon, but I'll happily review and accept PR(s), and I'll keep the issue open to track it!