use full path after protocol
jbenet opened this issue · 5 comments
we dont want people using ipfs://<hash>
-- we want people using /ipfs/<hash>
. of course, this doesn't work with how git helpers work, but see the discussion over at ipfs/kubo#1678
Since we have not yet settled on an approach there o/ (i will update here when we do), maybe for now switch to using ipfs://ipfs/<hash>
?
Sure, can do. Keep me posted :)
Basically I don't have any strong feelings about this but I'd like to be persistent with the rest. The idea was to use (just a symlink) git-remote-ipns
to support remotes like ipns://$keyHash
but that gets icky if you want to handle named records (Do you use DNS or which other system then..?).
I'm not sure why but ipfs://ipfs/$hash/repo.git
somehow raises a syntax error in me. It thinks it should be ipfs:///ipfs/$hash
(with three slahes) or the way I did it now. Coming from HTTP my brain somehow expects the resource location description to starts after the 2 slash. I hope Tim never reads this.
I tried to follow 1678 but it's a lot to go through. Personally, I might try to argue for ipfs::/ipfs/$hash/repo.git
,ipfs::/ipns/repo.git
and ipfs::/dns/ipfs.io/..
as it is semi-clear in each case that it relates to IPFS as a system.
cc @larsks as this concerns his helper, too :)
then go for fs://ipfs/<hash>/...
as that will (most likely) be the unixweb protocol scheme identifier.
but other things will use ipfs://ipfs/<hash>
. and we'll encourage people to support all
ipfs:/ipfs/<hash>
ipfs://ipfs/<hash>
ipfs:///ipfs/<hash>
Sorry for having this on the back burner for so long.
I will support ipfs:///*ipfs/<hash>/...
but need more support on this to go for git-remote-fs
as there will be a large range of other stuff to support there, at least in the future.
👍