[pacman-dev] Fw: Pacman support for IPFS
cyrond at gmail.com
Mon Apr 13 01:19:49 UTC 2020
On Tue, 7 Apr 2020 17:44:07 +1200
David Phillips <david at 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:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 228 bytes
Desc: OpenPGP digital signature
More information about the pacman-dev