Add NIP-4A Event Onion Routing

[nyonson]

I believe onion routing is a key missing piece to client privacy and would be extremely valuable in high value, low bandwidth use cases like bitcoin transaction collaboration. A lot of work has been done recently with things like NIP-17 to hide application metadata in events, but I do not believe a nostr native way to protect network metadata has been addressed (happy to be proven wrong there though). Event onion routing is not a new concept and has been proposed a few times over the years:

• Republish Events by Peers #430 for NIP-705 Republish Events by Peers and the original issue Publish by peers #411.
• NIP-103: Onion Routed Direct Messages #499 for NIP-103 Onion Routed Direct Messages.
• Comments in NIP-17 (old 24) Sealed Gift-Wrapped Messages for Private DMs and Small Group Chats #686 (comment) for NIP-17 Direct Messages.
• A long form note proposal for NIP-37 Event Publication Onion-routing (although it looks like NIP-37 has been taken, so NIP-37-ish?).

I am restarting onion routing discussion here with a bare bones proposal which attempts to grab the best parts from the ones above, plus use the most modern practices (e.g. NIP-44).

Some open questions initially left off, but should be addressed:

• @pablof7z's NIP-37 proposal defined a regular kind 2444 and ephemeral kind 20444, I left off the regular one for simplicity but see the value. Added a regular event kind since it allows a sender to disrupt time-based deanonymization.
• How a routing service announces itself as available should be defined here, but is this a chance to use NIP-89? I am not sure if appropriate for this use case since ideally the service could broadcast information like what ecash protocols it understands and what it charges. Not clear to me if NIP-89 supports metadata like that. Maybe a new kind is required? While I think NIP-89 could maybe still be used as a way for peers to recommend a router, it feels like an abuse to finagle onion routing specifics into NIP-89 events. Added a replaceable announcement event.
• I like the simplicity of cashu's V4 serialization and it is what I had in mind for the ecash tag. I think how ever a routing service announces itself should also have stuff like what ecash protocols it understands. But is this tag definition too open ended? I found a useful comment in the NIP-60 pull request explaining the lack of V4 serialization usage. But I just dropped all the optional ecash stuff from this patch. It feels like the perfect pairing, but at this point can we assume cashu usage through out a route? I am a little concerned with interop issues between senders and routers in this case, whereas NIP-60 is explicitly a cashu wallet.

[pablof7z]

the non-ephemeral kind is fundamental as it improves time-based deanonymization.

As a byproduct, it creates a non-dvm approach for publication scheduling.

[vitorpamplona]

Yes, let's go!

[nyonson]

I backed down for shoehorning NIP-89 events in here and added a router announcement event like your NIP-37 proposal @pablof7z. I made the event replaceable though instead of ephemeral. I believe the downside to this swap is if a router goes offline and a sender still tries to send, which does suck because hard to get feedback to the sender. But ephemeral to me seems a little too drastic, could make routers way more chatty than necessary? Maybe I am missing something though.

[mikedilger]

This is another reason why relays should be identified by pubkeys instead of URLs. I know in the past I've said that is major breaking change for nostr, but unless we are starting over, nostr is just gonna have to break. This means relay hints being optionally pubkeys, relay lists using pubkeys, relays publishing their URLs (since we know their pubkey not their url), and probably quite a bit more. (EDIT: nevents redefined, nprofile redefined, NIP-05 relays redefined...)

This proposal depends on all of that prior work to be done right IMHO.

[pablof7z]

This is another reason why relays should be identified by pubkeys instead of URLs. I know in the past I've said that is major breaking change for nostr, but unless we are starting over, nostr is just gonna have to break. This means relay hints being optionally pubkeys, relay lists using pubkeys, relays publishing their URLs (since we know their pubkey not their url), and probably quite a bit more. (EDIT: nevents redefined, nprofile redefined, NIP-05 relays redefined...)

This proposal depends on all of that prior work to be done right IMHO.

This is when we started touching on these things at Sovereign Engineering, arjen wrote that NIP PR to do pubkey<>relay mapping, I think the PR got some scope creep and devolved into the endless "naming systems" issue.

So yeah, I agree about relays should be identified as pubkeys, although I don't think this is as much of a breaking change as you imply, e.g. nevents can still have relay hints as URLs and can add relay pubkeys as well, nostr software needs to be coded defensibly anyway, so current implementations should already be filtering out by URLs so they'd filter out what they don't understand.

[nyonson]

This is another reason why relays should be identified by pubkeys instead of URLs. I know in the past I've said that is major breaking change for nostr, but unless we are starting over, nostr is just gonna have to break. This means relay hints being optionally pubkeys, relay lists using pubkeys, relays publishing their URLs (since we know their pubkey not their url), and probably quite a bit more. (EDIT: nevents redefined, nprofile redefined, NIP-05 relays redefined...)

This proposal depends on all of that prior work to be done right IMHO.

Sorry I am not following, pubkeys for relays sounds generally helpful, but why does this proposal depend on it?

[pablof7z]

I backed down for shoehorning NIP-89 events in here and added a router announcement event like your NIP-37 proposal @pablof7z. I made the event replaceable though instead of ephemeral. I believe the downside to this swap is if a router goes offline and a sender still tries to send, which does suck because hard to get feedback to the sender. But ephemeral to me seems a little too drastic, could make routers way more chatty than necessary? Maybe I am missing something though.

not really, ephemeral events live for 5 minutes, which is a perfectly acceptable heartbeat for a router imo

[mikedilger]

Sorry I am not following, pubkeys for relays sounds generally helpful, but why does this proposal depend on it?

You could source-route packets through multiple relays by encrypting Relay1(Relay2(Relay3(FinalUser(Message)))). Each relay unwraps their onion layer with their keypair, and sends the inner message to wherever the inner message specifies. It is not your proposal exactly, but it is the same general principle.

[nyonson]

Sorry I am not following, pubkeys for relays sounds generally helpful, but why does this proposal depend on it?

You could source-route packets through multiple relays by encrypting Relay1(Relay2(Relay3(FinalUser(Message)))). Each relay unwraps their onion layer with their keypair, and sends the inner message to wherever the inner message specifies. It is not your proposal exactly, but it is the same general principle.

Ah, right. Closer to existing onion route-like things (e.g. Tor, Lightning Network). Doesn't this introduce some Relay-to-Relay messaging though? I think there are simplicity benefits even for this proposal to adhere to the super simple nostr topology of "relays only to clients".