I’d like to build a web app for me and a few friends to use that allows us to play D&D together. There is an existing solution out there but wanted to do this as an exercise.
I’ve read through all the documentation over the last few days and I’m just a little confused when configuring my node’s peer discovery. Out of the options available I’m unsure of which to use, and am aware the docs recommend to use multiple.
mdns: is out cause there’s no registered domain in this scenario.
webrtc-star: could be used and will be the one for ease of use if neither of the following would work
bootstrap: Because all my friends and I will be on zoom already we can report our peer ID’s to each other. Could we each manually enter eachother’s peer id’s through the webapp to be bootstrapped or am I missing some required info for this to work like the public ip?
kad-dht: Same method as the bootstrap but because I’m missing the public IP address this would actually work? Or do I misunderstand the use of DHT for peer discovery?
I would know the transport protocol, the expected port and the peer ID in the multi-address just not the public IP address.
webrtc-star is likely going to be the best fit for your use case. The reason for this is that you will need a central signaling server for everyone to connect to initially. The webrtc-star server will also serve as peer discovery for your group, since anyone who connects to it will be notified of one another. Webrtc will then attempt to create direct connections to one another.
Bootstrap won’t work simply because your friends are likely not going to be directly dialable due to local home network NATs. Webrtc-star should help to overcome this.
kad-dht is a bit overkill for this, since you’re really only connecting to a specific, small set of users.
or when the the docs refer to the DHT singularly are they referring to a single DHT shared by the peers using the app?
My confusion stems from the DHT being referred to as “the DHT” when it’s referenced.
Would using kad-dht be overkill because of the complexity of the second option just being to much for my use case, or too slow to find peers in the first option due to the global nature?
My aversion to using webrtc-star is simply because of the recommendation to not use it in production. Although this project will likely never see “production” I’d still like to design with best practices in mind as if I were going to ship it in the future.
Additionally, I’m a little unsure of your statement:
If I used the public webrtc server would that mean anyone using it as their signaling server for their own project would as well connect to my peer group? If so could this be solved in either of the following ways?
Forming a private network after using the webrtc server to connect to each other? I found the docs referencing this functionality the other day but can’t seem to find it now.
The DM of the group would first use the webrtc server to find their own complete multiaddress. The app would then display it as a shareable link that could be sent to the peer group using another messaging app, turning the DM’s node into the new “signaling server” for the peer group? Or even just bootstrap the address because I would have their complete multiaddress at that point?
Been working at this some more today and have opted to forgo using kad-dht as my discovery protocol for simplicity and learning’s sake. Been trying to get the app working using a modified version of your example to get up and running: https://github.com/libp2p/js-libp2p/tree/master/examples/libp2p-in-the-browser
I’ve successfully got it working in a vue instance I can build and just pass it around for anyone with a browser to use. But it is still dependant on having a local server-star instance running somewhere on my local network. I’ve been trying to connect to the public webrtc-star signaling server but have run into an error when I switch my multiaddress from
/ip4/0.0.0.0/tcp/9090/wss/p2p-webrtc-star
(this was the address from the github example for js-libp2p in the browser)
to this multiaddress
/dns4/star-signal.cloud.ipfs.team/wss/p2p-webrtc-star/p2p/QmRhrGGsJBdTR4xfKGMxMxAvuVuWz64b3NqNkG7Qj8fP9i
(my peer id is auto generated each time the node starts up)
When I change it I thought I was following the format outlined in the js-libp2p-webrtc-star github, “/dns4/star-signal.cloud.ipfs.team/wss/p2p-webrtc-star/p2p/”, but the error message comes back as “invalid multiaddr:”.
I can’t seem to spot the difference or what I’m doing wrong here because the only change I am making is this multiaddress which to the best of my understanding should work.
I can’t seem to spot the difference or what I’m doing wrong here because the only change I am making is this multiaddress which to the best of my understanding should work.
It looks like the readme needs updated, you should be able to just specify /dns4/star-signal.cloud.ipfs.team/wss/p2p-webrtc-star as the address. However, that server isn’t running properly and needs replaced. We’re in the process of doing so, but don’t have an ETA yet for that. I will post on the forums once that’s deployed.
If I used the public webrtc server would that mean anyone using it as their signaling server for their own project would as well connect to my peer group? If so could this be solved in either of the following ways?
If you connect to the public webrtc server, it will exchange knowledge of you to other peers. The reason for this is to get around limitations of peer discovery in the browser. You won’t be able to use a private network while connected to the public network, because the two don’t work together.
Ultimately it sounds like what you need is the ability for players to connect directly to a DM, and then be able to exchange info. The pubsub discovery module could be helpful for this, as your players would be able to discover one another after connecting to you. As long as they are each connected to a webrtc-star or relay server, they should be dialable. Additionally, depending on the needs of your app, pubsub might just be a helpful module in general for exchanging game data. I’ll post in the forums when those are released (should be this or early next week) and again once we have something deployed.
Oh neat! I think this marks the first instance where I’ve hit the limits of the tech I’m using. Personal milestone!
I’ve learned a lot over the last few days and realise how some of my earlier questions showed some ignorance of the concepts.
“I am planning on adding support to namespace the discovery topic, so that you could isolate who you are discovering (application specific discovery on a public network).” THIS! Please! That’s perfect haha
I’ll keep an open and test that out as soon as it’s available.
Would this act as a bool value in the core lib-p2p node’s configuration? As in it could be add to the peerDiscovery array of the LibP2P node instance? Offering your node as an agnostic seeder for peers looking for other app specific peers?
could you then create a private network within that subscribed game? ie.
the relay node(webrtc or other) connects peers using the pubsub peerdiscovery
peers subd to the same app(my d&d app could live on this network next to other apps representing different subs) get connected and can now communicate.
to isolate our individual game from within the broader app we subd to, we would then have to create a private network or could I nest another pubsub within that?
If you have the time and see this could help out with something else related to this?
I’m trying to figure out how to access the API of my node from the rest of my Vue app. In your example of using it in the browser you use window.libp2p to export it to the browsers console. How would I go about exporting it?
Trying to use exports.libp2p = libp2p from inside the async function wrapping the new libp2p instance. Instead of the document.addEventListener() you have in your example I replaced that wrapper with a plain async function that is triggered when a part of my app loads.
Once that part loads, the async function is called, creating the node instance of the same configuration as your example without the ui tags. But now that libp2p is instantiated how do I reference the api of that node instance from outside of that function.
Actually no need! I just figured it out. Will expand on this more and likely share github with you at a later date. Maybe make a video out of this. “How to Mount LibP2P to your Vue App”
Would this act as a bool value in the core lib-p2p node’s configuration? As in it could be add to the peerDiscovery array of the LibP2P node instance? Offering your node as an agnostic seeder for peers looking for other app specific peers?
Yes, you’ll be able to just pass it into peerDiscovery with additional configuration as needed. The relay server will do this, so we’ll be able to point to that configuration as a sample.
could you then create a private network within that subscribed game? ie.
It wont be private at the network level, but you could configure the application to support this. If you join a namespaced pubsub discovery network for your application, you could discover everyone actively online who is also running the app. The next thing is connecting to the peers that are in the same campaign(s) as you. This could potentially be done via pubsub, by subscribing to a campaigns topic, however every peer in pubsub would learn about the campaign through querying (not necessarily a bad thing). While peers could know about your campaign, you could add application logic to include a secret key to “join”. So when a peer connects to you and wants to join your campaign, they would need to send you the secret key for the campaign in order to get the data. When you start a campaign with your friends you could send them the campaign ID and secret key. They could find you on the public network (libp2p supported) and then you’d get the privacy of the shared secret (application logic) to actually access the data.