NIP-103: Encrypted direct message envelopes

103.md

@@ -0,0 +1,18 @@
+NIP-103
+=======
+
+Direct Message Envelopes
+------------------------
+
+`draft` `optional` `author:threeseries`
+
+This NIP defines a kind 16 event which is a kind 4 event (see [NIP-04](04.md) where the decrypted content is itself a kind 4 or kind 16 event.
+If the inner event is kind 16 it must be possible to eventually reach a regular kind 4 after enough rounds of decryption.
+
+# Motivation
+
+It's well-known that direct message metadata is public on nostr since everyone can see who is messaging whom and when. One solution to this problem is for the entire event including its metadata to be encrypted and only revealed to an intermediate party responsible for relaying messages to their intended recipients.
+
+On receiving a kind 16 event such a service would decrypt the content and then determine the kind and recipient of the inner event. If the event is kind 4 it should be re-encrypted and then forwarded along to its destination. If the event is kind 16 it should be forwarded without additional encryption. This latter behavior enables forwarding rounds to be chained together before reaching the final recipient, with a layer of nesting being removed at each step.
+
+Ordinary clients might also opt into being "forwarders" themselves, creating a large mesh network to anonymize everyone's direct messages. To add further anonymity, forwarding could also be configured to inject timing delays (for instance, using the difference in `created_at` timestamps between the outer and inner events), or to only forward messages once enough have been collected into a queue, thus creating a type of "message join" on nostr.