Fedi -> Bsky: Please let me block Bsky users without them bridging

[Mieridduryn]

Hi, I don't want minors to follow my Mastodon account. I bridged it, and within minutes, a minor was following it.

I want to be able to block this minor, and any other minors who ignore my bio and pinned post, without them needing to bridge first.

I suggest that this be implemented by dming @bsky.brid.gy@bsky.brid.gy the bsky user's username and a command, sort of like how you request that a user bridge over, and the mirrored account on bsky will block that bsky user.

[snarfed]

Understood! Could be a good idea.

A couple points as background here:

• Bridgy Fed does translate blocks across protocols. Blocking a bridged user blocks them in their native network. https://fed.brid.gy/docs#moderation
• Bridgy Fed also translates Bluesky labels to/from fediverse content warnings and the sensitive flag, including for NSFW content.

Regardless, I definitely get that the idea here is to be able to block users who haven't bridged themselves.

[Tamschi]

I'm not sure that the way the sensitive flag is currently bridged (as unspecific 'graphic' label) actually prevents minors from seeing the content on Bluesky. The US is generally somewhat okay with minors seeing violence to an extent, so I would be (imo: positively) surprised if the label is age-gated on Bluesky.

That said, I think this is an important safety function in general.

[evant]

+1 to this, I had to disable bridging my account for the moment because some creep followed my on bluesky and I couldn't figure out how to block them.

[Mieridduryn]

Understood! Could be a good idea.

A couple points as background here:

* Bridgy Fed does translate blocks across protocols. Blocking a bridged user blocks them in their native network. https://fed.brid.gy/docs#moderation

* Bridgy Fed also translates Bluesky labels to/from fediverse content warnings and the `sensitive` flag, including for NSFW content.

Regardless, I definitely get that the idea here is to be able to block users who haven't bridged themselves.

Yeah, someone suggested that I ask them to bridge and then block them, but bridging is optional on their end. They can just refuse to bridge and stay unblocked. 😔 Plus, I wanna use my 10 daily bridging requests on friends or people I look up to, not people I want to block.

[tesaguri]

I suggest that this be implemented by dming @bsky.brid.gy@bsky.brid.gy the bsky user's username and a command, sort of like how you request that a user bridge over, and the mirrored account on bsky will block that bsky user.

I think a drawback of that approach is that your Fediverse server won't recognize the block, so if the blocked user opts into bridging later, your server will treat the bridged profile as if you hadn't blocked them. Although I guess Bridgy Fed could still prevent the blocked user from interacting with you, and you could just block the bridged profile again to make your server aware of the block, I think the UX would be suboptimal either way.

An alternative approach would be to make Bridgy Fed dynamically create placeholder accounts for non-bridged users (in response to WebFinger and GET /ap/did:* requests for Fediverse => Atmosphere, or to GET /.well-known/atproto-did requests for wildcard domain requests for Atmosphere => other networks), whose profile would only have an explanatory boilerplate message, which you can block just the same way you block any normal accounts.

As a bonus, this would allow you to follow the placeholder so that you could automatically receive activities from the other user once they opt into bridging.

[Tamschi]

It's technically possible to do that, but depending on the networks involved, we'd end up getting broadly defederated because of the backlash against too-broad discoverability or with stale profiles that won't update automatically for a while after the user does bridge their account. This solution also wouldn't work for users who have directly opted their account out of bridging, which should delete their profiles on the other network entirely.

(Note that ATProto does no such specific lookup, either. Users and profile updates are announced globally there and the information is cached by the AppView to populate search, so we never see it if someone tries to look up a user that doesn't exist yet (to my knowledge). We could still create the stub in response to the follow, technically, but this likely wouldn't be socially acceptable.)