| Message ID | 20220131135116.14035-1-markg85@gmail.com |
|---|---|
| Headers | show |
| Series | Add IPFS and IPNS protocol support | expand |
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. /Tomas
On Mon, Jan 31, 2022 at 4:52 PM Tomas Härdin <tjoppen@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. Question though. In a V2 patch, would it make sense to squash everything in one commit? It's not that much anyhow. I have a feeling the current spliced patches give much appreciated feedback but also on parts that a later commit removed :) > > /Tomas > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >
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@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 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 > > Question though. In a V2 patch, would it make sense to squash > everything in > one commit? Just look at what other patch series look like. This is small enough that a single patch is likely enough yes /Tomas
On Mon, Jan 31, 2022 at 9:23 PM Tomas Härdin <tjoppen@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@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 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. Rather, the gateway approach uses an already running IPFS instance. Users are meant to run a local IPFS instance but it doesn't *have* to be local. Sure, a user could point it to another local network hosted IPFS node or some online public gateway. But the idea is for users to host a node themselves. > > 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). > > > > > Question though. In a V2 patch, would it make sense to squash > > everything in > > one commit? > > Just look at what other patch series look like. This is small enough > that a single patch is likely enough yes > > /Tomas > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >
On Mon, Jan 31, 2022 at 09:22:52PM +0100, Tomas Härdin wrote: [...] > 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 sounds like a security nightmare the ffmpeg command line is complex, there are filters, strings for thinsg like drawtext, there is metadata possibly and links can occur at different places some of this may be controlled by a user (= attacker) seperating the actual links out to modify them and just them is no easy feat thx [...]
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@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@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
tis 2022-02-01 klockan 11:06 +0100 skrev Michael Niedermayer: > On Mon, Jan 31, 2022 at 09:22:52PM +0100, Tomas Härdin wrote: > [...] > > 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 sounds like a security nightmare Parsing shit in C is a far bigger nightmare I can assure you. The command line can leverage sed and the regex in the URL RFC. /Tomas
On Tue, Feb 1, 2022 at 5:40 PM Tomas Härdin <tjoppen@acc.umu.se> wrote: > 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@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@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? > I don't entirely agree that this logic should live in kodi. I think ffmpeg should provide the base essentials (which this patch is doing). Kodi and other applications should then provide an input field or whatever to potentially say "i know the gateway you need to use, pick this one". They would then either pass "-gateway <url>" with the setting they deem correct or by filling in the $IPFS_GATEWAY environment variable. Kodi currently has no way to play IPFS data. Unless one goes through the hassle of translating it manually to a gateway url. To give you an idea of how it looks. Kodi has so called strm (stream) files. They can contain an url that can be played. Without this patch an ipfs file would look like this: http://localhost:8080/ipfs/QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T With this patch it becomes possible to patch kodi to accept: ipfs://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T In the former case it's gateway specific. In the latter case it's gateway agnostic. The gateway specific way has a problem. If i translate it to a gateway then that url i picked becomes the point to access the file. If that url goes down, the file isn't playable. Even if the file might still be online just fine on the IPFS network. Imagine you get a file from me and have ipfs running locally. I'm guessing you don't like to edit the file you received to fix the gateway part of the url, do you? I certainly don't. The idea here is that a user sets the gateway that needs to be used to play. The ideal place to do that is ffmpeg because the gateway logic can then be in one application. Others (kodi, vlc, ...) can either rely on ffmpeg doing the right thing or overrule the gateway with their own setting. In either case, ffmpeg needs the option to set the gateway. This all changes if the logic can't go in ffmpeg. Then each application gets its own configuration to set the ipfs gateway. That's a situation I actively try to prevent because it makes accessing files on ipfs just more complicated then need be. Also, please forget the systemd and linux specifics here. ffmpeg isn't linux only neither is ipfs. Anyhow, V2 of this patch series will be here shortly. > Come to think of it, why aren't URLs openable as files on Linux? > > /Tomas > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >
tis 2022-02-01 klockan 22:18 +0100 skrev Mark Gaiser: > > To give you an idea of how it looks. Kodi has so called strm (stream) > files. They can contain an url that can be played. > > Without this patch an ipfs file would look like this: > > http://localhost:8080/ipfs/QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T > > With this patch it becomes possible to patch kodi to accept: > ipfs://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T > > In the former case it's gateway specific. In the latter case it's > gateway > agnostic. > > The gateway specific way has a problem. If i translate it to a > gateway then > that url i picked becomes the point to access the file. > If that url goes down, the file isn't playable. Even if the file > might > still be online just fine on the IPFS network. > Imagine you get a file from me and have ipfs running locally. I'm > guessing > you don't like to edit the file you received to fix the gateway part > of the > url, do you? I certainly don't. You translate the URLs on the fly of course, and don't store the translated URLs in the strm. I can almost guarantee you you will need to do this inside Kodi anyway. What if you want to play a playlist stored in IPFS? /Tomas
On Wed, Feb 2, 2022 at 1:52 PM Tomas Härdin <tjoppen@acc.umu.se> wrote: > tis 2022-02-01 klockan 22:18 +0100 skrev Mark Gaiser: > > > > To give you an idea of how it looks. Kodi has so called strm (stream) > > files. They can contain an url that can be played. > > > > Without this patch an ipfs file would look like this: > > > > > http://localhost:8080/ipfs/QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T > > > > With this patch it becomes possible to patch kodi to accept: > > ipfs://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T > > > > In the former case it's gateway specific. In the latter case it's > > gateway > > agnostic. > > > > The gateway specific way has a problem. If i translate it to a > > gateway then > > that url i picked becomes the point to access the file. > > If that url goes down, the file isn't playable. Even if the file > > might > > still be online just fine on the IPFS network. > > Imagine you get a file from me and have ipfs running locally. I'm > > guessing > > you don't like to edit the file you received to fix the gateway part > > of the > > url, do you? I certainly don't. > > You translate the URLs on the fly of course, and don't store the > translated URLs in the strm. I can almost guarantee you you will need > to do this inside Kodi anyway. What if you want to play a playlist > stored in IPFS? > I can guarantee Kodi won't need to do that translation if it's in ffmpeg. This is because kodi passes media on to ffmpeg. If ipfs and ipns are in it's whitelisted protocols then ffmpeg is relied upon to handle it. It's not "exactly" working like that (there are many layers there) but it's roughly how it works. We are getting out of the ffmpeg scope here, but here's how I envision it to work in kodi. I'm quite sure it's going to work this way because I'm making the patches for it :) How I envision it is as follows: 1. Kodi will, somewhere in it's settings, get an option to define an IPFS gateway. If the user specifies this, it's used. 2. ffmpeg will just honor what was set (kodi will likely pass -gateway <url>) or will try to auto detect if nothing is given. 3. strm files will be modified to work with ipfs://<cid> url's 4. playlist files. These are tricky as they are not specific to kodi. I will TRY to let those work if they contain ipfs://<cid> The playlist case is a bit tricky as m3u8 (i assume you mean that) isn't a kodi specific thing. strm is. The eventual endgoal with regards to kodi is for ipfs:// to be a first-class citizen and to just work. But there are lots of places in kodi that i'll need to adjust for that to become a reality. The first step is to get it working in the strm file and I'll go from there. > > /Tomas > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >
On Tue, Feb 01, 2022 at 05:43:24PM +0100, Tomas Härdin wrote: > tis 2022-02-01 klockan 11:06 +0100 skrev Michael Niedermayer: > > On Mon, Jan 31, 2022 at 09:22:52PM +0100, Tomas Härdin wrote: > > [...] > > > 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 sounds like a security nightmare > > Parsing shit in C is a far bigger nightmare I can assure you. The > command line can leverage sed and the regex in the URL RFC. the problem is if you parse it on the command line and change it before passing it to ffmpeg. You really need to have ffmpeg and the command line parse it 100% exactly the same. If theres a difference you can introduce security issues. because things in the commend line that are not intended to be changed by an attacker could become changeable by parser differences, this involves also issues with artgument seperators being parsed or not parsed as urls for example a filter argument could be a URL or it could be a generic string the command line wraper would have to know this difference. metadata and drawtext will behave interresting if they display ipfs: and keep in mind on top here the : is a argument seperator for filters so a real url ipfs link as filter argument would have the : escaped in some way. The command line tool would need to fully handle all escaping and unescping we use in every argument and it would need to have a list of what holds an url and what doesnt. Noone will implement this in a 100% correct form with sed and regex anyone trying will long before run naked through the streets and flap her/his hands as if (s)he is a chicken feel free to proof me wrong of course thx [...]
ons 2022-02-02 klockan 14:48 +0100 skrev Michael Niedermayer: > On Tue, Feb 01, 2022 at 05:43:24PM +0100, Tomas Härdin wrote: > > tis 2022-02-01 klockan 11:06 +0100 skrev Michael Niedermayer: > > > On Mon, Jan 31, 2022 at 09:22:52PM +0100, Tomas Härdin wrote: > > > [...] > > > > 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 sounds like a security nightmare > > > > Parsing shit in C is a far bigger nightmare I can assure you. The > > command line can leverage sed and the regex in the URL RFC. > > the problem is if you parse it on the command line and change it > before passing it to ffmpeg. You really need to have ffmpeg and > the command line parse it 100% exactly the same. The word you're looking for is langsec. It is why I harp on about being very strict with what we accept. /Tomas