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: [...] > > > > > > 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 because he > > > was quite persistent in asking for this feature to begin with. > > > > 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 > > > 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 results 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 listing this here as i think it makes sense for the dicussion to better understand 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 connect to peers and find out which has the data. If you start from zero (and some hardcoded peer list) that will take more time 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 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 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 prevented with some effort. IPFS urls IIUC contain the hash from a root of a merkle tree of the data so one 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 from the URL alone Also i hope this whole thread can stay technical because this all is a technical problem and a technical mailing list and it should have a technical solution. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell
signature.asc
Description: PGP signature
_______________________________________________ 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".
