Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hyperswarm network reliability and fallback #3

Open
urbien opened this issue Sep 22, 2020 · 1 comment
Open

Hyperswarm network reliability and fallback #3

urbien opened this issue Sep 22, 2020 · 1 comment

Comments

@urbien
Copy link
Member

urbien commented Sep 22, 2020

Problem

See the issue for this. Summary:

  1. No UDP in browsers.

  2. Corporate firewalls may block UDP. Need to bridge to DHT over WebSockets or WebRTC.

  3. No peer discovery on Cell Phone networks. Cellphone networks run symmetric firewalls. So mobile apps or PCs on HotSpot can't establish direct connections (although UDP works, NAT hole punching does not).

  4. DHT state needs stability. Peers that come and go lose DHT state and need to recreate it (although this can be overcome with caching). Peers that change their IP address too often, destabilize DHT.

This solution uses 2 servers for signaling.

Note that WebTorrent works in the browser. Need to investigate how they do it. They have been discussing "DHT over WebRTC" for a long time.

See a number of issues still pending resolution to make Hyperswarm and Hypercore work in react-native

Fallback using Personal Cloud

  1. If in browser, fallback to 2.
  2. check holepunchable indicatior in Hyperswarm. If false, fall back to next ..
  3. get DNS record for bootstrap servers (multiple IPs). Tradle will dynamically populate DNS records using DNS server of the Data Center(s) in runs in.
  4. choose IP randomly (or rely on a DNS client to give one) and request DHT lookup for desired my Personal Cloud (e.g. hash of Identity).
  5. Mutual Authentication that this is our Personal Cloud. If failed, choose another IP.
  6. Cache IP. Response needs a TTL, e.g. 24 hours.
  7. Mutual Authentication that this is our Personal Cloud. If failed, repeat 2.
  8. Forward all Hyperswarm request to that IP.
  9. Read a feed from Personal Cloud with IP addresses of bootstrap servers. This avoid DNS altogether.
  10. Next time IP does not respond or does not Authenticate, repeat 3.

Notes

  • avoids the need for DNS records for Personal Cloud servers
  • avoids the need for SSL certificates for Personal Cloud servers
  • still has a choke point as relies on supernodes for the initial DHT lookup. But regular Hyperswarm also has bootstrap servers, so not worse.

Future research

To increase privacy, especially for applications like COVID-19 Contact Tracing, we need to add encryption to DHT traffic.

  • To encrypt DHT traffic we need to add Noise, which adds several roundtrips (RTT). QUIC provides 0-RTT, but can it be used for hole-punching? I think it will as the principle is the same: 1) UDP traffic leaving your peer passed NAT and leaves it open for traffic on this port. 2) exposes NAT's public IP,Port to DHT server socket.
  • QUIC alternative is Noise, which Hypercore already uses, and Noise offers 0-RTT. One of the Noise patterns, IK (which is 0-RTT) received formal verification from the WireGuard VPN authors.
  • With 0-RTT you need to be especially careful with replay attacks. So doing updates to DHT on 0-RTT is not OK, but doing queries is safer
  • QUIC creates dependency on TLS certificates, which Noise does not have
  • QUIC / HTTP/3 will expose API in the browser to utilize UDP. This may allow DHT over QUIC. QUIC resolves the absence of UDP in the browser but still has an issue of DHT stability, which Personal Cloud overcomes.
  • Cloudflare open-sourced QUIC / HTTP/3 implementation in Rust (so it may be able to run in WebAssembly in Node and browser).
  • Chrome-specific (for now) RTCQuicTransport is WebRTC on QUIC with better RTT, and also using UDP and falling back to TCP. Will require same signaling as WebRTC.
  • Geo-routing can be added to DHT
@urbien urbien changed the title Hyperswarm network reliability and fallback modes Hyperswarm network reliability and fallback Sep 22, 2020
@balupton
Copy link

balupton commented Jan 14, 2021

While I am a newb when it comes to low-level p2p, I imagine that the cloudflare workers stack (workers kv for persistent, durable objects for ephemeral) could be used to facilitate a peer discovery service, and multiple workers from different accounts could sync data to facilitate a multi-owner DHT (akin to bittorrent trackers, or scuttlebutt pubs), which could use some form of cryptography to verify what the worker says who is who is actually who is who. Such operating on the edge with cloudflare power would solve a lot of the current performance issues with DHT technology. So clients could specify several of these worker locations to replace the oldschool dht, or supplement it, and update their listing as time goes on.

seems zeronet are somewhat doing this:
HelloZeroNet/ZeroNet#1913 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants