[FFmpeg-devel] [PATCH 0/5] Add IPFS and IPNS protocol support

[Tomas Härdin]

mån 2022-01-31 klockan 23:00 +0100 skrev Mark Gaiser:
> On Mon, Jan 31, 2022 at 9:23 PM Tomas Härdin <tjoppen at acc.umu.se>
> wrote:
> 
> > mån 2022-01-31 klockan 17:31 +0100 skrev Mark Gaiser:
> > > On Mon, Jan 31, 2022 at 4:52 PM Tomas Härdin <tjoppen at acc.umu.se>
> > > wrote:
> > > 
> > > > mån 2022-01-31 klockan 14:51 +0100 skrev Mark Gaiser:
> > > > > 
> > > > > There are multiple ways to access files on the IPFS network.
> > > > > This
> > > > > patch series
> > > > > uses the gateway driven way. An IPFS node - by default -
> > > > > exposes
> > > > > a
> > > > > local
> > > > > gateway (say http://localhost:8080) which is then used to get
> > > > > content
> > > > > from IPFS.
> > > > 
> > > > 
> > > > Perhaps the protocol should be called something other than just
> > > > ipfs if
> > > > it doesn't actually implement IPFS. Like ipfsgateway. It could
> > > > still be
> > > > registered to ipfs:// of course, until someone writes a wrapper
> > > > for
> > > > libipfs.
> > > > 
> > > 
> > > Do you mean to have it named like "ipfsgateway" as files (and
> > > library) but
> > > keep the protocol registration of ipfs and ipns?
> > > I'm fine with that. The name is only artificial in code anyhow,
> > > all
> > > that
> > > matters are the protocol names.
> > 
> > What I'm really after is if other devs think there might be an
> > issue
> > once someone goes an implements proper IPFS support
> > 
> 
> 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 sounds similar to Tor, except Tor has a much more elegant way of
dealing with this stuff by just wrapping ffmpeg with torify. It takes
care of all the IPC stuff with tor.service

> > 
> > It strikes me that this borders on incorporating business logic
> > within
> > lavf. A user could achieve the same thing with a small shell
> > script.
> > For example adding an alias that inspects calls to ffmpeg and sed:s
> > ipfs:// URLs accordingly
> > 
> 
> That might work but isn't really user friendly. It also doesn't help
> for
> tools/applications that incorporate ffmpeg to potentially use IPFS
> resources.
> KODI (when IPFS is merged into ffmpeg) is one such application where
> I'll
> be adding support for IPFS.
> But there are more that could potentially benefit. Think for example
> of OBS
> studio and blender (i haven't been in contact with them, all i know
> is that
> they use ffmpeg).

This sounds like business logic that should live in Kodi, OBS and
Blender respectively. Or better yet, in the operating system itself
(read: systemd). How does Kodi handle browsing media stored in IPFS in
this case? Does it not already have to be IPFS aware for this to work
reasonably well?

Come to think of it, why aren't URLs openable as files on Linux?

/Tomas