Setup hash subdomain proxying

[yuvadm]

It could be awesome if we had a cluster that proxied <hash>.gateway.ipfs.io to gateway.ipfs.io/ipfs/<hash>

This is useful for many different cases:

• DNS CNAME records
• root relative links
• secure content isolation

(see https://github.com/neocities/hshca/)

[whyrusleeping]

@kyledrake you do this, right?

[kyledrake]

Yes, hshca was used to implement the IPFS archive viewer.

I whipped together a very primitive proxy that's doing the work of translating: https://github.com/neocities/hshca-proxy

[jbenet]

I think this would be a nice to have for infra in the near future. we may not have bandwidth for it atm. but of course, PRs accepted.

[davidar]

A little tangential, but another thing that I thought would be a good way to drive adoption, is to make a webhook for github pages that publishes the site to ipfs and makes it available under <github-username>.github.ipfs.io

[jbenet]

@davidar that would be great!

[jeluard]

@eefahy Can you detail what ready means here? Is this available? :)

[eefahy]

Hi @jeluard - the ready tag came from us moving this issue onto a ready column on our issue mgmt system. It's not ready in the sense that it's available (yet)

[jakubgs]

At Status we are currently using a Lua b32tob58.lua script with Nginx to create an IPFS proxy that changes base32 domains names into base58 paths.
Here is an example Nginx config:

server {
    listen 443 ssl;
    # This regex allows us to detect which sub domain was used
    server_name ~^(?<domain_hash>\w+).ipfs.example.org;
    # SSL certs ommitted
    location / {
        # Rewrite to proxy to Infura IPFS by converting
        # base32 hash to a base58 hash for /ipfs/ path
        rewrite_by_lua_file /etc/nginx/b32tob58.lua;
        # proxy the request to Infura
        proxy_pass https://ipfs.infura.io;
        proxy_redirect off;
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

Might help you do something similar.

[mburns]

Hi all! I'm on the Infra team and help run the ipfs gateways and would like to move this ticket forward. There are a couple of prerequisites but it is something I'd like to see happen in the reasonably near future.

First and foremost, there are security concerns around user-published content in arbitrary subdomains for something like *.ipfs.io, which has other, non-gateway uses, unfortunately. Thankfully, we have dweb.link for just such a thing.

• Add dweb.link to the Public Suffix list, for cookie/etc security isolation. pending PR
• ipfs base32 migration. This is tracked at various levels for various sub-tasks, but eliminates the required hshca (b32tob58.lua) or translation step
• add relevant rewrite/redirect rules

[lidel]

I believe a proxy aware of subdomain transformation would remove the need for 32tob58.lua:
ipfs/kubo#5982 (go-ipfs as HTTP PROXY for http://<cidv1b32>.ipfs.localhost)
(cc https://github.com/ipfs/ipfs/issues/337)

[ghost]

* add relevant rewrite/redirect rules

Might make sense to have the ipfs.io -> *.dweb.link redirects only for browsers -- the security concern only applies in browsers, and other clients (tools, automated things, apps) will likely not expect or deal with redirects.

[lidel]

For anyone randomly finding this issue:
upstream support for subdomain gateways in go-ipfs is tracked in ipfs/kubo#6498

[mburns]

With upstream support, I've been able to roll this change out to the production Gateways. go-ipfs will handle the base conversion, nginx is just acting as a simple reverse proxy.

e.g. https://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq.ipfs.dweb.link/wiki/Vincent_van_Gogh.html