NIPXX: encrypted events

[earonesty]

"private" versions of a number of nip's are needed, not just direct messages

• private product listing
• private nip26 delegation (we do this now for another protocol) https://github.com/nostr-protocol/nips/blob/master/26.md
• private... nipXX messages of any kind

likewise

• group-private (private channel) versions of the same!

we may want a trivial way to say:

• "this encrypted message is equivalent to nip26 delegation"

Imagine we post an event

content: encrypt(
  {content: encode({id, kind, content, tags}), version: 2}
),
tags: [["version", 2],
          ["p", <recipient-public-key-1>], ...
]

of the analogous message.

without having to specify a NIP specification for a private and group-private version every existing message type

now, when a client sees this NIPXX event, they can simple decode it and, recursively, interpret it as another event of the encrypted kind/content and tags...

this opens up encryption across every use case

most useful (to me) is encrypted delegation, which allows two people to create a new blinded channel, and also encrypted product listings

we can do this NIP up nicer than NIP4, with an ephemeral public key and hashed shared secret, and make it more flexible and useful than NIP4 as well by allowing it to be generic. you can make an encrypted version of any well-known event now, and clients can treat them as if they are, otherwise, regular events.

(we can also restrict it so that it explicitly excludes itself from recursion... one level only!)

[fiatjaf]

This is too broad. It creates a ton of flexibility, confusion, incompatibility across all Nostr apps in a single stroke.

[earonesty]

fair. i'll focus on encrypted delegation, which we're using now, and just worry about the rest later.

[earonesty]

this is exactly NIP59 #468 by the way

[decentropy]

This is closed, but I agree with the need for general encryption.... especially for replaceable events.
There are lots of use cases for 'personal data', which you want to encrypt.

My approach would be:

• If 'encrypted' tag exists, then event.content is expected to be encrypted
• If 'encrypted' tag exists with additional values, then those values should be interpreted as tag names which are encrypted.

For example, if tag exists ['encrypted', 'title'], then not only is event.content encrypted... but every value of the 'title' tag as well.

For now, NIP-04 encryption could be applied... until/unless that changes.

[staab]

@decentropy #715 will land soon, fixing NIP 04, just FYI. Also #716 will cover many use cases for encryption. For more general-purpose encrypted payloads (e.g. encrypted lists), your approach could be helpful, but only really if the tag is a single character so you can avoid pulling the events in the first place, otherwise you can try to parse the event and if it fails discard it.