Derek Buitenhuis (12022-08-11):
> I agree... we should never send a users data through *any* service they
> haven't explicitly asked for. Ever. Regardless of who runs it and who
> is deemed "trustworthy".

Absolutely. And Kieran's simile with DNS is very good. It is not just a
question of whether the gateway might turn evil, there are also concerns
of privacy.

> > The patch wasn't on my radar at all. I had assumed it was actually 
> > implementing IPFS in some fashion.
> Yes, I had assumed the same too, and thus wasn't following the sets
> at all.
> 
> As it exists right now though, I don't really see why lavf needs what
> amounts to a URL builder for a service as a "protocol" - this totally
> the wrong layer to do that at...

I also assumed it was a native implementation. If it is just a matter of
translating “ipfs://whatever” into “https://gateway/wHaTeVeR”, a perl
script in tools/ would be a reasonable expedient.

Native implementations are a huge part of what made FFmpeg great: you
build from source, without a shit-ton of extra libraries that might not
be packaged or recent enough on long-term distributions, and you get
support for most codecs, formats and protocols in the world.

Unfortunately, work on implementing native versions of codecs and
protocols seems to have gotten out of fashion.

For protocols, I can blame the lack of framework: our pedestrian
read/write blocking API is not adapted to modern protocols that require
asynchronous operation.

I had the project of building a new framework for networking and
protocols; in fact I have a large part of how I want to make it work in
the back of my mind already. But considering the shortsightedness of the
leadership of the project these days about framework that is not an
obvious incremental enhancement directly related to existing code, I do
not expect to invest more time into it any time soon. The same goes for
most API enhancement I had promised over the years. Too bad.

Regards,

-- 
  Nicolas George