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 C01C143DE7 for ; Fri, 12 Aug 2022 15:05:28 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 3F66268B8D2; Fri, 12 Aug 2022 18:05:25 +0300 (EEST) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 602FC68B757 for ; Fri, 12 Aug 2022 18:05:19 +0300 (EEST) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id 612C3240005 for ; Fri, 12 Aug 2022 15:05:17 +0000 (UTC) Date: Fri, 12 Aug 2022 17:05:17 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20220812150517.GI2088045@pb2> References: <20220810222708.186270-1-derek.buitenhuis@gmail.com> <612e12d2-4df2-a2fc-5560-7acd93c2fc8f@rothenpieler.org> <20220811201834.GE2088045@pb2> <7ce22e69-d0ad-16b7-52c6-0a447ce05be2@rothenpieler.org> MIME-Version: 1.0 In-Reply-To: <7ce22e69-d0ad-16b7-52c6-0a447ce05be2@rothenpieler.org> 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-Type: multipart/mixed; boundary="===============0356174248636856286==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============0356174248636856286== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cvGDtX8LmIpY177y" Content-Disposition: inline --cvGDtX8LmIpY177y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 12, 2022 at 12:03:17AM +0200, Timo Rothenpieler wrote: > On 11.08.2022 22:18, Michael Niedermayer wrote: > > On Thu, Aug 11, 2022 at 07:56:04PM +0200, Mark Gaiser wrote: [...] > > >=20 > > > This is just your - valued! - opinion, but still just 1. I insist on > > > waiting to hear from Michael to hear a decision on this, mainly becau= se he > > > was quite persistent in asking for this feature to begin with. > >=20 > > Iam quite happy to leave this discussion to others, last time it was > > just that noone seemed to care over a really long time to comment > > now it seems everyone really cares. > > I think its very good that people are thinking about it now, it is a > > rather annoying situation as each option is a tradeoff which sucks in > > some form > > Maybe the ultimate best would be a change at the IPFS protocol level > > so that lean light clients could securely use the protocol easily >=20 >=20 > The patch wasn't on my radar at all. I had assumed it was actually > implementing IPFS in some fashion. > Not via an entire external http gateway. I'm a bit confused that it's its > whole own protocol. Maybe thinking about http is the wrong mindset. Maybe DNS is a better analog to grab data from DNS you can implement a full DNS server which recursivly resolves the request starting from the root name servers (which it needs to= have hardcoded in some form) But this is something no application does because of latency and wide support of easier name resolution on platforms So what one does is to connect to local of ISP DNS server which caches resu= lts and does resolve from the root servers if needed (either directly or though= platform APIs) Problem with IPFS is your ISP doesnt have a IPFS server nor do you have one locally normally Below is how i understand IPFS, please someone correct me if iam wrong, iam= =20 listing this here as i think it makes sense for the dicussion to better und= erstand what IPFS is before arguing about it IPFS seems closer to DNS in how it works than to how http works if you want to grab something from IPFS it cant just do it, it needs to con= nect to peers and find out which has the data.=20 If you start from zero (and some hardcoded peer list) that will take more t= ime than if there is a running node with active connections So for better performance we want to use a IPFS node which persists before = and after the process with libavformat. This is the same as with a DNS server. I suspect IPFS provides little security against loging, If you run a IPFS node, others can likely find out what your node cached be= cause thats the whole point, of caching data, so that others can get it. If you are concerned the http-ipfs gateway logs you, running your own node = might be worse. IIUC thats like a public caching DNS server the other threat of the http-ipfs gateway modifying data can possible be pr= evented with some effort. IPFS urls IIUC contain the hash from a root of a merkle tree of the data so= one=20 can take a subset of the data with some more hashes and verify that the data matcheswhat the URL refers to. This also makes data immutable. There is mutable data in IPFS called IPNS. IPNS uses a hash of a public key allowing the private key owner only to mod= ify the data. again it can in principle be checked that this is all unmodifed by any inte= rmediate that makes IPFS different fron DNS and HTTP(S) which cannot be checked from= the URL alone Also i hope this whole thread can stay technical because this all is a tech= nical problem and a technical mailing list and it should have a technical solutio= n. thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell --cvGDtX8LmIpY177y Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCYvZsKQAKCRBhHseHBAsP q8w+AJ4+h+z3lbhtpHWeCWgT7GOqrWAZYgCcC76Rome7jCQzdVAtHIKrxzxvjH0= =Tm1T -----END PGP SIGNATURE----- --cvGDtX8LmIpY177y-- --===============0356174248636856286== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============0356174248636856286==--