search

ipfs / in-web-browsers

Tracking the endeavor towards getting web browsers to natively support IPFS and content-addressing
https://docs.ipfs.tech/how-to/address-ipfs-on-web/
MIT License
349 stars 29 forks source link

Document how to leverage /dnsaddr for peer/content/routing #193

Open Winterhuman opened 2 years ago

Winterhuman commented 2 years ago

Related: https://github.com/ipfs/go-ipfs/issues/3926

Browsers have a few properties that can be exploited for use by IPFS:

This puts browsers in a unique position, browsers naturally discover many websites and thus many potential bootstrap nodes just from user behaviour, I propose encouraging browsers to exploit this behaviour to benefit IPFS bootstraping. Here's an example scenario to demonstrate:

  1. A user goes to https://website.tld in their browser, this website happens to have TXT records which contain DNSAddr values.
  2. The browser has a few options:
    • Trust all - Add any DNSAddr values it finds to it's own bootstrap list.
    • Trust whitelist - Have a whitelist of popular domains whose DNSAddr values are trusted by default (likely exposed in the GUI so users can expand the list).
    • Trust user - Prompt the user, perhaps in the security padlock menu, if https://website.tld's DNSAddr values should be saved.
  3. If trusted, the browser will add the values found at _dnsaddr.website.tld to it's own bootstrap list.

This system provides resilience to bootstrap downtime and censorship by expanding the bootstrap list to include a wide selection of trusted entities, this also has the potential to reduce latency by contacting bootstraps which are geographically closer.

lidel commented 2 years ago

Bad news

Resolving TXT records does not happen in web browsers. Nor there is any API for that, even WebExtensions are lacking this capability (Firefox bug from 2018, chromium is even worse because it has no DNS API at all).

This means TXT resolution is possible only when native IPFS node/support is involved (e.g. go-ipfs, Brave). And this occurs only when a DNSLink website or a Public Gateway URL (see is-ipfs) is redirected to a local IPFS node.

Due to this, I don't think this will provide way to "passively discover bootstrappers". Instead, we are looking into saving all discovered peers across restarts – see wip work in https://github.com/ipfs/go-ipfs/pull/8856

Good news

Value added for DNSLink websites

I think that is still useful: we can leverage DNSAddr as alternative content routing method to speed up DNSLink website load times by immediatelly getting peers providing the data.

IPFS node that tries to resolve /ipns/en.wikipedia-on-ipfs.org would

  1. Resolve DNSLink TXT record with dnslink=/ipfs/{cid} (latest snapshot)
  2. Resolve DNSAddr TXT records with multiaddrs that are known to provide the content
  3. (if DNSAddr was present) attempt to preconnect to mentioned peers. if this fails, nothing happens, we just want for regular DHT lookup to finish.

Value added for services without DHT support

DNSAddr would also provide value for Services that expose Gateway, but do not announce data on DHT (such as some Pinning Services, that provide their own Gateway).

Web browser with IPFS support (Brave, ipfs-companion) could detect DNSAddr records present on their public gateway domain name, and preconnect to dnsaddr peers that provide the data, allowing for the content to load from local node just fine.

lidel commented 2 years ago

I included DNSaddr section in DNSLINK_GATEWAY.md in https://github.com/ipfs/specs/pull/283 – feedback appreciated!

Winterhuman commented 2 years ago

@lidel Assuming https://github.com/ipfs/specs/pull/296 goes through, could we potentially allow exporting TXT records as well in order to get around needing an API from the browser? That way, the TXT records can be fetched from IPFS with DNSSEC allowing the records to be authenticated

lidel commented 2 years ago

Including DNSAddr DNSSEC chain of trust proofs is a good idea. I've added below to my review:

  • Fetch DNSSEC proof for both DNSLink and DNSAddr
    • DNSAddr TXT records work the same as DNSLink ones, but for peer routing. They are optional, but their presence allows fast recovery when HTTP is down, skipping DHT lookup and opportunistically doing bitswap with trusted provider endpoint etc.