Open fryorcraken opened 1 year ago
Regarding circuit relay.
Alice --> Bob (Relay) <-- Carole (behind NAT)
Talking about Carole's ENR.
If Carole cannot be reached from the outside, then she needs to connect to a Relay node (Bob) and provide circuit relay information in her ENR.
Carole's ip4
, tcp4
, wss connection details are useless. Indeed, these ports/ip are not reachable from the outside.
Hence, she could encode Bob's ip4
, tcp4
and even wss connections details in her ENR. The only missing piece of info is Bob's peer id.
We could then add a new cr_secp256k1
field to the ENR to store Bob (relay) peer id.
When decoding an ENR, if cr_secp256k
field is present, then we know to reconstruct Carole's multiaddr, we need to build a circuit relay multiaddr and that tcp4
etc fields are used for Bob's part of the multiaddr.
The only remaining question is: How does Carole determine that she is not reachable from the Internet and that she:
Regarding circuit relay.
Indeed. Circuit relay is already used quite extensively by go-waku and nwaku supports the relay process as server. I think following the process as described here would allow Carol to encode information in her ENR as you described.
In short:
How does Carole determine that she is not reachable from the Internet
She uses AutoNAT, the first step of the circuit relay process (already supported as server by nwaku): https://docs.libp2p.io/concepts/nat/autonat/
- Needs to connect to a (circuit) relay peer
- Needs to encode the (circuit) relay peer's (Bob's) details in her ENR instead of her (local) connection details.
Carole knows that she has successfully reserved a relay slot in the circuit-relay server and hence knows the address.
That said, if Carole is behind a restrictive NAT, how does she advertise her ENR as her discv5 UDP port is also likely to be unreachable? For this reason I think a multiaddrs
discovery scheme, such as libp2p rendezvous, needs to be introduced regardless, as this will allow Carole to actively register her circuit-relay address at a rendezvous point.
Problem
31/WAKU2-ENR conforms to the EIP-778 size limit of 300 bytes.
multiaddrs
field was added to enable storage of information for secure websocket connections: FQDN + WSS PORT.Circuit relay information also needs to be stored, currently using
multiaddrs
field: https://github.com/waku-org/nwaku/issues/1491rs
relay sharding field is being added: https://github.com/vacp2p/research/issues/178WSS + Circuit Relay information already takes the ENR over 300 bytes (especially when trying to store 2 circuit relay multiaddr)
WSS + relay shard information takes the ENR over 300 bytes in some instances
Solutions
rs
attribute.fqdn
andwss_port
fields to the ENR and prefer it overmultiaddrs
to suport secure websocket information. Also do not encodewss_port
if value is443
. https://github.com/vacp2p/rfc/issues/578identify
protocol).Evaluation of solutions
rs
field even if only using store/filter/light pushwaku2
info is covered as part ofidentify
so it could be removed from ENR?Acceptance criteria
Notes
a. For efficiency reason, the
rs
information must be present in the ENR and cannot be transmitted via req/resp protocol (4) b. Connection information (ws/tcp/ip/fqdn details) must be present in the ENR otherwise the req/resp protocol cannot happen c.waku2
information is already covered as part ofidentify
so could be removed? d. ~A node that provide circuit relay info would not also provide ws info: if it needs to provide circuit relay info to be connected to, then it means it does not expose a direct port to the internet and hence ws connection is not possible @richard-ramos to confirm this point.~