NIP-93: Secret Events

[shafemtol]

This NIP defines secret events.

A secret event is an event with encrypted contents and no distinguishable
metadata apart from its kind, created_at value and the length of its
contents. Its pubkey is a unique key not used on any other event.

This NIP is intended as one of the building blocks for a new secure direct messaging system.

The main concern of this NIP is to standardize how secret events appear publicly, making sure that they cannot be distinguished by anything other than their size and timestamp. It therefore does not at the moment cover things like key exchange/management, cipher selection, ciphertext structure etc. Some of these things might be worth including as recommendations, would like to know other people's thoughts on what to include here.

An obvious question might be how to use this in a messaging system if there's no "destination address". The main idea is to use the event's pubkey for addressing, with the sender somehow secretly and anonymously communicating the event's pubkey to the intended recipient. For this problem I plan to introduce the concept of rendezvous beacons in a separate NIP.

[mikedilger]

There is a conflict between the user wanting no metadata, and the relay wanting to know who to charge or whether to bother hosting the event. I think that conflict has to be resolved towards relays remaining in the dark or else this NIP fails to serve it's purpose of hiding the metadata. Perhaps pragmatically people will post these to their own relays to guarantee they persist, but of course that implies they are the author leaking that. If public relays are gracious enough to host these, there would be an incentive to game that by storing massive data under these events, and then relays would stop hosting these. I cannot see a way out of this pickle. This is one of the reasons I have been in favor of DMs being peer-to-peer outside of nostr, and people simply post their DM contact address (and protocol thereof) in their metadata. I would be pleasantly surprised to be shown to be wrong.

[Egge21M]

I am aligned that we need to find better ways to hide DM metadata from the network and relay operators, the approach outlined here , as @mikedilger mentioned, would render relays extremely defenceless against spam.

Now a possible solution would be for relays to charge a tiny fee for the reception and storage on a per event basis. That way relays can default to only accepting secret events that have been paid for. Just a spontaneous thought, that has not been thought through completely yet... might be a little too exclusive.

[shafemtol]

There is a conflict between the user wanting no metadata, and the relay wanting to know who to charge or whether to bother hosting the event. I think that conflict has to be resolved towards relays remaining in the dark or else this NIP fails to serve it's purpose of hiding the metadata.

It's an issue that's been on my mind as well. I think it's a solvable problem that should be tackled in a separate NIP. I think the most viable option is some sort of anonymous tokens based on blind signatures. I mentioned some ideas on this in another discussion.

In any case, the main purpose of this NIP is hiding the public metadata.

[staab]

Seems to me this has been superseded by NIP 17.