- Limiting access to kind 4 events (control DM metadata leaks)
- Metered resource usage
What other ideas can you think of that NIP-42 enable? They seem endless. nostr:note1htlnv7fnuxc8dzty5p7zhhgkdz5gg8zh04ez8lra50f7lu8x54sss233cp
Discussion
I’m super excited for #Nostr enabled comments on personal websites. The problem now is inability to moderate those comments. Having control over a private relay would mean that content creators will be able to hear feedback without risking to have completely inappropriate censorship resistant comments. Or am I getting something wrong?
If I’m understanding correctly, you’d want to be able to delete events after they were posted, right? You could accomplish this today with a public relay that you control (and could delete event IDs from).
I think the ask here is moderation in advance. And I do think a private relay could help here. Free to write, but your admin user has to auth to read all events, and then can approve posts for public consumption? Does that sound right?
That option too, yes!
I’m not technical enough, but I got a feeling, that private relays would give better flexibility for the operator.
To be honest I would be happy with some 3rd party service providing such functionality.
A convenient alternative to disqus if you will.
Personalised relay feed for pubkey, based on a web portal or similar - like filter events with ‘Facebook’ before sending to me. Or Nthdegree events only.
Access premium features that are too costly to provide to everyone for free - search, POW generation, extra metadata on events, perhaps media caching, etc.
Unlocking higher rate limiting. For example re-broadcasting a backup.
Perhaps access to your recently deleted events.
I’ll keep thinking. It does have a privacy consideration which isn’t ideal - but can’t see how you could get past that.
Could you expand on controlling DM leaks (I do not speak code). I remember reading about the metadata leaks, how does this NIP address that?
I’ll preface by saying there is work on a new DM NIP I believe that tries to address the metadata to begin with. This is a better solution as it prevents the relay operator from snooping as well.
NIP-42 is an auth message from the relay to the client that can occur at anytime during the websocket connection. For DMs, it would work like this:
- You (via your client) make a REQ for kind 4 events (DMs) for your pubkey
- The relay sends back an AUTH challenge
- You sign the auth challenge and send it back to the relay who validates that you are the one requesting your own DMs.
If you signed the auth message with a different pubkey than you requested DMs for, the relay would reject your AUTH.
Paying for a read relay by zapping the administrator.
Controlling anything, the relay itself, a lightning node, your light switch.
Have throwaway keys on your phone, send event to your authorized relay and that one retransmits it signed by your main keys.
Get personal follow lists, or personal notes, shopping lists, todo lists.