4 ms·

I see these websocket connections in my network panel. wss://sfo-3.bootstrap.libp2p.io/ wss://nyc-1.bootstrap.libp2p.io/ wss://nyc-2.bootstrap.libp2p.io/ wss:/

by mbar 9y ago

I see these websocket connections in my network panel. wss://sfo-3.bootstrap.libp2p.io/ wss://nyc-1.bootstrap.libp2p.io/ wss://nyc-2.bootstrap.libp2p.io/ wss://ams-1.bootstrap.libp2p.io/ wss://lon-1.bootstrap.libp2p.io/ I'm going to guess this is to establish the connections between peers. So this isn't really p2p because while there aren't any intermediaries for data transfer, there certainly are to establish the data connections. If you want a p2p system because you care mostly about removing servers as a bottleneck, then this may not be an issue, but if you care about removing servers because you don't trust intermediaries, then this only gets you half way there.

diggan 9y ago
So the discovery is currently via Bootstrap Peers and a Signaling server that can help connect peers together. A P2P network needs some way of bootstrapping and having a couple of stable peers for doing that is the simplest and works in most scenarios. But, it doesn't work in all scenarios. In the go-ipfs version of ipfs (or running js-ipfs) we can use mDNS for local discovery without any bootstraps, but unfortunately doesn't work in the browser (yet! FlyWeb would help https://github.com/ipfs/in-web-browsers/issues/45 https://github.com/ipfs/in-web-browsers/issues/45). Some sort of gossiping could work as well but we're always glad to hear other ideas of how we can make discovery work without having to hardcoded bootstrap nodes or signaling servers.
lgierth 9y ago
These websockets node you see aren't servers. They're nodes like any other node, except they have a well-known domain name. They don't do any work that a browser js-ipfs node wouldn't be capable of.
stebalien 9y ago
> If you want a p2p system because you care mostly about removing servers as a bottleneck, then this may not be an issue, but if you care about removing servers because you don't trust intermediaries, then this only gets you half way there. This is, actually, truly peer-to-peer. Those are connections to the bootstrap nodes, you can set your own bootstrap nodes if you want but you do need to be seeded with a few initial peers to find new peers. If you want to establish a browser-to-browser connection, you will need some server to help setup the WebRTC connection; this is the unfortunate reality of browsers. However, you can (theoretically^) connect to arbitrary non-browser IPFS nodes over a websocket connection (that's what's happening here) without some "blessed" node acting as the rendezvous. ^Unfortunately, there's a bit of a wrinkle: 1. Most non-browser IPFS nodes don't listen on websockets by default. The transport is still experimental and and has some bugs. 2. If you load IPFS from an https origin, browsers won't generally allow you to establish connections to non-https websocket endpoints. Unfortunately, even if you enable listening on the websocket transport on your IPFS node, you'll end up listening on an http (not https) websocket. This is because IPFS manages the encryption of the connection itself (IPFS addresses, or "peer IDs", are cryptographic hashes of public keys) and doesn't use (or play well with) the CA system. To work around this, the bootstrap nodes have nginx proxies out in front that to handle HTTPs connections. Most (all other?) nodes don't.
marknadal 9y ago
Unfortunately browser technology sucks, WebRTC still requires a server to bootstrap the connections. It is incorrect to criticize this as not being P2P just because of existing limitations which immediately are removed if you were to run the exact same app in Electron or something. The best thing we can do is plead with browser vendors to improve this.

by mbar 9y ago

diggan 9y ago

So the discovery is currently via Bootstrap Peers and a Signaling server that can help connect peers together. A P2P network needs some way of bootstrapping and having a couple of stable peers for doing that is the simplest and works in most scenarios. But, it doesn't work in all scenarios. In the go-ipfs version of ipfs (or running js-ipfs) we can use mDNS for local discovery without any bootstraps, but unfortunately doesn't work in the browser (yet! FlyWeb would help https://github.com/ipfs/in-web-browsers/issues/45 https://github.com/ipfs/in-web-browsers/issues/45). Some sort of gossiping could work as well but we're always glad to hear other ideas of how we can make discovery work without having to hardcoded bootstrap nodes or signaling servers.

lgierth 9y ago

These websockets node you see aren't servers. They're nodes like any other node, except they have a well-known domain name. They don't do any work that a browser js-ipfs node wouldn't be capable of.

stebalien 9y ago

> If you want a p2p system because you care mostly about removing servers as a bottleneck, then this may not be an issue, but if you care about removing servers because you don't trust intermediaries, then this only gets you half way there. This is, actually, truly peer-to-peer. Those are connections to the bootstrap nodes, you can set your own bootstrap nodes if you want but you do need to be seeded with a few initial peers to find new peers. If you want to establish a browser-to-browser connection, you will need some server to help setup the WebRTC connection; this is the unfortunate reality of browsers. However, you can (theoretically^) connect to arbitrary non-browser IPFS nodes over a websocket connection (that's what's happening here) without some "blessed" node acting as the rendezvous. ^Unfortunately, there's a bit of a wrinkle: 1. Most non-browser IPFS nodes don't listen on websockets by default. The transport is still experimental and and has some bugs. 2. If you load IPFS from an https origin, browsers won't generally allow you to establish connections to non-https websocket endpoints. Unfortunately, even if you enable listening on the websocket transport on your IPFS node, you'll end up listening on an http (not https) websocket. This is because IPFS manages the encryption of the connection itself (IPFS addresses, or "peer IDs", are cryptographic hashes of public keys) and doesn't use (or play well with) the CA system. To work around this, the bootstrap nodes have nginx proxies out in front that to handle HTTPs connections. Most (all other?) nodes don't.

marknadal 9y ago

Unfortunately browser technology sucks, WebRTC still requires a server to bootstrap the connections. It is incorrect to criticize this as not being P2P just because of existing limitations which immediately are removed if you were to run the exact same app in Electron or something. The best thing we can do is plead with browser vendors to improve this.