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 DEC7F43B36 for ; Fri, 12 Aug 2022 17:18:55 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 6806568B8E5; Fri, 12 Aug 2022 20:18:52 +0300 (EEST) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 8A8C468B501 for ; Fri, 12 Aug 2022 20:18:45 +0300 (EEST) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id B262220009 for ; Fri, 12 Aug 2022 17:18:44 +0000 (UTC) Date: Fri, 12 Aug 2022 19:18:43 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20220812171843.GL2088045@pb2> References: <612e12d2-4df2-a2fc-5560-7acd93c2fc8f@rothenpieler.org> <20220811201834.GE2088045@pb2> <7ce22e69-d0ad-16b7-52c6-0a447ce05be2@rothenpieler.org> <20220812150517.GI2088045@pb2> MIME-Version: 1.0 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-Type: multipart/mixed; boundary="===============4505553936865143000==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============4505553936865143000== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="s6Wo+7iKhEdF4/RK" Content-Disposition: inline --s6Wo+7iKhEdF4/RK Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 12, 2022 at 07:01:49PM +0200, Nicolas George wrote: > Michael Niedermayer (12022-08-12): > > Maybe thinking about http is the wrong mindset. Maybe DNS is a better a= nalog > >=20 > > to grab data from DNS you can implement a full DNS server which recursi= vly > > resolves the request starting from the root name servers (which it need= s to have > > hardcoded in some form) But this is something no application does becau= se of > > latency and wide support of easier name resolution on platforms > >=20 > > So what one does is to connect to local of ISP DNS server which caches = results > > and does resolve from the root servers if needed (either directly or th= ough platform APIs) > > Problem with IPFS is your ISP doesnt have a IPFS server nor do you have= one > > locally normally > >=20 > > 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= understand > > what IPFS is before arguing about it > >=20 > > 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= connect > > to peers and find out which has the data.=20 > > If you start from zero (and some hardcoded peer list) that will take mo= re time > > than if there is a running node with active connections > > So for better performance we want to use a IPFS node which persists bef= ore and > > after the process with libavformat. This is the same as with a DNS serv= er. > >=20 > > I suspect IPFS provides little security against loging, > > If you run a IPFS node, others can likely find out what your node cache= d because > > 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 n= ode might > > be worse. IIUC thats like a public caching DNS server > >=20 > > the other threat of the http-ipfs gateway modifying data can possible b= e prevented > > with some effort. > > IPFS urls IIUC contain the hash from a root of a merkle tree of the dat= a 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= modify > > the data. > > again it can in principle be checked that this is all unmodifed by any = intermediate > > that makes IPFS different fron DNS and HTTP(S) which cannot be checked = =66rom the > > URL alone >=20 > All this looks a lot like =E2=80=9Cmagnet:=E2=80=9D URLs for torrents, an= d we do not > consider FFmpeg should support torrents. But the practice can make the > difference: if leeching without seeding at all is supported, then it can > make sense. >=20 > The goal that everything works out of the box is limited by the need for > safety for the user, and it is a concern for both a peer-to-peer > protocol and for an external gateway. And it is not limited to technical > security risks, it involves also legal liability: the information that > somebody accessed a resource that is considered illegal in their country > is more likely to leak. Also to consider: if FFmpeg hardcodes a default > gateway, secondary distributors might change that default into a less > trustworthy one. >=20 > The simile with DNS has a significant limitation: DNS has been here > since forever, and we can assume it is properly configured everywhere. > In fact, FFmpeg does not use DNS, it uses the libc's resolver, which > could be configured not to use DNS at all. This protocol is a newfangled > thing, so the expectation that it just works is lower. >=20 > It brings me to another point: how common is this thing? FFmpeg aims to This is easy to awnser, you can look at: google trends since 2015 when IPFS first release was worldwide https://trends.google.com/trends/explore?date=3D2015-01-01%202022-08-12&q= =3Dipfs at that timescale its popularity is going up alot over time > support all protocols used in the world, but it is not meant to be a > showcase for somebody's vanity project or some company's new commercial > product. For this issue, I think the criterion the IETF uses to consider > something a standard is a good touchstone: are there several independent > and compatible implementations already out there? gthub search for ipfs has "10,204 repository results" first hit is a "IPFS implementation in Go" 3rd is a "IPFS implementation in JavaScript" looking further i see "Python implementation of IPFS, the InterPlanetary File System. Not even re= motely done yet." further down "The Interplanetary File System (IPFS), implemented in Rust" so id say you can have an implementation of some form in every modern langu= age And i dont think removing IPFS support entirely from FFmpeg is a smart choi= ce. thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange --s6Wo+7iKhEdF4/RK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCYvaLbwAKCRBhHseHBAsP q3aOAJ9U3sBJLOTregs9GIyhcf7PVWbr0ACeIzKG4+wk4RNGM5OdX6HISMX1e1g= =9w/s -----END PGP SIGNATURE----- --s6Wo+7iKhEdF4/RK-- --===============4505553936865143000== 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". --===============4505553936865143000==--