nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-23 08:55:52 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

Clarify

Browse Source
This commit is contained in:
threeseries 2023-05-04 22:49:31 -05:00
parent b0dbdde53b
commit 4bc43f41b7
1 changed files with 7 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
103.md
View File

@ -11,8 +11,12 @@ If the inner event is kind 16 it must be possible to eventually reach a regular
# Motivation # 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. 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 forwarding 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. # Usage
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. On receiving a kind 16 event a forwarding service should decrypt the content and then determine the kind and recipient of the inner event. If this event is kind 4 it should be re-encrypted and then forwarded along to its destination. If the inner event is kind 16, then its content must itself be decrypted (hence the content of the outer and inner events need to be encrypted with the public key of the outer event recipient), and the inner event recreated using the keys of the forwarding party. Recreating the event in this way serves to remove any association between the message and the original sender before being forwarded on to the next recipient. And by allowing for forwarding rounds to be chained together in this way we enable use cases that would add further plausible deniability as to the source of a message.
One such use case would be if ordinary clients were allowed to opt into being forwarders themselves. Then one could send a kind 16 to any one of these users, and when they forward the message along it's impossible to know if they are forwarding a message or are the source of a message themselves. This could create a large mesh network within which it would be nearly impossible to interpret who is messaging whom.
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.