Collecting P2P/DWeb Use Cases

[lidel]

Summary

This is a meta-thread collecting use cases for adding P2P and DWeb technology to web browsers.
Feel free to refer to this issue when discussing interesting use case
or just add link and/or citation in comments below.

Motivation

Browser vendors would appreciate easy-to-explain examples of tangible use cases that could be unlocked by use of P2P/DWeb technologies in web browser. It will help making the case for investing resources and planning dweb-related work. We have a lot of various projects and ideas floating around, but there is no one good resource that can could be used as a starting point.

[lidel]

ipfs/in-web-browsers#14 (comment):

• disconnected operation & offline (ie. local chat, share files without access to backbone, easy way to load simple applications and work with the person next to you [on airplane])
• when you're in an environment, being able to see local nodes around you (geographically local or metaphorically local, ie. nodes run by people with shared affiliations) and see which applications you can run with them -- similar to how airdop works on macs, chat, collaborative doc editing

CREATING THE COUNTERPOINT TO: "your machine is a portal to the cloud."
INSTEAD EMPHASIZING: visibility of what's around you.

Example: PeerPad is a realtime P2P collaborative editing tool, powered by IPFS and CRDTs. With local discovery and p2p transport it could be used in local browsers without uplink to the internet.

ipfs/in-web-browsers#14 (comment):

bookmark a page and snapshot it and serve that snapshot to the network. Plus, by extension, copy that snapshot to any additional nodes (i.e. Newspaper, Library, Legal Proceedings) with cryptographic integrity checks.

Example: resources in IPFS are content-addressed so address itself is enough to apply cryptographic integrity checks before bookmark snapshot is loaded from the network.

[lidel]

Realtime, bi-directional exchange of files between the browser and other IPFS nodes that have a) unique invite link b) are in the same LAN

We have a PoC built with websockets/webrtc at https://github.com/ipfs/js-ipfs/tree/master/examples/exchange-files-in-browser
Having TCP sockets + mDNS for local discovery would make it truly decentralized and robust (centralized signaling server is a big weak spot that could be eliminated).

[lidel]

ipfs/in-web-browsers#14 (comment):

Provide a faster and more reliable alternative to old school CDN [..]
If someone else on your LAN visited the website before, assets will be fetched from them.
No CDN can provide that.

Having local discovery method (eg. DNS-SD) and p2p transports in the browser context (such as TCP from libdweb, webrtc in worker or by some other means) would enable browsers in local network to share popular content with each other, effectively making the web more robust.

Apart from opt-in from website owner, it could be also implemented on the client side:

ipfs/in-web-browsers#94:

Automatic mirroring of standard websites to [DWEB] as you browse them [and sharing them with other nodes in LAN / DHT]

This is a much harder problem and comes with additional security and privacy considerations, but here are some initial ideas at ipfs/ipfs-companion#535 (comment)

[feross]

P2P use case: Distributed Hash Tables

DHTs are a fundamental building block of almost every P2P system. They are the primary routing layer in Bitcoin, IPFS, Dat, BitTorrent, and WebTorrent, for example. Almost every decentralized/distributed system needs to provide a lookup service similar to a key-value hash table. Using this distributed data structure, it's possible to build higher-level capabilities like peer-finding without a central signaling infrastructure.

Limitations of WebRTC Data Channels:

It's not possible to build a DHT on top of a WebRTC connection model. We need the ability to store the "contact information" for a peer, close the connection to that peer, and then re-connect to that peer at some point in the future (if they're still online). This is the way that DHT routing tables get built up over time. With TCP/UDP, this is quite easy to accomplish – simply store the ip:port (12.34.56.78:9000) and try to connect. If the peer is still online, it will just work. However, in WebRTC, the offer/answer connection model makes it impossible to store a peer's "contact information" and attempt to connect again later. A WebRTC connection offer or answer is one-time use.

I think that rectifying this in WebRTC requires a few changes:

1. Peers need the ability to "listen" for incoming connections.
2. Peers also need the ability to "fork", i.e. publish a "reusable offer/answer" that multiple peers can use to connect to listening peers (currently an offer/answer is usable only once)
3. Lighter-weight connections. It seems that the current WebRTC spec is very complex (or perhaps currently implementations are still immature). But this leads to a situation where it's really hard to open more than a dozen connections at once without the browser process hitting 100% CPU utilization. This prevents applications that would like to open 20+ connections from doing so, which makes Data Channels a lot less useful for use cases like peer-assisted delivery, peer-assisted live streaming, WebTorrent, DHTs, in-browser cryptocurrency networks, etc.

[feross]

P2P use case: Peer-assisted delivery

• Hybrid P2P. Optimistically serve content from peers, but fallback to HTTPS when no peers are available.

• See products from companies like PeerCDN (my company, sold to Yahoo), Peer5, and Streamroot. See open source projects like WebTorrent, PeerTube, etc.

[feross]

P2P use case: Sending files directly browser-to-browser

• Benefits: Faster on networks with a slow uplink to the "cloud", more private, could allow discovery of local peers like macOS's "Airdrop" feature.

• Current products implementing basic versions of this: https://instant.io, https://file.pizza/

• (Sidenote: this isn't a use case, but actually an implementation suggestion - All of these products would benefit from being able to use a ServiceWorker to intercept HTTP requests and then handle them via a WebRTC Data Channel instead. Currently, this requires creating the Data Channel in the main window and shuttling data back-and-forth between the main window and the ServiceWorker. If we add support for WebRTC Data Channel in Workers (see Add support for WebRTC Data Channel in Workers w3c/webrtc-pc#230) then these use cases become a lot easier to support. Less data copying, simpler architecture, better battery life, etc.)

[fippo]

@feross see the slides and recording from https://www.w3.org/2011/04/webrtc/wiki/June_19-20_2018 wrt Peers need the ability to "listen" for incoming connections. and Peers also need the ability to "fork", i.e. publish a "reusable offer/answer" that multiple peers can use to connect to listening peers (currently an offer/answer is usable only once). ORTC supports the forking you want.

[lmatteis]

Add ability for anyone to create a website without the use of DNS

Currently the only way to create a website is to register a DNS name and have it point to your HTTP server of choice. There are several problems with this design:

• The website owner needs to buy and renew their domain name
• The domain name can expiry after many years of inactivity effectively killing "old content"
• The domain name can be very expensive
• Authorities can easily shut down DNS names

Instead I'd propose a naming system using public/private key cryptography and a DHT network to notify users about where each address points to.

Effectively a user can then create any p2p://02a1633cafcc01ebfb6d78e39f687a1f0995c62fc95f51ead10a02ee0be551b5dc cheaply without any expense whatsoever, and have it point to any desired HTTP server. Only the user having the private key connected to such address can modify the DHT item and therefore change where it points to.

This would allow much larger possibilities for the Web as we know it since anybody would be able to create a site. Domain names are becoming also less and less used as one simply either "clicks a link" or takes a picture using "QR code" to reach a website.

[tschudin]

ICN (Information Centric Networking) is meant to replace IP, would cover many of the properties mentioned in this thread (e.g., content's hash as a resolvable name, obtaining verifiable copies from local neighbors, serverless web and offline operation).

So to the point of collecting use cases, you may find a good list in RFC7476 "Information-Centric Networking: Baseline Scenarios" from 2015, and more documents at the ICNRG's web site.

[aboba]

@feross ORTC specification is here: http://draft.ortc.org/ ORTC lib (which supports forking) is here: https://ortclib.org/

[dominictarr]

dweb applications ipfs, dat, and secure-scuttlebutt are really databases. But the browser lacks sufficient access to storage to implement these successfully.

I recommend adding low level file system access, in particular random access partial reads and appends to files. Also, move/rename. This file access can be in a reserved section allocated per domain, does not need to be in the user's home directory.

[dominictarr]

to build something that is really decentralized, the code should also be decentralized - that is, the source, and wether or not to update should be under the user's control. ServiceWorkers provide much of this, but unfortunately they always do a forced update every 24 hours. This makes it hard to design a system that is robust in the case of server compromise. If we could disable automatic updates like this, we could make truly secure systems.

(currently, the best we can do to prevent malicious updates is have an application self-destruct: if an unexpected update is detected, private keys and other sensitive data is destroyed. This at least means that attackers will not be motivated by profit, but does not exclude attackers motivated by spite)

[RangerMauve]

As mentioned in this Beaker Browser Issue the main problem browsers have right now, IMO, is the inability to discover and communicate with peers.

In my opinion, having a high level API that would "discover peers for a key" and provide a duplex communication channel would be enough to build all sorts of P2P applications on.

WebRTC was great in giving us to connect directly to other machines, but the inability to discover those machines without a centralized, internet-accessible, service makes it impossible to create truely p2p applications.

[amark]

I know there are specs/flags/extensions for some of these:

• UDP support flat out (not via reliable: false mode).
• Bluetooth support (or in general, similar to other people, "discover what is nearby" without a cloud ability).
• haveIbeenpwned hash check or similar (even the compressed version is 2GB which browsers wouldn't want to carry around, let alone mobile) but an API for rating password security relative to human/social hacks would be appreciated.
• hardware wallet proxies WebCrypto is great, but proxies to pass to hardware wallets, libsodium, or natively installed identity services (or APIs for them in the browser, without vendor lockin to Moz/Google/Apple) will be critical.
• Argon2 kdf in WebCrypto / other.
• localStorage limits allow user to increase, like with IndexedDB (localStorage compatibility/ease hands down beats IndexedDB).
• DHT "like" features, like others have said, to circumvent DNS/IP limitations, ICE limitations, etc. sounds like ORTC is going in that direction? (By DHT "like" features, ideally I mean for me instead, having a public-key to IP/address peer discoverability via a radix "DHT" capable of being sharded amongst peers.)

Good group of people in this thread :).
Oh hey @RangerMauve , long time no see in years - hope you are well!

[Gozala]

I thin there is a lot of useful notes in this thread. I would propose organizing it in a following manner:

• Use cases that is not possible with existing web capabilities. And what value does this provide to the user.
• Set of technical limitations in current web platform that prevent it.
• What could enable this

Here is an example

Use case: Getting content across two devices in the same room without internet access.

• Enables file sharing while on airplane, subway, disaster situation, or travailing abroad.
• Enables collaborative applications, like google docs but while camping.
• Makes geographically relevant large sized data available for free in relevant locations. Local maps replicated by coffeeshop, AR exhibitions etc..

Limitations:

• Web platform does not expose capability to discover & connect to devices nearby.
• Web platform does not expose capability to advertise content and listen for connection from devices nearby.

Solution:

• Provide an API for peers (e.g. WebRTC RTCPeerConnection description) to be advertised / discovered over the local network. That would allow two web apps on different devices but on the same network complete a handshake.
• Provide an API for peers to broadcast and observe messages over the local network. While above option would enable two nodes connect to each other it's suboptimal for sharing large amount of data with large groups as each chunk need to be send no individual connection. Broadcasting API would provide more optimal solution and would also enable advertising / discovery described above.

I think there are multiple benefits to this approach:

1. It illustrates problem that people can resonate with, which helps in getting them into "how do we solve it mode".
2. Articulates what specific limitations are there, and as we collect use cases we'll be able to see which specific item appears over and over making it easier to prioritize.
3. Proposes specific solution to address this use case. As use cases aggregate it would allow how one thing could unlock many or how solution to one use case addresses n other use cases allowing to prune their proposals.

[lgrahl]

I suggest to create a set of requirements similar to the WebRTC NV Use Cases which also overlap with the interests brought up here.

[lgrahl]

The WebRTC WG is still gathering use cases for the next version of WebRTC which will be discussed at the June interim. File your use cases if you haven't already.

Furthermore, we need someone to present the DHT use cases (filed in w3c/webrtc-nv-use-cases#15) which potentially requires fundamental changes in WebRTC. I have already broken down the use case into requirements and I can also help with the technical details (what WebRTC can and currently cannot do) and presenting the requirements. But I'm not well-versed in DHTs, so someone else needs to join.

[Gozala]

@lgrahl thanks for bringing this up! I’m also not the best candidate to present on DHTs, but I’ll make sure to find someone. We’ll also bring this up at dtn.is to try & get more people involved.

/cc @autonome is there anyone from PL who could participate?

[Gozala]

@feross you do have experience with both WebRTC and it’s shortcomings in the p2p context, would you be compelled to engage in this (referring to WebRTC next mention earlier) ?

[jacobheun]

@jhiesey might be able to help out with presenting the DHT/p2p use cases.

[jhiesey]

See use cases here: libp2p/js-libp2p-webrtc-star#177 (comment)