So before I start setting it up, help me understand what is the simplest way for browser nodes to discover and connect to IPFS nodes. I see many variants there and I’m new to this field, so what is the best option for the most decentralized website you can get? Thanks!
1 Like
I’m trying to get a blog post up about this. For now, I hope this draft helps you on your adventure.
tl;dr you’ll likely want a combination of:
- Reliable bootstrap node(s)
- WebRTC-Star
- circuit-relay
Thank you very much, will read that now.
Will try to implement this tomorrow, I just wanna drop one (pretty much political) point here: We won’t get far with decentralized web if setting up is this complicated! And I know for sure things could be much much simpler with proper native support in browsers. Things need to go much faster toward decentralized web, Chrome and Firefox are fucking snails in this field. I believe it’s intentional.
After all, this is not fully decentralized at all. Don’t want to hurt anyone, especially not developers working on the case but until some peer discovery protocol is not natively supported in web browsers, we can’t say we decentralized the web.
This document is linked in your tutorial: GitHub - libp2p/js-libp2p-webrtc-star: libp2p WebRTC transport that includes a discovery mechanism provided by the signalling-star
Trying to start signalling server gives:
/usr/local/lib/node_modules/libp2p-webrtc-star/node_modules/@hapi/teamwork/lib/index.js:8
#meetings = null;
^
SyntaxError: Invalid or unexpected token
I’m not anywhere close to Javascript expert, but is “#” allowed at all in Javascript? I think not?
The “ipfs://” protocol type is supported in Brave browser at least, but you may already know that. I’m not sure how Brave goes about selecting a gateway to pull from, but there must be some config setting for that.
Yes I know that, it’s only that I don’t if such URLs can be used in the Javascript too?
I’ve never used Brave. I only know it supports IPFS protocol. I don’t know if JS itself would choke on that protocol or pass it just fine to some lower level network code and work just fine. Good question.
Having some weird troubles following js-libp2p-webrtc-star/DEPLOYMENT.md at master · libp2p/js-libp2p-webrtc-star · GitHub for docker installation…
First… js-libp2p-webrtc-star_1 | Listening on: http://0.0.0.0:9090
…but it’s not there listening
and secondly, I cannot access my site (defined with DOMAIN) even if I made correct NAT translation. Not the docker can access it to validate the domain for SSL.
[Thu Jun 3 17:58:34 UTC 2021] xxx.yyy.zzzz Verify error:Fetching http://xxx.yyy.zzzz/.well-known/acme-challenge/8n3BqBc7iyj_V0RfzTv30LJ6b08MwM73lQpOPOU4njM: Error getting validation data
Anyone’s going through same troubles?
You were right, this is real adventure… 
Seems like I’m close to setting up it all in docker. For starters, any idea why libp2p-webrtc-star says it’s listening on 9090, but actually not? So I can’t connect to my star node, and also that port 4430 in p2p-circuit section is confusing. Is that port supposed to be served by some docker container service I installed? There are only servers at 80 and 443, not 9090, nor 4430.
OK I just realised p2p-circuit is installed separately… so it’s like 4 decentralized services by now to serve web browsers… Kind of defeats the purpose of it all, but I hope things will get better in the future.
The way I do it is having go-ipfs and call the http API from the website. Your IPFS node must have CORS set though.
Thanks for letting me know it’s possible, because this other way the Discordian suggested is so extremely complicated I don’t believe I can alone solve the problems I encountered. 
Still I don’t believe it’s possible to instantiate OrbitDB database object with IPFS HTTP API, so that kind of not doing the work for me.
I’m not sure why you’d have that issue. If you’re trying to connect a browser to the default 9090 port it likely won’t work as browsers expect SSL.
You’re referring to using Nginx as a reverse proxy for SSL?
It’s served by Nginx.
This is covered in the “Nginx Setup” section, it’s important to slowly read though the tutorial, it’s meant to give you a lot of information quickly, and doesn’t really repeat too much.
p2p-circuit is served by a go-ipfs node. This is covered under p2pcircuit#Setup.
I hope this helps, I’m not quite sure where you’re getting lost. FWIW the final version will have some sort of docker setup you can try out before diving into the full tutorial.
Edit: Also p2p-circuit and WebRTC-Star are both technically optional, but both help a lot in peer discovery and connectivity each in their own way.
It seems I forgot to add in how to actually use Certbot, I’ll update that section. Also if you have more feedback about specifically the SSL/Nginx stuff, please write it out, especially if you hate it. It’s a good time to work on that.
I’m not sure why you’d have that issue. If you’re trying to connect a browser to the default 9090 port it likely won’t work as browsers expect SSL.
I did not try to connect to it, I just asked why libp2p-webrtc-star says it’s listening on port 9090, but actually not. Also, I’m not sure browsers expect SSL by default when reading from port 9090, aren’t they able to read from that port in unencrypted form too?
Here’s what is stated in your blog post: “If you opt for the native setup, we cover the Nginx reverse proxy process and SSL cert retrieval later in this post.” I opted for docker setup, which seems to be properly installed (except that 9090 thingy), so I assumed nginx setup section of your blog post is not relevant
You’re referring to using Nginx as a reverse proxy for SSL?
No, I’m referring to this part of your blog:
ipfs = await Ipfs.create({
config: {
Bootstrap: [
'/dns6/ipfs.thedisco.zone/tcp/4430/wss/p2p/12D3KooWChhhfGdB9GJy1GbhghAAKCUR99oCymMEVS4eUcEy67nt',
'/dns4/ipfs.thedisco.zone/tcp/4430/wss/p2p/12D3KooWChhhfGdB9GJy1GbhghAAKCUR99oCymMEVS4eUcEy67nt'
]
}});
Please write here when you updated that section about Certbot.
Maybe if I tell you what I’m trying to achieve, you’ll be able to tell me with what minimal set of services I need to go, and then to eventually improve and optimize with additional services. I’m having OrbitDB instance of database running on one js-ipfs node and I want to be able to connect to it from plain browser (not nodejs), and I want the database to be replicated among every peer that is interested into it, and every peer should be able to have write rights to database.
That’s odd, how did you verify that? It just works out of the box for me.
Not 100% sure of all the restrictions but generally, at least for websockets, most browsers will make you connect over SSL and use DNS, or the connection will just fail. There’s an exception there for localhost connections.
If you followed their docker setup, it’s not 100% clear to me, but it looks like they try to put the encrypted port on 9090. You’re right that you don’t need Nginx for WebRTC-Star at that point, but you’ll still want it if you plan on using p2p-circuit. If 9090 isn’t open with that container running, not really sure why that’d be (I haven’t tried that Docker image).
I think I’ll separate the Nginx section into it’s own thing, and slow down on the explanation. Right now I go in broad, assuming most people already have basic knowledge of setting up a reverse proxy. This seems to be the wrong move.
Ah those 4430 are WSS ports. go-ipfs can only setup ws ports by default, and after that usage section, I show how to get WS going on 4011, then in the follow Nginx section, how to reverse proxy the 4011 port into 4430 for SSL connections (but without the Certbot step, whoops!).
OK I will.
Hmm not familiar with OrbitDB specifics, but if your main concern is ensuring you can find and connect to peers on your app, the tutorial is for exactly that. So you seem to be on the right track.
That’s odd, how did you verify that? It just works out of the box for me.
netstat -tpnl console command shows no listening servers at port 9090, and this is the only entry from docker container’s log: “Listening on: http://0.0.0.0:9090”
If nothing else helps, I will try the “native” setup, although I had some problems previously and that’s why tried docker way.
My impression when working with OrbitDB is that I don’t need to find out what peers are interested to connect to database and to connect manually to them. I was thinking that part was somehow automatically solved by IPFS layer that is embedded into OrbitDB, and I hope I’m right because what’s “distributed decentalized” in OrbitDBs name if it doesn’t function that way?
Anyways, I’m closely following updates to your blog post and will comment on it and try to do something with it.
That’s really strange, I don’t have that problem. Here’s mine (I set non-SSL to 9091, SSL to 9090):
tcp 0 0 0.0.0.0:9090 0.0.0.0:* LISTEN 19894/nginx: worker
tcp 0 0 127.0.0.1:9091 0.0.0.0:* LISTEN 22415/node
I’ll try to think on this, but if you can’t figure it out it might be worth it’s own thread or an issue.
It is distributed and decentralised however browser js-ipfs is very young right now. Discovery is much easier outside of a browser. Inside a browser there’s a lot of work going on around better discovery mechanisms and what defaults should be considered sane, and what ones shouldn’t be. It’s a tough problem to solve, which is why I made the guide to try to show people who want to play with the tools today some of the more powerful options available.
Thanks, I do appreciate it. Going for lunch rn, but after I’m working on this, as I really want that post to be live.