You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is there a canonical format for mapping IPFS identifiers into URLs ? We need to represent IPFS objects in applications, so that we can know to open them in IPFS (not HTTP for example), and I'd rather not reinvent the wheel or define yet another format. Naively I was using strings like: ipfs:/ipfs/Qm.... as was recommended somewhere (I can't find that reference now).
However thee strings don't work, because depending on how that hash was generated it has to be passed to a different API - for example the hash returned by JS.Block.put has to go to JS.Block.get; the hash returned by the HTTP API has to be passed to either JS.Files.get or JS.Block.get depending on the size of the file (See ipfs/js-ipfs#1049 ) Passing any of these to the wrong API generates either infinite waiting; return of 0 bytes or an exception, so it sounds like I have to encode which API in the actual URL.
Note - encoding the CID doesn't work, because the HTTP API returns the hash rather than the CID, and the Block.put returns a CID which tells you the codec is dag-cbor (which may itself be a bug) so it looks just like the correct CID for a getting a long file from files.get
I can't seem to find which of these are bugs in the code; which are bugs in the design; and which are intentionally and need kludges to work around ?
Is there a canonical format for mapping IPFS identifiers into URLs ? We need to represent IPFS objects in applications, so that we can know to open them in IPFS (not HTTP for example), and I'd rather not reinvent the wheel or define yet another format. Naively I was using strings like: ipfs:/ipfs/Qm.... as was recommended somewhere (I can't find that reference now).
However thee strings don't work, because depending on how that hash was generated it has to be passed to a different API - for example the hash returned by JS.Block.put has to go to JS.Block.get; the hash returned by the HTTP API has to be passed to either JS.Files.get or JS.Block.get depending on the size of the file (See ipfs/js-ipfs#1049 ) Passing any of these to the wrong API generates either infinite waiting; return of 0 bytes or an exception, so it sounds like I have to encode which API in the actual URL.
Note - encoding the CID doesn't work, because the HTTP API returns the hash rather than the CID, and the Block.put returns a CID which tells you the codec is dag-cbor (which may itself be a bug) so it looks just like the correct CID for a getting a long file from files.get
I can't seem to find which of these are bugs in the code; which are bugs in the design; and which are intentionally and need kludges to work around ?
Some places I've checked that don't appear have it ! JS implementation; Github/ipfs/cid; git/multiformats/multicodec;
The text was updated successfully, but these errors were encountered: