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

[Tomas Härdin]

fre 2022-08-19 klockan 14:52 +0200 skrev Mark Gaiser:
> 
> 
> 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

Not our problem



> 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.

I'd actually argue that in that case we should link a library that
implements IPFS, not split developer effort by trying to implement it
ourselves.

> 
> 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?

A better way of handling this could be FUSE. How exactly to implement
protocol handlers at the kernel or (more likely) systemd level is a
discussion for those projects. Probably dbus shenanigans resulting in
file descriptors.

I don't hate the current gateway solution enough to want to delete it,
since its current state of not having a default gateway won't cause
unexpected security problems for users. But I also deliberately chose
not to push the patchset because I didn't like it, because the proper
solution belongs elsewhere.

/Tomas