From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 177CB40F6C for ; Thu, 11 Aug 2022 17:35:44 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 731A768B93D; Thu, 11 Aug 2022 20:35:41 +0300 (EEST) Received: from btbn.de (btbn.de [136.243.74.85]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 9CA5368B915 for ; Thu, 11 Aug 2022 20:35:35 +0300 (EEST) Received: from [authenticated] by btbn.de (Postfix) with ESMTPSA id 3C519365C33 for ; Thu, 11 Aug 2022 19:35:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rothenpieler.org; s=mail; t=1660239335; bh=4OWBkrXU6nplcfIN5ZvK7FCgHsLx5XNr6pjpi72BhME=; h=Date:Subject:To:References:From:In-Reply-To; b=hrhENoWrUklUQh1rU6Zhe8EhFIxMmZ//debwiNA15zcoWqe0UZ5MGZAdqWmy8O5Go aQsCIDU5BUJ2iBLJlKgGbY9NbIIguBaPhl6lJnCt0HUrToZ5S4ybDuQihUdlvFeHH6 vXs4EfP3g2h2RndUuQv1V+629XQEeqXsOicWHheAgHtDRkot/7SJTnqLmvCG7v61/9 nSn5W45ICEV0xwLpGrxmSyd2G8Eu1ojFU1BXm4afn5S+jND9L083BQWRqGTSeCuP6u pYf1cIZrOU29gk2Q9aDXMOck0UXV3H3kvFmyitfbtCu/yLSEIhR0rBoyGcswzg39jV 6VUAydqpeBJRQ== Message-ID: Date: Thu, 11 Aug 2022 19:35:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.1.2 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20220810222708.186270-1-derek.buitenhuis@gmail.com> <612e12d2-4df2-a2fc-5560-7acd93c2fc8f@rothenpieler.org> From: Timo Rothenpieler In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 11.08.2022 19:21, Mark Gaiser wrote: > On Thu, Aug 11, 2022 at 6:49 PM Timo Rothenpieler > 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 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? _______________________________________________ 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".