Nostr Web Client

possibly yes. I had recommended this to nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgspr3mhxue69uhksmmyd33x7epwvdhhyctrd3jjuar0dak8xtcppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7208x3z in the past, where a community can run an 'agent' somewhere (a bot, with the community root key).

The reason that devs keep wanting to put logic directly into the relay is that nostr has no official spec for moderation of a relay and the nostr world is very opposed to talking about moderation or making it easy, so it is a green field.

As a relay operations team (could be a person, could be a team): The requirement of moderating a relay will not be going away.

And then, we have communities that *also need the exact same same types of moderation capability.

So, this is why I believe nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszxmhwden5te0wfjkccte9emk2um5v4exucn5vvhxxmmd9uq3xamnwvaz7tmhda6zuat50phjummwv5hsx7c9z9 concluded in nip29 it would be simpler architecture wise, to combine these. Which does sacrifice the separation of the two and removes the ability of a community to use a relay that is multi-purpose. I'm unsure how 0x is managing to have multiple communities on their single relay, as my understanding is that the operator of that relay is also the admin for the community (the relay has the private key).

The basic structure of moderation I employ on relay.tools is for example: Relay is owned by a root key, this is 'super admin level' access to the relay settings. The next level of access is moderator level which can do anything except for change moderators and change relay profile/description. Then there are the relay user level which is the normal join/post/read. This could be refined but its what i started with.

Say I'm a relay operator and i want to contribute to a community by mirroring the content, if the group allows my relay into the list, ideally i should not need the community admin key for this..

Communities will likely want a similar tiered access scheme and it will *have to combine with the relay level access scheme at some point if the community wants to delete notes that they do not have a key for. This is all a lot to think about.

Enjoy 🌝

hodlbod 11mo ago

It would not be hard to adapt keys to relays in a transport-agnostic way. Just add a new event kind 3xxxx which means "I am a relay" with tags declaring relay address under different transport (wss, onion, etc).

> The reason that devs keep wanting to put logic directly into the relay is that nostr has no official spec for moderation of a relay and the nostr world is very opposed to talking about moderation or making it easy, so it is a green field.

This misses the point for me. Relays largely already have everything they need to do moderation (nip 56, auth, and deleting stuff), which means the best form of moderation is going to be implicit on the protocol level, explicit on the human level.

But I agree that the needs of a community for policy enforcement neatly match those of any kind of relay.

Reply to this note

Please Login to reply.

Discussion

semisol 11mo ago

Relay-side moderation also has the problem it interferes negatively with caches like nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s's NostrDB

cloud fodder 11mo ago

nip56 was created to get damus into the app store. not a lot of thought was put into that.

what is missing is fine grain control. clients decided to send reports to all relays (flawed). imo to really manage a relay you are purposefully telling it what to do, and from the convenience of one key that you are reading the relay from. if you want to delete offtopic or etc from your relay, you do not care about other relays nor do you want to broadcast your actions globally for all time.

hodlbod 11mo ago

For end users and moderators, I think nip 56 is perfect, since reporting should be declarative rather than imperative. For administrators who actually want to unambiguously delete stuff, NIP 86 is probably the right way.

Niel Liesmons 11mo ago

> Just add a new event kind 3xxxx which means "I am a relay" with tags declaring relay address under different transport (wss, onion, etc).

Is there a serious case against this? Because that's exactly what the noob in me would do. Leaving the option open to also specify the media servers that Community uses.

> Relays largely already have everything they need to do moderation

Yup, they might miss just a few things to make Communities work, but that doesn't mean we need copy (and add unnecessary complexity) to the whole relay spec in something like NIP-29, just to add these.

hodlbod 11mo ago

It seems reasonable enough to me, but we'd have to propose it and see what others think. And yeah, communities do need other things, at least granular permissions for sub-groups, but the starting point IMO should be relays as groups

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 11mo ago

Number one problem is binding them to DNS more important to decouple that than talk about adding features.