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 @[email protected] 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 @[email protected] 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 @[email protected] 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.

[thomasjwebb]

I came here because I realized I need this feature too. I am totally fine and understanding that blocking a user this way won't automatically block any bridge they create in the future. I think creating placeholder accounts might partially violate the idea that it's opt-in. Also theoretically someone could create a bridge on a separate bridgy fed instance, or using separate software, or they may simply create an account on a fediverse server. The nature of decentralization is the protocol can't know which other accounts out there are the same person, though monolithic websites already have the issue of sockpuppets anyway.

Just being able to make your bridge account block non-bridged accounts would help a lot, and it should be in both directions (so bsky users could block non-bridged fedi accounts). It would also be powerful if bsky users could tell the bridge to block entire fedi servers, but that could be a separate issue.

[lucajet]

More than specifically block, what i want is to clean my follower list by removing people.

Would also be easier to convince people to opt in if you don't allow unbridged followers.
That's the grey area of people who didn't understandd the thing. (But i followed you ! isn't that enough ?)

I have already in my bs followers, people i would not have manually accepted in mastodon, scammers, wanna be influencer, people that i simply don't want to be associated with.

What if that famous guy, the transphobic one that got blocked by all the network, followed me searching for audience, and i couldn't remove the association.

People would notice and think i agree with hateful content

[snarfed]

More than specifically block, what i want is to clean my follower list by removing people.

Good point! This isn't actually possible in Bluesky right now, whether in the UI, API, or at the protocol level. From bluesky-social/social-app#1160 (comment) :

The issue is that every user controls their own dataset. When I "follow" somebody, what I'm doing is publishing a follow record on my account. When I block somebody, same thing: I publish a block record. A block record can override the behaviors of a follow record, but it can't force-remove the follow record from somebody else's repository.

[lucajet]

Yeah, so block for lack of better term 🙂

[Tamschi]

I'd like to request an extension for this: List blocks (on supporting networks).

Personally, I think it would be nice if the following all worked (depending on the remote network):

[un]block @[email protected]
[un]block [@]user.example.com
[un]block <web-url>
[un]block <at:-url>
[un]block <ActivityPub-actor-id>

where bracketed text is [optional] and angle-bracketed text is a <placeholder>, where <web-url> and <at:-url> can belong to an account or a moderation list.

Some of these are definitely more involved, so for starting out, blocking only users by only the respective handle would solve much of the problem.

[snarfed]

Done! Added two new DM commands, block and unblock: https://fed.brid.gy/docs#block

[lucajet]

this is great ! thank you