Do any nostr clients have the ability to block an entire relay? I’m thinking folks who don’t want to see posts which are mirrored from another network like minds or monstr’s fediverse gateway?
How would that even work?
Discussion
If the relay isn’t a part of your list you won’t see posts from it. What am I missing?
Depends on the app, some pick up and read from relays they see others mention. They write to the ones you specify but read from tons. Some apps only read from the specific relays in your list.
i think i see what you are saying. basically any notes on the blocked relay you want to be filtered out of the collated feed of notes from all other relays. i guess it could be done by a client but it seems like it would be a rarely used feature
ah yeah I see, interesting problem. potentially lists can solve for this? There’s already the NIP for muting pubkeys, maybe this could be extended to relays
A lot of client's rebroadcast automatically or from interaction. You’re not signing permission to just the relay you are broadcasting to. Most client's rebroadcast automatically or when you interact with content. So you only have Eden, you note “this should only be seen on eden” and a couple minutes later everyone sees it anyways.
just remove said relay from your list of relays. what client are you using?
I use my own nostr app… nos.social
More I’m trying to find patterns other apps are using because I want to learn and not reinvent the wheel.
the users coming out of mostr.pub are nip5 to that domain so easy filter
or is it their names are?
This would probably be the only viable answer. Dropping all traffic from a relay doesn't stop that same event from finding its way to another relay, and then to your client. You're sort of fighting the way nostr functions by doing that. I suspect it will be ultimately fruitless except by rejecting NIP-05 identities based on domain, something that some relays can already do themselves, and would be straightforward.
I suppose they are all using mostr nip-5 verification.
That is correct. As part of the bridge bounty, bridged fediverse accounts were expected to have a NIP-05 identity at the bridge, to aid in controlling the flow of posts since, as we have seen, they can be torrential for users who only want to see a few accounts but not to be drowned in the flood on things like global feeds.
One thing to consider, though is a separate toggle for whether a relay appears in the global feed. The android client nostros does this and I rather like it. A natural extension to this would be to add individuals followed from that relay back into the list. You could easily do the exact same for the domain portion of a NIP-05 identity. More (sensible) toggles is better than shotgun style "mute the living shit out of everything" a la fediverse style blocklists and dns blackholing.
I believe this would facilitate mitigating clutter on such things, and still give users flexibility, rather than being constrained by the client they use
https://gist.github.com/fiatjaf/ea7d21e81359e1eb8abcb8805306adaa
The bounty, for reference
yep thats why nostr is so good, if the content is passed to anyone it likely cant be stopped
The fediverse bridge only posts to relay.mostr.pub, but I discovered the posts "leak" out, a thing the protocol allows. It's possible someone is copying them to other relays for archival purposes, and some clients forwards mentioned events when a user quotes or replies to them. In other words, not it's not possible to block posts that originated on a single relay. (You could block the relay itself by IP). But as #[2] mentioned below, users from the bridge have nip05 identifiers at mostr.pub, a thing added to make detecting them easier. -I created the bridge