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.

Additionally, users actively using VPNs and proxies is also an option for addressing IP leakage. View quoted note →

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.

A built in nostr solution (ie a bunch of republishers) may lower the bar for more user usage. Also maybe better privacy if a republisher is popular? Versus just offloading trust to a proxy.

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?

If the Nostr protocol supports the re-publisher functionality, that would be ideal. Moreover, if the goal is to address the issue of relays knowing the sender's and recipient's IP addresses, relay X can also act as the re-publisher. This is feasible because the "ecash stamp" on the outer envelope can simultaneously prevent spam targeting the re-publisher. One particularly great aspect of this proposal is that it requires both the sender's and recipient's addresses to be one-time use. This is very similar to Keychat's metadata privacy mechanism, where Keychat users have separate sending addresses and receiving addresses that are constantly updated. Currently, Keychat effectively protects metadata privacy at the application layer, and we hope to further promote metadata privacy protection at the network layer in the future (mainly focusing on IP addresses).

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.

GitHub

nips/01.md at master · nostr-protocol/nips

Nostr Implementation Possibilities. Contribute to nostr-protocol/nips development by creating an account on GitHub.

Tried to capture a history of the proposals for it cause curious why it seems to have stalled:

2025.01 Vol.1 | YONSON

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