> This verifying of the content, it is done in a streaming manner, right?
Yes, buffering is up to 2MiB (depends on the blocksize used when
creating the file originally).
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
On Fri, 27 Oct 2023, Hugo Valtier via curl-library wrote:
What I'll submit will use the IPFS trustless gateway spec, so curl will receive
the IPFS data structure, hash it, validate it and deserialize it:
Hash Validated
┌─┐
│Host → Gateway → Curl│
└─┘
> my understanding was that there were two
> main ways to get files over IPFS: one is to get them via HTTP from an IPFS
> gateway that knows about IPFS (what curl does now) and the other is to become
> a
> full-fledged node in the IPFS network and speak the IPFS protocols to the
> world.
We have
On Thu, Oct 26, 2023 at 03:42:34PM +0200, Hugo Valtier via curl-library wrote:
> Instead of using the Path Gateway it uses the Trustless Gateway which
> answers with a stream of blocks and walks the merkle-tree, verifies
> hashes and deserializes it on the fly.
> This would make curl or libcurl
> I know very little about IPFS but it certainly sounds like the right way.
Good, I'll change my code to be an improvement of the existing ipfs:// feature
in the CLI and I think we can continue discussion when I have a pull request.
Thx for your time.
> Would this not rather *replace* the URL
On Thu, 26 Oct 2023, Hugo Valtier via curl-library wrote:
This would make curl or libcurl capable of downloading ipfs:// content
from any reachable IPFS node, not just a localhost trusted one.
If anything, do we agree that doing this is a desirable improvement ?
assuming implemented in curl
> If we are still talking about IPFS-over-HTTP then I believe this situation
stands. If you want an IPFS-over-HTTP library you can make one on top of
libcurl.
>
> Am I wrong and if so, how and why?
Right now it is indeed "IPFS-over-HTTP" however it is different from
the current implementation.
