On Tue, 7 Apr 2020 17:44:07 +1200 David Phillips <[email protected]> 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
pgpEfftR1EWDi.pgp
Description: OpenPGP digital signature
