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
345 stars 29 forks source link

Alt-Svc (HTTP Alternative Services) #144

Open lidel opened 5 years ago

lidel commented 5 years ago

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:

Cons:

References

da2x commented 5 years ago

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 commented 4 years ago

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

bertrandfalguiere commented 3 years ago

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 3 years ago

@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 https://github.com/ipfs/in-web-browsers/issues/179 is more powerful in the context of what IPFS does and that we have many gateways that could act as fallback/mirrors.

bertrandfalguiere commented 3 years ago

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 commented 3 years ago

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

lidel commented 2 years ago

Quick note based on recent discussions:

Seirdy commented 1 year ago

Also see https://github.com/dnslink-std/community/discussions/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/