[pacman-dev] Fw: Pacman support for IPFS

[@RubenKelevra]

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:

ipfs::ipfs://$CID


Best regards,

Ruben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20200413/f9a30828/attachment.sig>