I will see stuff rebroadcast from that topic-based relay, so aside from it functioning like hashtagless hashtag to only read from there what’s the point?

Reply to this note

Please Login to reply.

Discussion

Likely you won’t see it;

I’m working on improving relay segregation so we stop this publish-everywhere madness

don’t get me wrong, I might want to see it, but just commenting on the futile nature of trying to control this from both the relay level and end user level.

It’s not about trying to control really; we just need better usage patterns on clients

It’s absurd trying to have all/most content in all relays: leads to centralization.

The gossip-style relay usage (I’m implementing it in NDK) and better relay groups selection in clients will fix this

Shouldn’t a relay just be able to say “no rebroadcast” and the white list clients that respect this?

Whitelist because you can’t force clients to respect it.

I’d love to build locals/discord/Patreon like functionality, but it just doesn’t work if you interact with it and your client rebroadcast it WillyNilly.

I don't think you can prevent an event from being published to it, other than enforcing some kind of whitelist, whether it's pubkey, tag, whatever based.

that's what I mean by clients needing to interact with relays better and de-commoditize them.

We'll get there

when you say “publish to it” what is the it?

I’m suggesting a client respect a relay running a no rebroadcast nip, so if it pulls from that relay, and then I interact with it, it won’t rebroadcast the note I’m replying too if it came from the topic specific relay. I’m not suggesting relays stop it from being published too.