mirror of
https://github.com/nostr-protocol/nips.git
synced 2025-07-21 20:32:25 +02:00
Add NIP-93: Secret Events
This commit is contained in:
46
93.md
Normal file
46
93.md
Normal file
@ -0,0 +1,46 @@
|
|||||||
|
NIP-93
|
||||||
|
======
|
||||||
|
|
||||||
|
Secret Events
|
||||||
|
-------------
|
||||||
|
`draft` `optional` `author:shafemtol`
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
A stored secret event has kind `9993`, while an ephemeral secret event has kind
|
||||||
|
`29993`.
|
||||||
|
|
||||||
|
`content` MUST be the base64 encoded string of the ciphertext with no added
|
||||||
|
whitespace. The raw ciphertext MUST be indistinguishable from random binary data
|
||||||
|
to anyone except those who have the secret to decrypt it. The length of the raw
|
||||||
|
ciphertext MUST be on the form `5n * 2**k`, where `n` is in `(12,14,16,18,21)`
|
||||||
|
and `k` is a non-negative integer. Equivalently, the length of the `content`
|
||||||
|
string MUST be on the form `8n * 2**k`, with no base64 padding.
|
||||||
|
|
||||||
|
`tags` SHOULD be an empty list.
|
||||||
|
|
||||||
|
`created_at` SHOULD be generated independently of any timestamp within the
|
||||||
|
encrypted data.
|
||||||
|
|
||||||
|
A relay MAY explicitly indicate support for this NIP as per `NIP-11`. If it
|
||||||
|
does, it SHOULD check for and reject secret events that do not meet the
|
||||||
|
requirements given in this NIP. In particular, it SHOULD reject secret events
|
||||||
|
where `pubkey` is known to be already associated with another event, where
|
||||||
|
`content` is not a base64-encoded string with a valid length, or where `tags` is
|
||||||
|
not empty.
|
||||||
|
|
||||||
|
|
||||||
|
Rationale
|
||||||
|
---------
|
||||||
|
|
||||||
|
The purpose of secret events is to enable storage and delivery of secrets with
|
||||||
|
minimal public metadata. Applications include secure messaging and storage of
|
||||||
|
private notes and settings.
|
||||||
|
|
||||||
|
Restricting content length to a small set of allowed values limits the leakage
|
||||||
|
of information about message size. The parameters are chosen such that for sizes
|
||||||
|
down to 52 bytes, the maximum overhead is 16.7% and the average overhead is
|
||||||
|
7.5%. By making the length a multiple of 5 bytes, no characters in the base64
|
||||||
|
encoding are wasted on base64 padding.
|
Reference in New Issue
Block a user