feat: add direct relay-rtc example

[weboko]

A new example here is a showcase of how a client that has only WebRTC connection can communicate with a third client through an intermediary by using Waku Relay.

sequenceDiagram
    participant Alice
    participant Bob
    participant Eve
    participant Relay Node
    Alice->>Relay Node: Dial
    Bob->>Relay Node: Dial
    Eve->>Relay Node: Dial
    Alice->>Bob: Dial WebRTC
    Bob->>Alice: Add to mesh
    Alice->>Relay Node: Disconnect
    Alice->>Bob: Send message
    Bob->>Relay Node: Relay message
    Relay Node->>Eve: Relay message

Such an approach enables us to:

• rely less on the service nodes;
• decrease load within on the network;

[danisharora099]

I'm aware it's just a draft PR but came in to say it's probably best to use a framework for better readability moving forward
Manipulating HTML from a different JS file seems quite unreadable and janky

Excited for the progress on this one!

[weboko]

afaik this is the only way to know what type of stream is established in the mesh

[weboko]

This is the main problem with the current approach, due to how WebRTC transport is made it is able only to create outbound connection using WebRTCStream but inbound stays MplexStream which is wrong, and prevents the mesh from functioning over WebRTC transport.

Anyway we don't intend to limit ourselves to the libp2p's WebRTC transport and we need a different solution on which I am working: it is to establish WebRTC connection similarly to how we do it in noise-rtc by using contentTopics. Main thing that makes everything ugly here is to manually put streams and connections into gossipSub

[fryorcraken]

but inbound stays MplexStream which is wrong, and prevents the mesh from functioning over WebRTC transport.

Is that a libp2p bug?

[weboko]

I would say it is gossipSub's bug since it is failing to upgrade inbound connection from mplex to webrtc due to the condition explicitly skipping it and it happens to be that webrtc transport starts as mplex and then get's upgraded

I am looking at how to fix it in js-libp2p-gossipsub but I consider it to be a low-priority

[weboko]

For this one, I intentionally used chat template that we have since it is pretty straightforward but let's discuss how it can be improved so we can have event better WoW effect for the next example I am preparing

I'm aware it's just a draft PR but came in to say it's probably best to use a framework for better readability moving forward Manipulating HTML from a different JS file seems quite unreadable and janky

[fryorcraken]

ah so actually we may not need to run our own go-waku node, right?

[weboko]

yes, the main criteria is to have circuit-relay implemented on nodes and as of now it only works with go-waku nodes in prod fleet, the guide is to make sure folks know what to do in case it does not work due to low capacity or something

[fryorcraken]

but inbound stays MplexStream which is wrong, and prevents the mesh from functioning over WebRTC transport.

Is that a libp2p bug?

[danisharora099]

general comment: can we add details of this works in the description/README? there is mention of how to start and navigate the example, but we should add what is happening with this example theoretically:

• how it's different from using relay directly
• what use cases could benefit with using WebRTC + relay
• whatever else you feel is relevant for theoretical understanding

This would also help with the review process :D

[fryorcraken]

Note that you can use mermaidsyntax in GitHub comments/description for sequence diagram. Maybe would be better to have Alice, Bob, Carol in the diagram than tab#N.

[fryorcraken]

Hum, maybe relay-webrtc would be a better name?

[weboko]

Actually, I named it like this first but I hope to push for the second example with gossiping discovery and call it relay-webrtc

[danisharora099]

thanks for this effort!

did a first review

general comment: code feels hard to read and like a challenge to maintain. imo readability is of bigger importance considering this is an example for end users.
i would incline to refactor it for the following:

• break down initWakuContext into functions like setupMessageHandlers, configureWaku, etc
• functions like initUI mix both UI initialisation and event handling -- consider separating them
• we could also go ahead and group similar functionalities together:
  • functions related to message handling can be together, UI related can be together, etc
• modularising the code: breaking down components into modules like ui.js, waku.js, etc
• adding some comments/docs on functions that might be hard to understand for the user at first like setRelayMeshInfo, dropNetworkConnections, dialWebRTCpeer, onExit

cc @LordGhostX how do you feel?

[danisharora099]

if the input box is empty, we should prompt the user to enter a multiaddr instead of throwing

[danisharora099]

during this, let's also make sure to clear attached event listeners to avoid potential memory leaks

[danisharora099]

this seems to be a fairly long function (150 lines); it would help to break it down into multiple functions

also might help keep code more maintainable & readable to break off code/functions into multiple files

[danisharora099]

it will help to encapsulate this function into a separate file/UI class for better readability & maintainability

[fryorcraken]

this is an example for end users.

I disagree there @danisharora099 . This is a PoC to demonstrate possible usage of WebRTC for Waku Relay. Should we just have a different repo for PoCs?

[danisharora099]

I disagree there @danisharora099 . This is a PoC to demonstrate possible usage of WebRTC for Waku Relay. Should we just have a different repo for PoCs?

I incline towards aiming to have our POCs as readable as our examples as it doesn't take much from our side; and can serve similar purposes

[vpavlin]

Why not just move the PoCs to a different folder and then have them as poc.waku.org instead of examples.waku.org ?

Then they are all in the same repo, but it is clear(er) that they may not be fully fledged examples to use for your app

[weboko]

As discussed last week - the following improvement will be introduced in root template here #271

As for if we need to split PoC and exmapels I think it's not needed yet.
Right now all of examples are PoCs for me.
Later when we have exampels as sets of defined patterns that devs are interested in - would be good to split.

[fryorcraken]

Why not just move the PoCs to a different folder and then have them as poc.waku.org instead of examples.waku.org ?

Then they are all in the same repo, but it is clear(er) that they may not be fully fledged examples to use for your app

FYI, Comms Hubs was keen on the usage of lab.waku.org.

[weboko]

Decoupled this conv to separate issue #275