#ipfs

/

      • lidel
        Unless you find someone with deep knowledge about Firefox and XUL internals, it may not be cost-effective to learn deprecated ecosystem
      • lgierth
        yeah
      • let me test your fs: faking code a bit more
      • about fs: faking not working with /ipns, is that just that some regexp doesn't include ipns, or does it hint at a proper bug?
      • lidel
        lgierth, I think ipns was disabled on purpose
      • let me check
      • lgierth, i think I got it: fs:/ipns/ipfs.git.sexy does not work but fs:/ipns/ipfs.git.sexy/ works, right? this is a bug reported at: https://github.com/lidel/ipfs-firefox-addon/iss... and recently picked up by flyingzumwalt at https://github.com/ipfs/in-web-browsers/issues/8
      • :)
      • in short, gateway makes redirect to a parth with / at the end, if you did not had one
      • *path
      • lgierth
        ah. aah!
      • lidel
        ok, its 1:18AM here, time for me to get some shut eye ;) good luck!
      • lgierth
        lidel: thanks so much -- good night
      • lidel
        lgierth, btw, The_8472 is here, he wrote most of this fs: code, and has more experience with legacy XUL than I do ;)
      • anyway, cheers
      • MikeFair
        lgierth: I was wondering if for the protocol handlers; fs://SomeHash/ could act as a base rooting id (probably out of the ipns namespace)
      • dimitarvp has quit
      • ipns://SomeHash/ perhaps
      • lgierth
        yeah that would be the second solution (which would definitely work), ipfs://$base32hash/some/path and ipns://same
      • the reconstruct the actual path before speaking to the ipfs api
      • *then
      • MikeFair nods.
      • it's problematic because it rips the path apart, and a user can't easily copy-paste the hash from the path
      • (because base32)
      • it'd work though. (although the option which keeps the path intact is ideal)
      • MikeFair
        I know it might ruffle some feathers; but what if the other tools were taught URL speak
      • lgierth
        yeah i could definitely live with it
      • MikeFair
        why does /ipns/hash have to be the way you copy paste? why not ipns://hash
      • lgierth
        and you can also have ipfs emit base32 CIDs, we're about to flip over the default there anyhow
      • hostnames are case-insenstive
      • MikeFair
        right
      • lgierth
        so it has to be base16 or base32
      • MikeFair
        what's the actual byte length again?
      • lgierth
        whyrusleeping: this just occured to me ^ if we have to go with ipfs://$base32hash/some/path for web browsers, that might have implications on the CIDs ipfs emits
      • whyrusleeping
        lgierth: we shouldnt have to switch to base32 in the urls
      • lgierth
        whyrusleeping: it might be useful to just emit hostname-safe CIDs by default (i.e. base32)
      • whyrusleeping
        just for the suborigin stuff
      • we can convert b58 to b16 or 32 on the fly
      • MikeFair
        For some reason my gut raction really likes base16 (I think it just speaks to the "easy to see/convert to the numeric bytes" in me)
      • lgierth
        yes, but that has severe UX implications imho -- a user can't easily make an ipfs://$base32 url out of a regular fs path
      • MikeFair
        A user can't easily make a hash path "."
      • lgierth
        (i'm just trying to grasp the implications of the two options, to write it down)
      • MikeFair
        I mentally think of a hashcode as ipfs' version of an ip address
      • lgierth
        whyrusleeping: and for a base conversion we might need a CID type which "contains another CID", so we can retain type information about the original CID so that we can convert back
      • whyrusleeping
        why do we need to convert back?
      • its purely a UI thing
      • lgierth
        mh, to reconstruct the path. it's unfortunate if toPath(toUrl("/ipfs/Qmfoo")) == "/ipfs/notQmfoo"
      • it looks innocent but it will bite, promise
      • trying to retain info of the original CID has its own complications, agreed
      • the fact that ipfs://$b32hash has UX issues is a pretty good argument in making the case with browser vendors, though :)
      • matoro has quit
      • MikeFair
        lgierth: Another thing this hilites is the point being having an address translation service
      • s/being/of
      • fwiw, /ipfs/Qmfoo is really unusable to me for anything but the most basic of single use purposes
      • Just the process of republishing changes to the directory that contains my website is a fairly cumbersome one...
      • ipfs add -r /local/path/on/system; ipfs files cp /ipfs/QmAddCmd /domain.dom; ipfs files stat --hash /domain.dom; ipns name publish -k domain.dom /QmStatCmd
      • lgierth
        yes it needs better tooling
      • MikeFair
        for instance; one though I keep having is: ipfs root /ip[fn]s/QmHash
      • that then goes into a file in ~/.ipns
      • matoro joined the channel
      • and all my other commands then just prepend that hash
      • (or use it as the case may be)
      • I gues it's ipfs cd /ipfs/Qm...
      • lgierth
        yes
      • the good thing is, such as with git, it's easy to write new tools which plug the existing ones together in new ways
      • ruby-ruby has quit
      • most of the time it's as easy as a shell script -- these kinds of little tools are great for informing the ui direction
      • MikeFair
        I can't recall if you were here for the discussion where I was exploring the benefits of giving links in IPLD a "type" so that different processing could take place; but I later kind of realized what I'm talking about could be a form of | for ipfs
      • lgierth: Shell script assumes you're on an OS that has that; though I think you could safely require powershell and then just make mobile deal with an SDK/API
      • ruby-ruby joined the channel
      • lgierth
        sorry, no mental capacity right now to dive into this further
      • MikeFair
        no worries
      • n0z joined the channel
      • AphelionZ
        did y'all see the first SHA-1 collision
      • MikeFair
        We'll leave it at "I'm liking your recommendations on the file protocol stuff; and would prefer to teach the tools ip[fn]s://$base[16|32]/ then squeeze case sensitive host names" :)
      • AphelionZ: Yes, it was good, at least the first publicized anyway; and still took insane resources to produce ;)
      • AphelionZ
        makes me feel good about sha-256
      • zeus1 has quit
      • hmmm im having trouble bootstrapping peers in my js implementation
      • aquentson1 has quit
      • aquentson joined the channel
      • ianopolous joined the channel