[FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway

[Michael Niedermayer]

On Fri, Aug 12, 2022 at 07:01:49PM +0200, Nicolas George wrote:
> Michael Niedermayer (12022-08-12):
> > Maybe thinking about http is the wrong mindset. Maybe DNS is a better analog
> > 
> > to grab data from DNS you can implement a full DNS server which recursivly
> > resolves the request starting from the root name servers (which it needs to have
> > hardcoded in some form) But this is something no application does because of
> > latency and wide support of easier name resolution on platforms
> > 
> > So what one does is to connect to local of ISP DNS server which caches results
> > and does resolve from the root servers if needed (either directly or though platform APIs)
> > Problem with IPFS is your ISP doesnt have a IPFS server nor do you have one
> > locally normally
> > 
> > Below is how i understand IPFS, please someone correct me if iam wrong, iam 
> > listing this here as i think it makes sense for the dicussion to better understand
> > what IPFS is before arguing about it
> > 
> > IPFS seems closer to DNS in how it works than to how http works
> > if you want to grab something from IPFS it cant just do it, it needs to connect
> > to peers and find out which has the data. 
> > If you start from zero (and some hardcoded peer list) that will take more time
> > than if there is a running node with active connections
> > So for better performance we want to use a IPFS node which persists before and
> > after the process with libavformat. This is the same as with a DNS server.
> > 
> > I suspect IPFS provides little security against loging,
> > If you run a IPFS node, others can likely find out what your node cached because
> > thats the whole point, of caching data, so that others can get it.
> > If you are concerned the http-ipfs gateway logs you, running your own node might
> > be worse. IIUC thats like a public caching DNS server
> > 
> > the other threat of the http-ipfs gateway modifying data can possible be prevented
> > with some effort.
> > IPFS urls IIUC contain the hash from a root of a merkle tree of the data so one 
> > can take a subset of the data with some more hashes and verify that the data
> > matcheswhat the URL refers to. This also makes data immutable. There is
> > mutable data in IPFS called IPNS.
> > IPNS uses a hash of a public key allowing the private key owner only to modify
> > the data.
> > again it can in principle be checked that this is all unmodifed by any intermediate
> > that makes IPFS different fron DNS and HTTP(S) which cannot be checked from the
> > URL alone
> 
> All this looks a lot like “magnet:” URLs for torrents, and we do not
> consider FFmpeg should support torrents. But the practice can make the
> difference: if leeching without seeding at all is supported, then it can
> make sense.
> 
> The goal that everything works out of the box is limited by the need for
> safety for the user, and it is a concern for both a peer-to-peer
> protocol and for an external gateway. And it is not limited to technical
> security risks, it involves also legal liability: the information that
> somebody accessed a resource that is considered illegal in their country
> is more likely to leak. Also to consider: if FFmpeg hardcodes a default
> gateway, secondary distributors might change that default into a less
> trustworthy one.
> 
> The simile with DNS has a significant limitation: DNS has been here
> since forever, and we can assume it is properly configured everywhere.
> In fact, FFmpeg does not use DNS, it uses the libc's resolver, which
> could be configured not to use DNS at all. This protocol is a newfangled
> thing, so the expectation that it just works is lower.
> 

> It brings me to another point: how common is this thing? FFmpeg aims to

This is easy to awnser, you can look at: google trends since 2015 when IPFS
first release was

worldwide
https://trends.google.com/trends/explore?date=2015-01-01%202022-08-12&q=ipfs

at that timescale its popularity is going up alot over time


> support all protocols used in the world, but it is not meant to be a
> showcase for somebody's vanity project or some company's new commercial
> product. For this issue, I think the criterion the IETF uses to consider
> something a standard is a good touchstone: are there several independent
> and compatible implementations already out there?

gthub search for ipfs has "10,204 repository results"

first hit is a "IPFS implementation in Go"
3rd is a "IPFS implementation in JavaScript"
looking further i see
"Python implementation of IPFS, the InterPlanetary File System. Not even remotely done yet."
further down
"The Interplanetary File System (IPFS), implemented in Rust"

so id say you can have an implementation of some form in every modern language

And i dont think removing IPFS support entirely from FFmpeg is a smart choice.

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20220812/d07d7e60/attachment.sig>