Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Fwd: Adding IPFS Trustless Gateway Protocol Questions
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Hugo Valtier via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 26 Oct 2023 15:42:34 +0200
> 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.
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 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 next to the current ipfs:// URL rewriting
> A primary reason I insisted on making the current implementation for the curl
tool and not for libcurl, is the fact that it is "only" a client on top of
> HTTP, and as such libcurl can be used as-is and does not need changing.
For me the main draw of having it in libcurl is that we can provide
the same GET semantics to consumers while having self validating
incrementally verified requests.
If I make my own C library which consumes libcurl either I have a
different API (creates work for consumers) or I make my own fork but I
believe me tracking you is work overall than if libcurl would know how
to reach out to the IPFS validation code, it's also annoying for
distributions.
I don't understand why precisely drawing the line at over-HTTP,
Trustless Gateway is used in production to transfer data between IPFS
implementations.
Would the new Trustless-Gateway-over-HTTP-over-Libp2p protocol be a
suitable candidate for libcurl ? AFAIT it can't just be done on top
since it requires running HTTP over yamux + tls + tcp (or other libp2p
transports).
Date: Thu, 26 Oct 2023 15:42:34 +0200
> 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.
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 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 next to the current ipfs:// URL rewriting
> A primary reason I insisted on making the current implementation for the curl
tool and not for libcurl, is the fact that it is "only" a client on top of
> HTTP, and as such libcurl can be used as-is and does not need changing.
For me the main draw of having it in libcurl is that we can provide
the same GET semantics to consumers while having self validating
incrementally verified requests.
If I make my own C library which consumes libcurl either I have a
different API (creates work for consumers) or I make my own fork but I
believe me tracking you is work overall than if libcurl would know how
to reach out to the IPFS validation code, it's also annoying for
distributions.
I don't understand why precisely drawing the line at over-HTTP,
Trustless Gateway is used in production to transfer data between IPFS
implementations.
Would the new Trustless-Gateway-over-HTTP-over-Libp2p protocol be a
suitable candidate for libcurl ? AFAIT it can't just be done on top
since it requires running HTTP over yamux + tls + tcp (or other libp2p
transports).
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-10-26