Update NIP-23 to define encrypted long form content

[space-shell]

Overview

This change updates an existing protocol definition to allow for encrypted long form content.

Considering that we currently have applications utilizing the event kind 30024 for long form content and to avoid clients accidentally being presented with encrypted strings it may be preferable to replace the encrypted tag for another event kind all together e.g. event 30025 to represent encrypted long form content.

Potential use cases

• Article paywalls: utilizing NIP-46 authors can selectively allow decryption acces to private / premium content
• Private journaling: utilizing relays to distribute and access private journal entries to be viewed and edited via multiple clients.
• DVM Publication: users may request that DVM's ( NIP-90 ) output their content to Nostr as a private article.

Relates to

#1183
#1139
#583

[vitorpamplona]

1. I would use a new event kind that is just a copy of 30024 with encryption. That avoids current long-form implementations from breaking (showing encrypted text raw).
2. NIP-44 encrypts to the pubkey of each receiver. Only that person can decrypt it. Is the use case here to be one-on-one events? Meaning, if I have 2000 followers, I have to create 2000 similar events, each one encrypted to a given receiver?

[space-shell]

Thanks @vitorpamplona for the quick feedback. I think that the new kind is the better option, I'll make the change to this proposal.

My thinking is that via NIP-46, one could utilize an nsecBunker to manage permissions to articles using a remote key 'owned' by the author.

For private journaling, individuals could encrypt and publish articles to themselves.

[fiatjaf]

Article paywalls: utilizing NIP-46 authors can selectively allow decryption acces to private / premium content

I don't think encryption is a necessary or sufficient condition for sharing premium content.

Private journaling: utilizing relays to distribute and access private journal entries to be viewed and edited via multiple clients.

This is a larger problem that @vitorpamplona for example is trying to solve on another NIP. Just encryption doesn't solve it.

I personally generally think these things are better done on proprietary platforms or separate protocols outside of Nostr.

DVM Publication: users may request that DVM's ( NIP-90 ) output their content to Nostr as a private article.

This should be specified as a DVM response format, not on NIP-23.