On Thu, Aug 11, 2022 at 6:49 PM Timo Rothenpieler <t...@rothenpieler.org> wrote:
> On 11.08.2022 18:26, Mark Gaiser wrote: > > Hi all, > > > > On the IPFS side we do have a solution for that with CAR files, you can > > read more about that here [1]. > > Within the scope of this ipfs gateway protocol handler there isn't a > > solution yet to use CAR files, it is on our radar but still in the > > discussion phase. > > > > On the cURL side we had this same discussion with 2 possible solutions > [2]. > > For completeness, i'll list them here in full too: > > > > 1. An error message that gives no example but instead points the user to > > documentation on how to get it working. > > === cURL example > > $ curl ipfs://bafkreicysg23kiwv34eg2d7qweipxwosdo2py4ldv42nbauguluen5v6am > > Error: local gateway not found and/or IPFS_GATEWAY is not set > > Learn how to run one: https://docs.ipfs.tech/install/command-line/ > > === > > > > 2. An error message that makes the user aware of IPFS and provides a > > solution to get it working immediately. > > === cURL example > > $ curl ipfs://bafkreicysg23kiwv34eg2d7qweipxwosdo2py4ldv42nbauguluen5v6am > > Error: local gateway not found and/or IPFS_GATEWAY is not set. > > Try: IPFS_GATEWAY=https://ipfs.io > > or run your own: https://docs.ipfs.tech/install/command-line/ > > === > > > > Within the cURL implementation we're going for point 1. > > The same idea can very well apply to ffmpeg too. Different texts that > match > > the different context, but in the same spirit. > > > > Now ffmpeg is a bit different here. First and foremost because it > predates > > the curl. > > But also because the default fallback gateway was an explicitly requested > > feature from the ffmpeg side to give an "it always works" feeling. > > ffmpeg therefore has a fourth option: Do nothing and keep it as-is. > > I'm not sure who requested that, but I doubt "tunnel all user traffic > through some random third parties server" was the idea there. > Here's the conversation requesting this very feature: https://ffmpeg.org/pipermail/ffmpeg-devel/2022-March/293835.html > > Releases with that hardcoded server in will be in distributions for > years, potentially over a decade long. > Nobody can guarantee that it doesn't turn malicious in the future. > And nobody can fully guarantee what the owner does with all the data today. > > This is simply unacceptable and it has to be fixed ASAP. > The approach taken by this patch seems the correct way to deal with it > to me. > It prints a message informing the user on what to do, akin to what curl > seems to do. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
