Follows from non-opted-in users don't work

[qazmlp]

(or at least that's my guess for what's happening here)

Since "hide from logged out view" users don't get an AP actor at all, when they follow a bridged AP user, this Follow activity is either not bridged or is rejected by Mastodon. On Bluesky and as per Bridgy, the follow succeeds otherwise.

This creates two issues:

• If all followers are hidden this way, then the home instance won't send Public posts to the bsky.brid.gy instance, meaning they won't be visible on Bluesky.
• More importantly, while following would effectively succeed while at least one bridged Follow was active, the AP user isn't made aware of these hidden followers and, even if aware somehow, has no way to block them.

#974 is related, but would fix this only for followers who have opted into the bridge in the opposite direction.
To fix this issue here, I think the only option is to present a very minimal stub account for the Bsky user on the AP side, ideally with a link to the Bsky profile and something like "This user has not opted into bridging their activity." as bio.

[snarfed]

Good points! Thanks for filing.

One approach would be to have @[email protected] follow everyone from the fediverse who opts in, so that we at least get their posts and can deliver them onward. The drawback is, I think that's effectively follow hiding/proxying, which is frowned upon, and the fediverse user couldn't reject follows like you mention.

I'm reluctant to bridge anything for users who haven't opted in though, even as little as their handle. So, hrm.

[qazmlp]

A third option would be to block everyone who follows using Bluesky unless they opt in, but I think that would be a worse and much more confusing/open-to-harmful-misinterpretation user-experience.

At least on fedi, you could add a note to the bio that "Following makes your handle visible to Bsky.".
Technically on Bsky too, but bio space is definitely more limited, so maybe "Following bridges your handle."?

[snarfed]

I think this is broader than explicitly opted out accounts, I think it affects follow from all accounts that haven't actually opted in and bridged themselves yet. eg the three Bluesky follows on https://fed.brid.gy/ap/@[email protected]/notifications failed because they're not bridged, so we don't serve AP actors for them, so when the remote AP instance tries to fetch their actor and keys to verify the HTTP Signature, we don't serve them.

[gamefreak613]

Following from a bridged Bluesky account seems to have allowed the @[email protected] posts start to flow. Just FYI.

[snarfed]

We're now following back from @[email protected] (#999), which has the effect of proxying bridged fediverse posts to Bluesky followers even if they haven't opted in themselves. The lack of transparency to fediverse users is unfortunate, but it at least solves the immediate problem here.

Longer term, the answer may be just to make Bluesky opt out instead, since the norms and expectations there are different.

[qazmlp]

This works for me personally (I tested it earlier.), but I think until the transparency problem is fixed, I'll likely recommend others against enabling the bridge unless they're okay with that specifically.

There's also still the issue that users who first follow and then opt-in to the bridge continue to not appear as followers indefinitely, unless this was fixed in a change that I didn't notice.

That said, Bluesky just announced DMs, which may make a discoverable opt-in approach viable over there, and could alert users about stubs being created when they follow a bridged user.
Another way to lower the friction and make using the bridge more natural would be if, if follower stubs are added at some point, following back such a stub account was a way to request an opt-in from that user. That all mainly hinges on solving #976 and adding a remark that following makes ones handle visible on ActivityPub.

(This is largely conjecture, but I think if Bsky users were automatically fully opted into Bridgy, then many fediverse admins would likely limit the bridge, since there'd be a spillage of content from people who actively dislike "Mastodon".)

[snarfed]

Understood!

(This is largely conjecture, but I think if Bsky users were automatically fully opted into Bridgy, then many fediverse admins would likely limit the bridge, since there'd be a spillage of content from people who actively dislike "Mastodon".)

Hmm. Maybe! They would still only show up for people who chose to follow those users, though. I guess I hope most fediverse admins aren't so petty that they'd limit an instance just because some of its users criticize Mastodon - tons of fediverse people themselves criticize Mastodon! - but who knows.

[qazmlp]

Understood!

(This is largely conjecture, but I think if Bsky users were automatically fully opted into Bridgy, then many fediverse admins would likely limit the bridge, since there'd be a spillage of content from people who actively dislike "Mastodon".)

Hmm. Maybe! They would still only show up for people who chose to follow those users, though. I guess I hope most fediverse admins aren't so petty that they'd limit an instance just because some of its users criticize Mastodon - tons of fediverse people themselves criticize Mastodon! - but who knows.

Sorry, I wasn't clear enough, it's not so much criticism of the fediverse directly as it is the difference in tone and posting habits that usually comes with that. But maybe it's not that much of an issue, since admins can limit individual users anyway.

You're currently addressing bridged posts "to" "https://www.w3.org/ns/activitystreams#Public", which makes them appear in discovery features (pretty much everywhere but the official Mastodon mobile app, which removed the "Federated feed". Other software like Firefish also has an algorithmic home feed by default).
The effect is somewhat limited in that they still should only appear on instances where there's at least one follower, which is fine for small instances, but it can get tricky on large instances. (mastodon.social would most likely be totally fine with it though, but then again that place is often limited elsewhere because it's a bit too rowdy at times.)

I think that "cc"-addressing the bridged posts to the …#Public collection ('Unlisted'/'Quite public', which acts like Public but without discovery features) would have too many adverse effects currently, though. First off it does limit reach (also by making some people hesitant to boost and causing hashtag search exclusion) which the bridging user most likely doesn't want, and second it makes most clients automatically drop reply visibility to match, which would mean replies wouldn't be bridged back unless their author remembers to change the visibility each time.

[snarfed]

Right! That audience addressing analysis parallels my own a while back. Maybe there's an argument that to public is "too" public - maybe - but I came down a bit more on the side that cc public ie unlisted isn't public enough. Not set in stone, we'll see how it all goes.