Open lidel opened 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.
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:
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?
@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.
- 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/
@bertrandfalguiere Thanks for surfacing the broken link - fixed now.
Quick note based on recent discussions:
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/
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
Potential IPFS Use
Websites could announce they are available over IPFS in a way that does not require additional DNS lookups.
/ipfs/
/ipns/
Pros:
Cons:
References
Alt-Svc