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

[Mark Gaiser]

On Fri, Aug 19, 2022 at 11:15 AM Tomas Härdin <tjoppen at acc.umu.se> wrote:

> tor 2022-08-18 klockan 16:31 +0200 skrev Michael Niedermayer:
> > On Wed, Aug 17, 2022 at 05:03:56PM +0200, Tomas Härdin wrote:
> > > tor 2022-08-11 klockan 19:35 +0200 skrev Timo Rothenpieler:
> > > > On 11.08.2022 19:21, Mark Gaiser wrote:
> > > > >
> > > > > Here's the conversation requesting this very feature:
> > > > > https://ffmpeg.org/pipermail/ffmpeg-devel/2022-March/293835.html
> > > >
> > > > I generally agree with the points brought up there.
> > > > But my conclusion very much is not "just put a somewhat random
> > > > default
> > > > into the code".
> > > > Even a list of defaults is not Okay.
> > > > We can't hardcode "magic servers".
> > > >
> > > > If it's not possible to make the protocol work without them, it
> > > > likely
> > > > shouldn't have been merged in the first place.
> > > > Why can't it access the files directly, but only via some magic
> > > > http
> > > > gateway?
> > > > Why does it need special code in ffmpeg in the first place, if
> > > > you
> > > > can
> > > > just access it via that http proxy-gateway anyway?
> > >
> > > I raised this very point several times when IPFS support was first
> > > suggested, and raised that ipfsgateway.c amounts to business logic
> > > that
> > > does not belong in lavf. I see now hat others in this thread, like
> > > Derek, agree with me on this, which is nice. IIRC I even suggested
> > > that
> > > users should solve this in bash, a suggestion that was shouted down
> > > as
> > > being "insecure".
> >
> > you cannot do it in bash
>
> Is bash not Turing complete?
>

I believe we went over this in detail during those patch rounds when this
was brought up (by you?).
I didn't go back in the archives to find it, but some reasons that come to
mind:
- just handing the mere edge cases would make that bash script complex
- potentially involving regex
- add in gateway detection logic and you'll have a bash script that's
likely more complex than the current ipfsgateway.c code.
- not cross platform by any means

This would require the manual step of installing such a script to get
"ffplay ipfs://<cid>" to work.
Worst of all, it would not be usable for applications building on top of
ffmpeg (vlc, mpv, kodi) and would not be cross platform at all.


> > filter="ipfs://..."
> > on the command line is translated or not ?
> > if its drawtext showing the user on screen a URL it must not be
> > OTOH if the filter reads from the URL it has to be
> > this just isnt going to work at the bash command line level besides
> > bash is
> > not even a dependancy of FFmpeg
> > not to mention that a ipfs:// link from one container to another
> > container
> > would never show up on the command line
>
> The point is that this is business logic that belongs elsewhere.
>
> > >
> > > I also suggested we should actually implement ipfs or link to a
> > > library
> > > that implements it rather than shoving more string mangling crap
> > > into
> >
> > for reference, mark replied in that thread:
> >
> >     A "proper" implementation is unfeasible for ffmpeg purposes
> > because a
> >     proper implementation would act as an IPFS node.
> >     That means it would:
> >     - spin up
> >     - do it's bootstrapping
> >     - connect to nodes and find new nodes to connect to
> >     - find the CID on the network
> >     - etc...
> >
> >     This all adds a lot of startup time making it very unfriendly to
> > users.
> >     In this scenario it could take up to minutes before your video
> > starts
> >     playing if it doesn't time out.
>
> Yes that is what implementing ipfs: entails. But ipfsgateway.c is not
> actually ipfs: now is it? This would be like gopher.c using overbite as
> a gateway instead of actually implementing gopher:
>
> We don't need to shovel everything into this project. We can actually
> rely on users being smart. For example vlc could do the business logic
> of dealing with IPFS. Or, better yet, the OS.
>

.. we should probably fork this out into its own thread, but i do like to
have this discussion! ..

What you describe here is an opinion I hear all too often. 9 out of 10
times the gut reaction for "implementing IPFS support" is any of the above
suggestions you make.
Very understandable for someone with technical skills and just a surface
level overview of what ipfs support means.
Heck, I too would give that response and thought that way when I just
discovered IPFS!

But when you dive deep into this you'll find out that there are no easy
solutions.
Bear in mind, any solution where you'd need an ipfs implementation like
ffmpeg has now in each application is just not scalable. I wanted to add
IPFS support in ffmpeg because it allows for far easier IPFS usage in
anything that uses IPFS.
But is that ideal? Depends on the alternatives. Is it the best achievable
at the moment? Probably yes.

I don't understand the argument of "ipfsgateway.c amounts to business logic
that does not belong in lavf". Earlier arguments in this very same thread
argues for far more "full" ipfs support, isn't that contradicting? How can
a "full implementation" then ever be acceptable with that same reasoning? I
honestly don't get that so please do educate me in this regard.

For the sake of the argument and because I'm really curious to know too.
Say we want to go for OS level support of IPFS. Just in the mindset of the
meaning of "OS level" gives the impression that it would magically make
IPFS work everywhere on the OS. Say, again for the sake of the argument,
that actual OS level IPFS support does that magical behavior! Sweet! I want
it! How?
- Can it be mounted as special directories? Say for example on /ipfs and
/ipns.. Yes! But that makes this a linux specific support that won't work
for windows. Which means this option isn't ideal.
- Can there be a global ipfs:// and ipns:// protocol handler? If that even
exists, thathandler would do "something".. how would that be supported
across different applications? Say chrome, file browser and ipfs to name a
few. Or would that magical handler just return a file descriptor where
every application is supposed to be able to use file descriptors?
- Any more OS level alternatives?

Do keep the discussion for this going (perhaps in a new thread)! This is
really interesting stuff that could very well influence a path forward.
Provided that there is a credible cross platform way.


>
> /Tomas
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>