Alt-Svc (HTTP Alternative Services)

[lidel]

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

• ​tools.ietf.org/html/rfc7838
• mnot.net/blog/2016/03/09/alt-svc
• trac.torproject.org/projects/tor/ticket/21952#comment:31
• Prior Art
  • Tor Browser supports Alt-Svc
  • Brave planning to support it as well (Support alt-svc for .onion brave/brave-browser#1121)
  • Website Announcing it is Available over Tor

    $ curl -s -I -X GET https://tor.cloudflare-dns.com/ | grep -i Alt-Svc
    Alt-Svc: h2="dns4torpnlfs2ifuz2s2yf3fc7rdmsbhm6rw75euj35pac6ap25zgqad.onion:443"; ma=315360000; persist=1

[da2x]

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.

[bertrandfalguiere]

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:

[bertrandfalguiere]

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]

@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:

• initial plan: protocol-handler-api-for-browser-extensions.md
• ongoing work, summary of things that landed in 2020: https://blog.ipfs.io/2021-01-15-ipfs-and-igalia-collaborate-on-dweb-in-browsers/

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.

[bertrandfalguiere]

• ongoing work, summary of things that landed in 2020: https://blog.ipfs.io/2021-01-15-ipfs-and-igalia-collaborate-on-dweb-in-browsers/

The provided link doesn't work. Luckily there's a copy on the Wayback Machine: https://web.archive.org/web/20210115180343/https://blog.ipfs.io/2021-01-15-ipfs-and-igalia-collaborate-on-dweb-in-browsers/

[jessicaschilling]

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