The Alpine reasoning seems flawed to me. Having a problem with the fact that a package has decided to hard code a host when the user only specified the protocol and resource (i.e. you said https://foo.jpg so we’re just gonna pick https://rando.com/foo.jpg) is one thing. But the reasoning given for rejecting the package was that the actual host hard coded may become malicious at some unspecified point in the future. The same could be said about literally any HTTPS endpoint anywhere.
IPFS is a content distribution platform, so there’s going to be content that the “media mafia” doesn’t like (just like torrents). ffmpeg is a tool for consuming such content. If you have a (silent) hardcoded gateway/proxy for IPFS within ffmpeg, and IPFS takes off as the next torrent, and everyone happily uses the same proxy, it’s possible for copyright enforcement agents to silently suborn the proxy and keep it running to gather evidence.
This post starts right away with a misinformation. ipfs:// is not a scheme approved or recommended by the IPFS team. The right way to write an IPFS link is as a path eg /ipfs/hash if you insist on a URI scheme there are several proposals ie file: or dweb:
FWIW, downstreams don’t seem to be a fan of this - at least Alpine.
The Alpine reasoning seems flawed to me. Having a problem with the fact that a package has decided to hard code a host when the user only specified the protocol and resource (i.e. you said
https://foo.jpgso we’re just gonna pickhttps://rando.com/foo.jpg) is one thing. But the reasoning given for rejecting the package was that the actual host hard coded may become malicious at some unspecified point in the future. The same could be said about literally any HTTPS endpoint anywhere.IPFS is a content distribution platform, so there’s going to be content that the “media mafia” doesn’t like (just like torrents). ffmpeg is a tool for consuming such content. If you have a (silent) hardcoded gateway/proxy for IPFS within ffmpeg, and IPFS takes off as the next torrent, and everyone happily uses the same proxy, it’s possible for copyright enforcement agents to silently suborn the proxy and keep it running to gather evidence.
Given privacy problems of content addressing, having merely one party observing what you’re fetching seems like an improvement.
It should be possible to verify integrity of the received file based on ipfs’s CID, right?
This post starts right away with a misinformation. ipfs:// is not a scheme approved or recommended by the IPFS team. The right way to write an IPFS link is as a path eg /ipfs/hash if you insist on a URI scheme there are several proposals ie file: or dweb:
The post is correct: https://docs.ipfs.tech/how-to/address-ipfs-on-web/#native-urls