Open olivier-nerot opened 4 years ago
One of the initial issues I can see here is the usage of websocket-star
, which we do not support anymore. Ideally, this should be changed into using webrtc-star
. You have more context on https://github.com/ipfs/js-ipfs/issues/2779
thanks. So, you mean to use js-libp2p-webrtc-star ? According to this page, I will first have a try with this swarm setup, and with my own signaling server afterwards :
/dns4/star-signal.cloud.ipfs.team/wss/p2p-webrtc-star
I imagine the p2p/<your-peer-id>
is added during the setup.
I will publish my tries here.
The code should also be modified, even if it is explained on websocket-star page
thanks. So, you mean to use js-libp2p-webrtc-star
Yes!
According to this page, I will first have a try with this swarm setup, and with my own signaling server afterwards : /dns4/star-signal.cloud.ipfs.team/wss/p2p-webrtc-star
You will need to use a local star server for now. I can also recommend you check this out: https://suda.pl/free-webrtc-star-heroku/
The good news are that we are in the process of having some infrastructure that people can use for experimenting, like we had with the websocket-star
. Watch the issue I mentioned and you will be notified once that happens.
I imagine the p2p/
is added during the setup.
Correct! You can also look into this example, which uses what we are talking about for the connectivity part of things.
The code should also be modified, even if it is explained on websocket-star page
yeah, sorry about that. We have not been maintaining all the examples, specially in the ipfs-shipyard org. If you can make this work, it would be great if you could PR this and let me know
trying to install/run js-libp2p-webrtc-star, as explained on the project page.
There is an error during the npm install libp2p-webrtc-star
:
error /usr/bin/git ls-remote -h -t ssh://git@github.com/ipfs/webrtcsupport.git
as webrtcsupport is now inactive : https://github.com/ipfs-inactive/webrtcsupport
there is even an issue about this.
no luck... :)
I am looking into that!
The repo somehow moved to ipfs-inactive
and broke the installs. It is a devDependency of both libp2p and IPFS, so I believe that this move to the ipfs-inactive
org just happened
This will fix that issue: https://github.com/libp2p/js-libp2p-webrtc-star/pull/229 I will release it soon, after approval
It is released 🚢
and it works ! Thanks. I will PR this demo as soon as I make it run. Btw, my purpose is to have peers (electron app) discovering themselves in a private local network, and one of them can become a webrtc-star relay with a port opened to the outside. The app goal is to co-edit ipfs files with yjs. I plan to use mdns for local discovery (or webrtc-star discovery now), with a pubsub room for each shared file to broadcast yjs messages. But I'm wondering if I am not reinventing the wheel, or if it is the better architecture. Your advice is welcome. (it may be not the better place here to post this... let's say this is linked to pubsub and webrtc-star discovery, and could be a draft of this demo code)
cool, I did not know about yjs
👍
If you are going electron, I think you should go with mdns
as discovery and tcp
as transport. It will be more efficient than using webrtc for everything
In pubsub context, we also have this discovery libp2p/js-libp2p-pubsub-peer-discovery, but we still need to finish jacobheun/js-libp2p-relay-server#1 to make that work. This and webrct would work in the browser, but since you are on an Electron environment, I would recomment mdns
.
I think that a pubsub topic to real time broadcast of yjs messages makes sense. With that, if you need to support more stuff, like persistence that pubsub implementations do not have, you can also create a libp2p protocol (you can see this chat as an example: https://github.com/libp2p/js-libp2p-examples) and exchange messages through it, since I believe your network scale will have all the peers connected to each other. Pubsub broadcasts the messages outside your connected nodes.
webrtc-star relay with a port opened to the outside
Can you write further on this?
Thanks for those relevant information ! If pubsub is planed to have discovery, there will be everything in the box indeed, and creating a specific libp2p protocol sounds really good. I've had a glance on chat example, and will study how persistance is made. I am not the first to try to mix libp2p/ipfs/yjs, there is already y-ipfs-connector, which uses pubsub rooms also. It is not maintained any more, but may be it is time to update and make everything run again. CRDT on ipfs would be so relevant. When I said to open a port for webrtc-star, I meant to embed webrtc-star into one of the electron app clients, seen as a relay to the peers in local network (192.168.x.x). If needed, to share information outside, this client is made visible from outside through a port opened for this client only. It is a kind a p2p proxy... I don't know if it is clear :/
Yeah, I knew Pedro was working on CRDT stuff, but I did not know he was experimenting with yjs
. But yes, he is not currently working on it these days. Keep me posted, I don't have bandwidth to collaborate in this type of initiatives for now, but I am interested in this type of use cases for IPFS/libp2p
When I said to open a port for webrtc-star, I meant to embed webrtc-star into one of the electron app clients, seen as a relay to the peers in local network (192.168.x.x). If needed, to share information outside, this client is made visible from outside through a port opened for this client only. It is a kind a p2p proxy... I don't know if it is clear :/
Yeah, got it! It makes sense and I think you are on a good way here
Hello,
I've made some tries from this code, but 'peer joined' or 'message' events are not emitted with the same code on two computers in a local network. It looks like peers does not see each others. ipfs is running, as a ipfs.cat() works, getting content from ipfs.
ipfs : 0.46.0 ipfs-repo: 3.0.1 ipfs-pubsub-room: 2.0.1
this is like the demo code, though. Thanks for any clue.