On Tue, 7 Apr 2020 17:44:07 +1200 David Phillips <david@sighup.nz> wrote:
On Sun, Apr 05, 2020 at 01:38:43PM +0200, Robin Broda wrote:
If the database gets extended by an additional field for every new network layer people come up with, where do we draw the line?
This needs a solution that does not require the database format to be altered to suit protocol-specific metadata.
This was the first point that stood out to me, too.
Can IPFS IDs have some representation as a URI? I'm spitballing here, but I'd far rather see e.g. the existing %FILENAME% registry extended to support some format like ipfs://baBbysFirStIPFScOmMitId;foo=bar That still feels a little shoehorn-y to me, but more comfortable than buying a new shoe for each new storage protocol supported in future (magnet anyone? ;)).
Sorry, the mail slipped by - or I had answered sooner. Yes, that's possible. The url is indeed ipfs://$CID If you got the browser-plugin installed for IPFS, those links will be automatically converted to something browser can understand, like http://127.0.0.1:8080/ipfs/$CID which then requests the file from the local http-gateway of the ipfs-node. If you have Opera for Android (which got build in IPFS-Support) those ipfs://$CID links will natively work. Maybe we could define something like the DLAGENTS in PKGBUILDS, this would allow to extend the field in the future: ipfs::ipfs://$CID Best regards, Ruben