Deploying a separate signaling server to facilitate web connections is probably an anti-pattern and a centralising force.
We should be able to leverage libp2p to facilitate ICE connections.
This is a solved problem so we should investigate how it's achieved elsewhere.
Proposal 1
TODO: investigate and understand how this problem is solved and implement this.
Implement libp2p webtransport on validator nodes and/or indexers to allow them to facilitate connections.
Use the following high-level scenario as a guideline:
Given a Tari network NETWORK_1
Given a tari-enabled wallet (walletd, metamask snap etc) WALLET_1
Given a tari-enabled website (tari.js) WEB_1
Given WEB_1 establishes an ICE connection to a random member of NETWORK_1
When WEB_1 wants to connect to WALLET_1, it provides ICE details (this could be an URL or some other approach)
Then WALLET_1 uses the ICE details to establish a connection to WEB_1
And WEB_1 can interact with WALLET_1
ICE details may include:
The tari node (network address may be simplest) that must be used to facilitate the connection
Problem
Deploying a separate signaling server to facilitate web connections is probably an anti-pattern and a centralising force. We should be able to leverage libp2p to facilitate ICE connections.
This is a solved problem so we should investigate how it's achieved elsewhere.
Proposal 1
TODO: investigate and understand how this problem is solved and implement this.
Implement libp2p webtransport on validator nodes and/or indexers to allow them to facilitate connections.
Use the following high-level scenario as a guideline:
ICE details may include:
Related links: