> 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.html
