Idea: webrtc

[Tomas-M]

Hi. Just idea: using webRTC, browsers can communicate peer-to-peer. So there is no need to install any windows application, the whole thing can run in browser. However you would need to write the software in JavaScript.

[HelloZeroNet]

There is many problems with webrtc:

• Not possible to create sandboxed iframe enviroment (cross-origin scripting problems)
• Tor connection not possible (Around 50% of ZeroNet clients using Tor)
• No SQL support
• File storage problems (max storage size per site origin)
• No support for non-web content (eg. github repository)
• You would need to keep an open browser tab for every site you seeding
• You private key would need to be stored by the browser, so any site you visit would able to access it
• WebRTC is created for small number of clients videochat system, not suitable to handling 100s of connections

[Tomas-M]

I agree with most of the objections, webRTC is shitty but it's the only thing available. Just a note, File storage quota in browser can be increased to unlimited if user confirms.

[Tomas-M]

Closing, since it was just an idea :)

[HelloZeroNet]

a light webrtc client would be possible that is allow to browse static (non-sql based) websites

[phiresky]

I think this should be reconsidered because it would further reduce the entry barrier for accessing decentralized websites from "download, extract, execute" to "click on this link".

Not possible to create sandboxed iframe enviroment (cross-origin scripting problems) You private key would need to be stored by the browser, so any site you visit would able to access it File storage problems (max storage size per site origin)

As far as I can tell you could do the following: Create two subdomains: gate.zeronet.io and webrtcclient.zeronet.io

Sites can be accessed using e.g. gate.zeronet.io/#/ZeroNetwork.bit.

On gate.zeronet.io, create an iframe containing webrtcclient.zeronet.io, which contains a port of the python client, stores the database (locally), has the secret keys and communicates with other clients using WebRTC. WebRTC support would then need to be added to the python client as well so they can interoperate. Webtorrent is a good example of this already working.

Then replicate the API currently accessed via WebSocket through the iframe via cross-document communication (window.postMessage).

No SQL support

Most browser support IndexedDB which can be used to store multiple gigabytes of data (up to some % of the available disk storage in chrome AFAIR)

The data files could also be stored using IndexedDB or using the Filesystem API / a polyfill for that. There is also a sqlite "port" to Javascript which should be possible to persist also using IndexedDB.

No support for non-web content (eg. github repository)

I think the priority here should be web content, but it should also be possible to implement download of arbitrary data (e.g. as a zip)

You would need to keep an open browser tab for every site you seeding

You would probably need to keep at least one tab open containing webrtcclient.zeronet.io yes, though Browsers have been starting to add functionality to do stuff as a website without actually having the website open, see Service Workers, Push API

WebRTC is created for small number of clients videochat system, not suitable to handling 100s of connections

Not sure about scalability, I couldn't find anything about WebRTC max connections right now. A fairly large problem might be not being able to use UPNP port mapping, but WebRTC has NAT traversal integrated.

Another is sending of large data cross domain.. not sure if thats possible without passing blobs via postMessage which might be too slow. An alternative would be to use a wildcard subdomain and access pages using zeronetwork.bit.gate.zeronet.io, then every site can have its own database.

Tor connection not possible (Around 50% of ZeroNet clients using Tor)

Probably, I don't have any ideas about that.

I just found ZeroNet, so I'm sorry if I misunderstood something about how it works.

[obv-mikhail]

@HelloZeroNet When WebAssembly (supported in chrome canary) comes out, SQLite will get ported over and should be pretty fast. Seeding zites without tab open might be possible using a browser extension. Also, someone will likely make a python to WebAssembly compiler which might make porting over somewhat easier.

https://github.com/pypyjs/pypyjs/issues/145

[SEVENID]

You would need to keep an open browser tab for every site you seeding

Nope. Extention does it in background.

Tor connection not possible

Nope. Maybe you can't connect to control port, but browser can actually be connected over tor like proxy. (you really need to know how much users use tor?)

File storage problems

Nope. Use browser's cache as file storage.

You private key would need to be stored by the browser, so any site you visit would able to access it

Nope. See extention.

WebRTC is created for small number of clients videochat system, not suitable to handling 100s of connections

Are you sure that you need more than 20-30 connections? Then one in five was on a site that you want?

And extention can redirect all *.bit zites to itself. Extension rules.

[HelloZeroNet]

If we target browser extension, then we don't need to use half-p2p webrtc sockets and deal with other js limitations, but we can do create real sockets like https://deepankar.io/current_projects/details/kronymous do

[ysc3839]

Yes! I know there's some IRC clients in Chrome. If it doesn't support real sockets they can't support IRC protocol.

[phiresky]

Maybe this issue should be reopened?

I don't think targeting a Chrome extension would be the right approach here. That immediately binds to it to some extension API and thus to one browser. And every user would still need to install a Chrome extension. I wouldn't press install if someone sends me a random link, and that would be my goal for this; to be able to send links to websites that are viewable to almost everyone, instantly, and while still 95% decentralized.

You don't need to be an extension to get sandboxing for storing private keys or for storing data on disk. The only weak point I can think of is the https CA system.

You could still publish a thin extension for parsing .bit domains and similar; and to verify the integrity of ZeroNet links to prevent the domain/CA system from compromising decentralization.

Not sure why every one here seems to be of the opinion that WebRTC sucks? The only problem I can see is that it does not support UPNP Port forwarding; but it has NAT port punching integrated. https://webtorrent.io/ opens >10 real peer to peer connections in less than 3 seconds for me and downloads 100MB from those in 30 seconds.

[HelloZeroNet]

I have just opened webtorrent.io in latest chrome, it freezed my browser for 20 second, then started playing, but according to the dev console (F12) it downloads the video from https://webtorrent.io/torrents/sintel-1024-surround.mp4 and the webtorrent.io tab currently using 250MB of ram

I'm not saying webrtc or webtorrent is bad, but it does not looks mature to me. (or suitable to handle many connections)

Also webrtc connections not fully p2p, you need to contact to google (or someone) before create connection to anyone: "Unfortunately WebRTC can’t create connections without some sort of server in the middle. We call this the Signal Channel. " - via

[phiresky]

it downloads the video from https://webtorrent.io/torrents/sintel-1024-surround.mp4 and the webtorrent.io tab currently using 250MB of ram

Okay, I guess I never tested it on a slower machine. But I don't think 250MB is bad, considering it has to keep at least 130MB of video in RAM.

Yeah, thats because that URL is a webseed. It did download 2MB (in 60KB chunks) from that URL for me too, but the remaining 128 MB were downloaded from peers. (not shown in Chrome Dev tools)

Also webrtc connections not fully p2p, you need to contact to google (or someone) before create connection to anyone

Well yes, but thats just bootstrapping right? You need that with every other method too, you can't just port scan the entire internet.

I'm not sure about this (have not tried it), but at least from how I understand it, you can get the peer description JSON via any channel. So you can connect to peers you get from other peers without ever going through a central server, once you have the initial connection to some peer.

[HelloZeroNet]

Okay, I guess I never tested it on a slower machine. But I don't think 250MB is bad, considering it has to keep at least 130MB of video in RAM.

I have i5 6600k (skylake) CPU, so it's not so slow. The GPU is running in separate process, so it's not includes that (if I open https://webtorrent.io/torrents/sintel-1024-surround.mp4 in a tab its displays 15MB)

Well yes, but thats just bootstrapping right?

No, it's not for bootstrapping (getting peer ips), but the both party need to connect to the STUN server every time before they want create new connection with eachother. I think it's for security reasons, to avoid DDOS attacks from webpages. (and add socket security)

[HelloZeroNet]

I don't really feel like to start developing it but, I would be happy if someone would do more experiments and I'm open to add webrtc connection support to python client.

[phiresky]

I have i5 6600k (skylake) CPU, so it's not so slow. The GPU is running in separate process, so it's not includes that (if I open https://webtorrent.io/torrents/sintel-1024-surround.mp4 in a tab its displays 15MB)

True, but it still needs to keep it in JS memory to be able to seed it or receive bits that it doesn't have yet.

No, it's not for bootstrapping (getting peer ips), but the both party need to connect to the STUN server every time before they want create new connection with eachother.

According to this: https://github.com/cjb/serverless-webrtc/ (warning: shitty demo, barely works) It should work without a central server if you are able to send your peer a 4KB JSON and receive one in return through a different channel. The only thing you need is a STUN server connection once to get your own public IP and NAT configuration

I might look into doing some experiments but don't hold your breath.

[SEVENID]

Also webrtc connections not fully p2p, you need to contact to google (or someone) before create connection to anyone

Wait, situation is different now? ZeroNet can work only with the use of LPD, PeX and DHT? Without any tracker? already? (Sorry for that, but real p2p is still not been reached, e.g., I can't load downloaded zite from different node in local network without internet connection)

[HelloZeroNet]

Yes, the situation is totally different now: In webrtc you need to connect to STUN server before every connection you make. The torrent trackers is only required to get the list of the possible peers, but you don't need to connect and report them before every new connection you make.

Pex is supported and peers is saved to local database, so you can use previously known peers.

[HelloZeroNet]

According to this: https://github.com/cjb/serverless-webrtc/ (warning: shitty demo, barely works)

After tring it out the demo works this way:

• Client A: Generate the the 4KB JSON
• Client B: Based on the 4KB JSON generate a response to 4KB JSON
• Client A: Using this response can connect to Client B

So I have no idea how could it work without any middle server. A tracker could store Client A's 4KB JSON, but you need the response to your 4KB JSON create the connection.

[Tomas-M]

As far as I know, clients cannot generate the 4KB JSON itself. They need to connect to a STUN server in order to obtain the information. The JSON contains IP addresses of gateway, port, etc - basically the information needed for other computers to connect to it. As far as I know there is no way to avoid this step, the browser needs to connect to STUN server to get the data. There are public STUN servers provided by google and many others.

Later, when clients have this 4KB JSON, they have to exchange this information so they know how to connect to each other. For that, there is usually another type of server needed (singalling server). But you may exchange the data between peers in any different way (users send it manually by email for example). There is example here: https://github.com/cjb/serverless-webrtc

In general, webrtc is not peer to peer per se, it needs some servers to setup connections between peers. However, once the client is connected to the p2p network, he can exchange data between peers directly without any additional server. As long as the client is on a type of network which allows this.

[Tomas-M]

One thing to add, as soon as the user is connected to other peers, he can use these peers to connect to other users (which are connected to the same peers), so there is no longer need for the signalling server in that case, if I understand it correctly. So the servers (stun and signaling) are only needed for initial connection of the client to the network.

[HelloZeroNet]

According to this diagram you always need a signal channel to create new connections. Maybe this signal channel can be an another peer, but then both peer has to be connected to the same peer before they can create new connection to eachother.

[HostFat]

Is anything changed on this issue? Are there now some useful features on browser and new code/support for webrtc that there wasn't before?

[54174]

I have a somewhat related approach in mind, keep an eye for my project WRW in the future.

[HelloZeroNet]

I know no new, related technology in the web standards.

[fermmm]

I heard IPFS protocol is being added by default in Firefox. If I understand everything correctly, IPFS can be used to implmenet a faster and better zeronet without the user installing anything.

[ROBERT-MCDOWELL]

crazy how google, firefox and other are just stealing all flash technology, ipfs uses a "smart" global sharedObject implemented in actionscript3 8 years ago.