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

• peer-exchange browser feedback #1454
• address web-chat: only showcase wss peers in discovered examples.waku.org#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
  • peer-exchange: investigate p2p-circuit address discovery & connection #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 libp2p/js-libp2p#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: feat: enable circuit-relay client nwaku#2130 (comment)
   improvements required (tracking here: chore: improvements for circuit relay interop go-waku#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 feat: enable circuit-relay client nwaku#2130)

[fryorcraken]

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