-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CID as a Subdomain #89
Comments
Is there a broader discussion already about how to square the existing origin based browser security model with the broader IPFS vision of a decentralized web? This is a great approach in the short term but I'd like to get the ball rolling, if it isn't already, on how we're going to think about these security contexts down the road. |
@mikeal historical discussions on origin-safe addressing can be found in #6. "The four stages of the upgrade path for path addressing" from ipfs/specs#152 (comment) is a good summary of long discussion in ipfs/specs#152 that puts things in a wider context and lists some trade-offs. Subdomains are somewhere between stage 1 and 2. Looking back at that plan thru discussions we had with vendors I'd adjust If you are interested in synthesizing this in one place, there is a rough outline/draft of "Addressing on the Decentralized Web" document by Lars that I forked and started filling with my notes. Unfortunately I don't seem to have enough time/writing skills to get it where it needs to be: in Q3 want to add remainder of my updated notes and will be looking for a better champion for this document. |
@lidel Thanks! these are super helpful :) |
Happy to help you out with any context/history questions. I'm having a hard time keeping up with github notifications nowadays, so make sure to tag me whenever you expect a response from me :) |
@lgierth are you going to be in San Francisco for dweb? I'm putting together a dinner with browser vendors and I'm sure this will come up. I was just talking to Alex Russell about how they've put together a new package format for browsers that uses PKI to sign resources that are then interpreted as being from specific domains. Super interesting and relevant to the work we're doing. |
Nope unfortunately not -- there's a tight limit on how many people PL is sending and I didn't make it on the list. |
Would it be helpful to condense all the existing docs and comments out there into one comprehensive doc though, before DWeb Summit? It might not be the pinnacle of technical writing excellence, but at least less confusing. |
For reference: Of particular interest is the signed HTTP exchanges, which open the door to associating an origin with content that was not explicitly retrieved from that origin by the browser. |
@mikeal webpackage seems to be also super relevant for:
|
I'd be really interested to see a public ipfs gateway using CID as subdomain: it opens the possibility to host dapps on ipfs for wide audience (who may not have special browser extension or local ipfs node), without risking all kinds of attacks stemming from the fact that all ipfs pages are hosted from the same origin. It is exciting to see Is there any public gateway that supports that yet? Any timeline? I could certainly set up my own, but I would rather avoid that, as serving my own content from my own gateway defeats the purpose of ipfs in this case (that is to prove that the content being served can't be suddenly changed by me). |
@burdakovd AFAIK @lgierth Do you know if there will be an infra OKR for the move in Q4? or is it too soon? |
Until
|
@burdakovd fantastic! Kudos for documenting what and why at https://dapps.earth 👍 |
@ilyaigpetrov sadly no, only the first part (in subdomain) is used for sandboxing |
@lidel, well, how about httpS://<short-hash-from-ipns-hash>.box.cf-ipfs.com/<full-length-ipns-hash>. It's just the matter of collisions probability I guess. |
Collisions are not the only problem:
Note: I don't think we will need HTTPS for long CIDs in subdomains any time soon. This discussion is mostly about future-proofing subdomain spec. |
I want to try deploying such gateway with wildcard subdomains as cidv1b32 on localhost. |
Right now people implement support for subdomains at Nginx, as noted in example: if ($http_host ~ ^(.+)\.(ipfs|ipns)\.dweb\.link$) {
set $ipfspath /$2/$1;
rewrite "^(.*)$" $ipfspath$1 last;
} Next steps:
|
PSA: Native subdomain support will land in go-ipfs v0.5.0. For now, one can try 0.5.0-rc1 from here or use Docker ( https://github.com/ipfs/go-ipfs/blob/master/docs/config.md#gateway-recipes provides one-line example how to enable subdomain gateway on specific host (here: $ ipfs config --json Gateway.PublicGateways '{
"dweb.link": {
"UseSubdomains": true,
"Paths": ["/ipfs", "/ipns"]
}
}' IPFS Companion v2.11.0 already supports this type of a gateway and redirects it to a local one. |
go-ipfs 0.5.0 shipped with native support for subdomain gateways on hostnames defined in Daemon configuration for hosting a public gateway can be found at:
|
I hoped to punt the problem of labls longer than 63 until we need to switch away from sha256 in CIDs, but we may need to solve this problem sooner than expected due to ED25519 keys being new default soon. Subdomain support for CIDs longer than 63 is tracked in: ipfs/kubo#7318 |
Base32-encoded CIDv1 can be used in DNS subdomains. It requires additional setup server-side, but enables people to get a valid origin-based security perimeter for free.
This is a meta issue for tracking related notes and developments.
Zone Naming Convention
To make it easier for everyone, support for CID in subdomains comes with explicit zone naming convention:
Nginx config
For now, this needs to be handled by reverse proxy.
An example of subdomain config for gateway at
dweb.link
:Native config (go-ipfs >0.5.0)
Native support for CID in
Host
header ship with go-ipfs 0.5.0 and later.It removes the need for Nginx config mentioned above, and can be enabled with this one-liner (
dweb.link
is the domain that should support$cid.ipfs.dweb.link
):Length Limits
Subdomain needs to comply with length limits from RFC 1034:
CIDv1(sha-256) in Base32 fits, but hashes with longer outputs can't be used as a single label.
Update: Potential solutions are discussed in:
ipfs/kubo#7318
The text was updated successfully, but these errors were encountered: