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

[Michael Niedermayer]

On Fri, Aug 12, 2022 at 12:03:17AM +0200, Timo Rothenpieler wrote:
> On 11.08.2022 22:18, Michael Niedermayer wrote:
> > On Thu, Aug 11, 2022 at 07:56:04PM +0200, Mark Gaiser wrote:
[...]
> > > 
> > > This is just your - valued! -  opinion, but still just 1. I insist on
> > > waiting to hear from Michael to hear a decision on this, mainly because he
> > > was quite persistent in asking for this feature to begin with.
> > 
> > Iam quite happy to leave this discussion to others, last time it was
> > just that noone seemed to care over a really long time to comment
> > now it seems everyone really cares.
> > I think its very good that people are thinking about it now, it is a
> > rather annoying situation as each option is a tradeoff which sucks in
> > some form
> > Maybe the ultimate best would be a change at the IPFS protocol level
> > so that lean light clients could securely use the protocol easily
> 
> 
> The patch wasn't on my radar at all. I had assumed it was actually
> implementing IPFS in some fashion.
> Not via an entire external http gateway. I'm a bit confused that it's its
> whole own protocol.

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

Also i hope this whole thread can stay technical because this all is a technical
problem and a technical mailing list and it should have a technical solution.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell
-------------- 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/bc0385f6/attachment.sig>