Replying to Avatar Nick

nostr:npub1h0uj825jgcr9lzxyp37ehasuenq070707pj63je07n8mkcsg3u0qnsrwx8 any thoughts on this simple onion routing proposal for nostr as an extra privacy layer? Feel like it could be useful for low bandwidth, but extra sensitive messages. Or is something like this already baked in? https://github.com/nostr-protocol/nips/issues/411

This is a good solution: using two envelopes for one letter. The sender first mails it to the re-publisher, who opens the outer envelope and then sends out the inner envelope. The re-publisher can be established as a standalone service.

Reply to this note

Please Login to reply.

Discussion

If the re-publisher uses the same receiving address, it seems that two envelopes are not necessary. Instead, a single envelope can include two receiving addresses (a feature supported by Nostr). The first receiving address is the re-publisher's receiving address, and the second address is the true recipient's nearly one-time receiving address. The re-publisher receives the message from relay X and then forwards it to relay Y. The recipient retrieves the message from relay Y.

Not sure I follow on the two receiving addresses. Wouldn’t we want two envelopes so it’s hard for outsiders to trace the path of the message?

In the `p` tag, multiple recipient addresses can be included. A single envelope can list two addresses: one is the re-publisher's address, and the other is the recipient's one-time address (which already resolves the metadata issue at the application layer). This is the solution with the least amount of changes.

Using two envelopes (outer and inner) is also an option, but it involves slightly more changes compared to the first solution.

https://github.com/nostr-protocol/nips/blob/master/01.md

Tried to capture a history of the proposals for it cause curious why it seems to have stalled: https://blog.yonson.dev/log/2025-01-vol1/

Could see it having some tricky UI issues though for something like chat use cases.