cryptix / git-remote-ipfs

git transport helper for ipfs
MIT License
227 stars 25 forks source link

use full path after protocol #3

Closed jbenet closed 8 years ago

jbenet commented 9 years ago

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 https://github.com/ipfs/go-ipfs/issues/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> ?

cryptix commented 9 years ago

Sure, can do. Keep me posted :)

cryptix commented 8 years ago

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 :)

jbenet commented 8 years ago

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>
cryptix commented 8 years ago

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.

jbenet commented 8 years ago

:+1: