Additionally, users actively using VPNs and proxies is also an option for addressing IP leakage.
nostr:note1wrsgwwzklju8fnywu3dlsh6cyvnjhcpf2k44sry5gfyasvg3mgvqeqsgh4
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
Discussion
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.
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).