Please let me block users who aren't bridged

[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.)

[shiribailem]

I don't think there's any conflict with the users explicitly opting out, they should just be blocked by default anyways.

[shiribailem]

I think placeholder accounts would be reasonable, especially since those accounts aren't going to be discoverable accounts, they would only be generated on interaction and would only be found by either them following you, commenting, or you directly putting them in.

I think they should just be the converted username, with the name on the account set to " - Unbridged Account", bio just "This profile is a placeholder because the source account interacted with a bridged account, this exists to preserve blocks.
If this is your account and you enabled bridging, please give it at least 24 hours to update. If you have opted out of bridging no information beyond username is being collected, stored, or transferred. This account exists only because you followed or commented on a bridged profile or post and only so that the bridged user is able to block you. (If you commented your post was ignored)"

Use just the first line and a couple of links if there's a character limit.

I'll be completely at wits end if they get angry that they followed a user that was bridged and get angry that the bridge has seen their username exists...

[shiribailem]

As I'm waiting for a friend's profile to populate across the bridge a few hours after they followed it... Adding that a further benefit of a placeholder account would be that I could follow them immediately and not have to wait for the bridge to catch up to them...

[lucajet]

as time pass, and bridgy-fed interactions start to become popular, this is getting relevant.

[snarfed]

Understood. PRs are welcome!

First we'd want to settle on the design. I get the placeholder idea, but I think it's unlikely due to the amount of complexity involved. I'm inclined to go with @Mieridduryn's original suggestion:

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.

@tesaguri's concern is real:

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.

...but Bridgy Fed can't directly do anything about it, since it can't make your native account block anyone. However, we could record the non-bridged users you've blocked, and when any of them enables the bridge, we could DM you a notification so you can block them yourself. Could be worthwhile for a phase two of this feature.