[WIP] propose: browser nodes can connect to any node out of the box #70
Conversation
proposals/browser-nodes-can-connect-to-any-node-out-of-the-box.md
Outdated
Show resolved
Hide resolved
| What awesome potential impact/outcomes/results will we see if we nail this project? | ||
| --> | ||
|
|
||
| We had some really good discussions yesterday about the state of Pubsub/IPNS in each runtime environment + what are the gaps for building dapps on our stack out of the box. |
There was a problem hiding this comment.
Are there notes from the conversation? I am seeing now that this is WIP.
There was a problem hiding this comment.
Yes, this was a wrong copy paste and not intended for the actual proposal. But here are the notes: https://hackmd.io/@gozala/state-of-ipns
Co-authored-by: Steve Loeppky <stvn@loeppky.com>
|
Some notes from @lidel that should be important to catalog here: ipfs/in-web-browsers#181 |
|
|
||
| Having browser nodes to connect with go nodes out of the box essentially means one of: | ||
| - go nodes listen on webrtc by default + we can use limited relays to also negotiate webrtc conns + we deploy nodes that can act as limited relay and have dns + wss addresses (which means not all DHT servers will be capable of doing so out of the box) | ||
| - go nodes listen on websockets address by default + we find a solution for out of the box certificates for announcing dns+wss multiaddr |
There was a problem hiding this comment.
the certificate problem seems like it could be a project in itself, go-ipfs certbot integration or something like that, the whole certificate problem is a diabolical one!
There was a problem hiding this comment.
Ah, I see ipfs/in-web-browsers#181 touches on some of the issues related to certs, but that doesn't even suggest a clear path forward. That presents us with a scoping challenge here, we have no clear technical solution and this may end up being experimentation to figure out something workable. Ideally we'd have a solid idea to at least try and can scope fail/success with that.
There was a problem hiding this comment.
An experimental project here would be to vet the feasibility of a service to issue subdomain certs/DNS mappings to https://<peerid>.libp2p.io or similar.
The other option is likely more viable (bind to a limited relay), but, we have to consider that if hole punching fails the nodes won't be able to speak.
Another option here is improving the active relay support story. If browser nodes are able to bind to a local node, or potentially later a relay-as-a-service, then execute dials through the relay as a fallback we can reduce the dependency on the SSL problem. This might look like:
- Improve browser ability to discover local and remote relays to bind to
- Ensure those relays can be/are configured to be active HOP relays (dial on a nodes behalf)
- Improve the prevalence of these relays (more local deploys, ipfs desktop, embedded browser nodes, hosted/incentivized services, electron template app)
There was a problem hiding this comment.
https://<peerid>.libp2p.io sounds like a whole can of worms, similar to the gateway problems (hosting content we don't necessarily want to host) but for more than just content (i.e. someone could abuse the service to host whatever they like, https, on a domain we own. Maybe there's been some thought put into how to deal with these kinds of problems already?
2 other options for managing certificates:
- Build a certbot plugin to manage certificates for a go-ipfs node, probably with some go-ipfs interaction to setup the challenge process (down side: this is very opt-in, even if we make it super simple for them)
- go-ipfs already has some user-interactive startup operations that it performs (fs migrations being the main one I think), so another option here is to build in the full letsencrypt certificate management process to node setup - as an optional, but encouraged step. It'd not be a simple project, but there's a full featured go library for dealing with ACME so we could run the entire process, including renewals, with some initial setup from the user.
The challenge process introduces awkwardness in both options but there could be a simple-path for easy setups (no NAT, no complex firewalls, etc.) and documentation for the more complex-path setups.
There was a problem hiding this comment.
That presents us with a scoping challenge here, we have no clear technical solution
I think we should attack this in two stages (updated ipfs/in-web-browsers#181 to reflect that):
- Add ACME support as opt-in "bring your own domain" feature to go-ipfs
- safe to do, reduces complexity of
/wss/deployments: no need for third party software like certbot or nginx.
- safe to do, reduces complexity of
- Each peer gets a free domain out-of-the-box
- this is a can of worms which will take time, or we may decide not do at all
Even if we never do the second one, built-in ACME support for setting up /wss on own domain is a good match of real life usage (people self-hosting IPFS infra on own domains), and would make things easier for everyone.
There was a problem hiding this comment.
Thanks @vasco-santos for the ping.
Even if we never do the second one, built-in ACME support for setting up /wss on own domain is a good match of real life usage (people self-hosting IPFS infra on own domains), and would make things easier for everyone.
👍 for option 1 being good enough, especially when "go nodes listen on webrtc by default", as browsers could connect to non-ssl Go nodes via WebRTC with the help of a smaller number of SSL + WSS Go nodes as signaling servers using circuit relay v2.
but, we have to consider that if hole punching fails the nodes won't be able to speak.
True. Sorry, in case this is a question already discussed: Is the goal of this proposal with Browser nodes can connect to **any** node out of the box a hard requirement, or is increasing overall connectivity on a best effort basis good enough?
Asked differently would Browser nodes can connect to **most** nodes out of the box, with the remaining nodes being the ones unreachable due to WebRTC NAT hole punching issues, be a goal worth achieving as well? To me 100% connectivity in a peer-to-peer setting seems impossible in the first place, thus I would assume the latter title to be more accurate. What do people think?
| <!--Briefly describe the milestones/steps/work needed for this project--> | ||
|
|
||
| #### What does done look like? | ||
| _What specific deliverables should completed to consider this project done?_ |
There was a problem hiding this comment.
| _What specific deliverables should completed to consider this project done?_ | |
| _What specific deliverables should completed to consider this project done?_ | |
| - Seamless ACME support to go-ipfs and js-ipfs: entering `/dns4/.../wss/` addr in `Addresses.Swarm` and setting up ACME endpoint for the domain name in something like `ACME.Endpoints` is all the user needs to do to have Secure WebSockets transport enabled. |
| _What specific deliverables should completed to consider this project done?_ | ||
|
|
||
| #### What does success look like? | ||
| _Success means impact. How will we know we did the right thing?_ |
There was a problem hiding this comment.
| _Success means impact. How will we know we did the right thing?_ | |
| _Success means impact. How will we know we did the right thing?_ | |
| - We see a clear trend of increasing number of `/dns*/.../wss/` addresses announced on the DHT |
| --> | ||
|
|
||
| #### Counterpoints & pre-mortem | ||
| _Why might this project be lower impact than expected? How could this project fail to complete, or fail to be successful?_ |
There was a problem hiding this comment.
| _Why might this project be lower impact than expected? How could this project fail to complete, or fail to be successful?_ | |
| _Why might this project be lower impact than expected? How could this project fail to complete, or fail to be successful?_ | |
| - The need for having own domain name for getting TLS cert via ACME endpoint is a good first step, but won't make difference big enough to enable universal connectivity. We may need to provide peers with `{peerid}.libp2p-peer.io` name for TLS and partner with ACME provider to ensure that mining TLS certs for third-parties under our name like that is ok. |
|
|
||
| Having browser nodes to connect with go nodes out of the box essentially means one of: | ||
| - go nodes listen on webrtc by default + we can use limited relays to also negotiate webrtc conns + we deploy nodes that can act as limited relay and have dns + wss addresses (which means not all DHT servers will be capable of doing so out of the box) | ||
| - go nodes listen on websockets address by default + we find a solution for out of the box certificates for announcing dns+wss multiaddr |
There was a problem hiding this comment.
That presents us with a scoping challenge here, we have no clear technical solution
I think we should attack this in two stages (updated ipfs/in-web-browsers#181 to reflect that):
- Add ACME support as opt-in "bring your own domain" feature to go-ipfs
- safe to do, reduces complexity of
/wss/deployments: no need for third party software like certbot or nginx.
- safe to do, reduces complexity of
- Each peer gets a free domain out-of-the-box
- this is a can of worms which will take time, or we may decide not do at all
Even if we never do the second one, built-in ACME support for setting up /wss on own domain is a good match of real life usage (people self-hosting IPFS infra on own domains), and would make things easier for everyone.
This is still incomplete and in progress