Mazin on Nostr: How can NIP-42 help control the spread of DM metadata, you ask? The problem today is ...
How can NIP-42 help control the spread of DM metadata, you ask?
The problem today is that REQs (requests for events that clients make to relays) are not signed. As such, we do not know who a user is when they request kind 4 DM events for a specific pubkey. If you ask a relay for kind 4 events that don’t belong to you, the relay hands them over because it doesn’t know the difference. Though you can’t decrypt the content, you can easily see who the messages were between and what time they happened.
Enter NIP-42, client authentication. A relay can now answer a kind 4 REQ by asking the user to prove who they are. This proof is done by asking the client to sign a specifically formatted ephemeral (not stored) event (kind 22242) with the users privatekey. Once the client provides the signed event to the relay, the relay can validate that the user requesting the DMs matches the pubkey in their REQ.
This allows relays to reject kind 4 REQs for unauthorized users.
Disclaimer: this still does not prevent relay operators from viewing the events. I believe others are working on a more complex DM NIP to conceal the metadata completely but do not know the details.
The problem today is that REQs (requests for events that clients make to relays) are not signed. As such, we do not know who a user is when they request kind 4 DM events for a specific pubkey. If you ask a relay for kind 4 events that don’t belong to you, the relay hands them over because it doesn’t know the difference. Though you can’t decrypt the content, you can easily see who the messages were between and what time they happened.
Enter NIP-42, client authentication. A relay can now answer a kind 4 REQ by asking the user to prove who they are. This proof is done by asking the client to sign a specifically formatted ephemeral (not stored) event (kind 22242) with the users privatekey. Once the client provides the signed event to the relay, the relay can validate that the user requesting the DMs matches the pubkey in their REQ.
This allows relays to reject kind 4 REQs for unauthorized users.
Disclaimer: this still does not prevent relay operators from viewing the events. I believe others are working on a more complex DM NIP to conceal the metadata completely but do not know the details.