reply

Interesting! You mean this moderation policy?

You're right, reports are like other features: bridging them across networks can't guarantee exact parity. I expect to monitor them myself at first, but I don't know that I always will. At best, all I can do is block someone from the bridge itself, which doesn't affect them inside their own network at all. Bridging the report to the source network/instance, along with bridging common shared blocklists, are probably the better ways to have broader, more meaningful impact.

Standard

One thought on “

  1. @snarfed.org Yeah, mainly the ‘no nazi bar’ part. To my knowledge, Nostr has no way at all to moderate accounts (aside from relay bans?), so you’d have to keep the bridge clean on your end somehow if accounts and relays there can initiate contact. I kinda suspect that most fedi instances will block the Nostr bridge on sight or preemptively though…not even just because of fascists, but because there’s likely an extreme culture difference.

    I think you might eventually have to put in some filters for the bridge directly, e.g. sourced from specific Bsky moderation lists, since we, at least currently, can’t sensibly subscribe to blocklists on fedi. (I think there’s some automation that can do that through the Mastodon API maybe, but that’s not something that’s commonly used. From what I can tell, trying to offload this to instances would also get the bridge as a whole blocked widely.)

    Have you thought about offering an opt-in bridge on another set of subdomains, btw? That way instances could choose the first-interaction model that works best for them, and when a specific user opts in that’s an opportunity for you to make them appear in searches on the other side too.
    (I do think that admins here have the tools to e.g. require confirmation for any follow-requests that come from the bridge, though, even if that and related measures are comparatively blunt tools.)

Leave a Reply

Your email address will not be published. Required fields are marked *