ipfs/in-web-browsers

Alt-Svc (HTTP Alternative Services)

lidel opened this issue · 8 comments

lidel commented

Alt-Svc is an Internet Standard (RFC7838) which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.

TL;DR

The idea of Alt-Svc is for a website to be able to tell a client "For technical reasons you don't need to care about, please talk to me using [this other web address]."

The client optionally does so. (They don't have to.) If they do so, they do not change the address bar or give any sort of visual indication to the user.
– src

Potential IPFS Use

Websites could announce they are available over IPFS in a way that does not require additional DNS lookups.

/ipfs/

$ curl -s -I -X GET https://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq.ipfs.dweb.link/ | grep -i Alt-Svc
Alt-Svc: ipfs="bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq"; ma=315360000; persist=1

/ipns/

$ curl -s -I -X GET https://wikipedia.org/ | grep -i Alt-Sv
Alt-Svc: ipns="wikipedia.org"; ma=3600; persist=1

Pros:

  • Location bar kept intact (same Origin!)
  • Following existing standard
    • Prior Art exists, Tor Browser will use .onion address if announced by a website
  • Enables smooth upgrade from HTTP to IPFS transport
  • Can be cached HSTS-style
  • No DNS TXT lookups

Cons:

  • Location bar kept intact (needs additional indicator that IPFS was used)
  • Requires initial hit to HTTP server
  • Relies on native support in browser itself
    • There is no API for WebExtension to register itself as a handler

References

da2x commented

Ideally, ipfs would standardize on a new service identifier (h2 stands for http/2) that accepts a CID or IPNS name without requiring to specify a gateway hostname. Something like: Alt-Svc: ipns="en.wikipedia.org"; ma=864000; persist=1 and Alt-Svc: ipfs="base32-cidv1"; ma=2700; persist=1.

Browsers currently require h2 services to present a valid TLS certificate for the current origin. Standardizing a new service identifier would allow us to lift that requirement without compromising the requirements of h2 services. Content integrity in IPFS is guaranteed by the content-hash in the CID which the origin that transmits the Alt-Svc header vouches for; so we don’t need the certificate to prevent third-parties from modifying the content.

  • 👍3
bertrandfalguiere commented

Prior Art exists, Tor Browser will use .onion address if announced by a website

It's live! I just read about https://blog.torproject.org/new-release-tor-browser-95, and figured it could be a good idea to share with IPFS, then I found this issue.

In IPFS-enabled browsers, not having to download IPFS Companion, keeping the exact same user flow, and still seeing the good old www.foo.com to access a familiar website would make grand-ma using IPFS (without her ever having heard about it).
This is a major UX improvement.

IPFS crawlers/indexers could also index wikipedia.org and other Web.2 websites if they provide the header.

Location bar kept intact (needs additional indicator that IPFS was used)

Tor Browser does the thing below for onion alternatives. IPFS-enabled browsers can probably take inspiration from it:
image

  • ❤️2
bertrandfalguiere commented

Relies on native support in browser itself
There is no API for WebExtension to register itself as a handler

Is this still true in Firefox and Chrome?

lidel commented

@bertrandfalguiere there is a basic redirect-based API in Firefox, but none in Chrome yet.
Theipfs:// "work" if you have Companion in Chrome, but it relies on creative hackery that works around the lack of WebExtension API.

We collaborate with Igalia to bridge that gap in both specs and vendor implementations:

As for the usefulness of Alt-Svc, I believe #179 is more powerful in the context of what IPFS does and that we have many gateways that could act as fallback/mirrors.

  • 👍2
jessicaschilling commented

@bertrandfalguiere Thanks for surfacing the broken link - fixed now.

  • ❤️1
lidel commented

Quick note based on recent discussions:

  • Potential downside of Alt-Svc is dependency on ALPNs from IANA and being limited to protocol upgrade – no way to link to different representation/metadata (eg. "i want this as block|car|dag-json with IPLD Data Model" etc)
    • RFC6249 Metalink/HTTP: Mirrors and Hashes #179 seems to be more flexible, as it allows other relation that "duplicate but on different protocol"
Seirdy commented

Also see dnslink-std/community#2. Quoted:

SVCB DNS resource records (RRs) were introduced somewhat recently. They inform user-agents that a given resource exists at another endpoint, possibly with extra parameters. Functionality closely mirrors the Alt-Svc standard. A profile of SVCB exists in HTTPS RRs; Encrypted Client Hello and HTTP/3 are the main use-cases today.

To give IPNS-accessible services familiar names, I think SVCB is a better long-term solution than DNSLink.

A related issue for the InterPlanetary Name System is Issue 144 for the IPFS web browsers integration group; it discusses the viability of using Alt-Svc for this.

POSSE note from https://seirdy.one/notes/2022/10/25/dnslink-and-svcb-dns-resource-records/