This should really just be a new URL scheme

[stuartpb]

Since by definition this isn't going to work with conventional host-oriented protocols such as HTTP, this should really just be something like ipfsh: for "IPFS by hash". See also: magnet (which is really what protocols doing hashed P2P should use).

[kyledrake]

@stuartpb the purpose of this is to be able to use it with subdomains. Example: ciqh7a5rmv77d7ctxew4dakiuhlf37bnjmp2hvtxfbfn3uqacjwza2i.neocities.org.

I can't use magnets because they don't conform to standards for subdomains. With IPFS unixfs objects, this allows you to attach an immutable hash to a static web site that will work with the domain security model browsers support.

I realize this is pretty special purpose, but I need -something- in order to allow my users to be able to view archives of their sites from our IPFS node.

[kyledrake]

Also, a magnet link doesn't give us anything here. IPFS knows how to find the data from a hash, it doesn't need anything else. It's not necessary to give it any more information than that.

[jbenet]

@stuartpb i am (currently) opposed to using the protocol scheme identifier because it breaks compatibility with unix paths. an ipfs path (uri) is self describing in the same way a regular http url (uri) is:

# http
https://github.com/neocities/hshca/issues/2

# ipfs 
/ipfs/Qmad6ntcNzeSy7QGZ7BVLgeBs4DssanposTpx23dirTJQv/hshca/issues/2

# ipns
/ipns/QmSiwkUbM8GaMUHYCCezUKMavjFcUyF3Lmay9vEfLzAsVK/hshca/issues/2

# ipns + dns
/ipns/github.com/hshca/issues/2

but the difference is that paths also work in unix, where protocol-scheme URLs do not.