peer-exchange: investigate p2p-circuit address discovery & connection

[danisharora099]

Problem

This issue is meant to track investigation/work around being able to find and connect to p2p-circuit addresses through peer-exchange in js-waku

Notes

• https://github.com/waku-org/js-waku/issues/1454
• address https://github.com/waku-org/js-waku-examples/issues/265 after this issue has been resolved

[danisharora099]

some findings:

• no peer discovered via js-waku has a component like p2p/QmAlice/p2p/QmBob as was seen in the browser findings (was checked right before sending to libp2p.dial()
• was also found out that peer IDs that have such a component as seen in browser's network tab, are actually the peers that js-waku is unable to dial. errors like:
  • no valid addresses
  • payload identity mismatch
    • [ ] look into libp2p to check if it does that automatically to undialable peers, in an attempt to dial them?
• @richard-ramos suggests that we add /p2p-circuit/ to our multiaddrs when we've decoded the ENR as it is something that is avoided on service nodes' sides or from the ENR and is client's responsibility due to size ENR's constraints
  • while we need to understand how a p2p/QmBob is suffixed, it should then make the multiaddrs "proper" in the interim at least: p2p/QmAlice/p2p-circuit/p2p/QmBob which has chances of getting dialed
  • https://github.com/waku-org/js-waku/issues/1527

---

• while i can't run same example with the updated js-waku without a new release (tried to build locally and configuring the right imports internally and externally with builds failing as we need to update it in @waku/ui as well which makes it quite complicated), running a spec test within js-waku still shows the same no valid addresses or payload identity mismatch errors
  • however, don't think we can conclude that "p2p circuits didn't work"
  • [ ] will investigate running a conscious go-waku setup with an unreachable node and attempt connection using circuit relay

[danisharora099]

update: js-libp2p supports circuit-relay: https://github.com/libp2p/js-libp2p/blob/a6be8f0f4bbd81826c2ca5d48ea6175b1fdf3ab9/doc/migrations/v0.42-v0.43.md?plain=1#L29

[danisharora099]

blocked with https://github.com/libp2p/js-libp2p/issues/2024

[danisharora099]

currently blocked until a sync with go-waku @richard-ramos (who is currently travelling) can be scheduled as there is an interop bug

[danisharora099]

the work enabling & testing circuit relay connections is being tracked in #1619

---

1. for go-waku, a few changes had to be made to allow for seamless testing, and some improvements are still pending. changes made: https://github.com/waku-org/nwaku/issues/2130#issuecomment-1766308592 improvements required (tracking here: https://github.com/waku-org/go-waku/issues/815)

• allowing to use a local node for circuit relay server
  • looks like there is a limitation from go-libp2p that does not allow using a node on the same as a circuit relay server (TBC)
• discard requirement on a secure websocket connection and allow unsecure socket connections
• allow to read a log line to know when the ENR is populated with a p2p-circuit addrs (this currently takes ~20/25 seconds and we're manually awaiting this delay)

2. for nwaku, we need to coordinate the same functionality & flags between both implementations (tracking here https://github.com/waku-org/nwaku/issues/2130)

[fryorcraken]

Removed from epic as agreed not needed at this point in time.