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.
Re: IPFS support in Curl
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 21 Feb 2022 10:06:53 +0100 (CET)
On Fri, 18 Feb 2022, Chris Anderson wrote:
My job is to resist feature creep and question all additions. Everything we
add must be considered and properly motivated.
> The HTTP gateways serve as a compatibility layer for clients that aren¢t
> running a full node.
I understand how that is convenient and practical for end users wanting to
reach IPFS hosted resources. But it's not speaking IPFS the protocol then, it
speaks HTTP(S). Using a scheme called 'IPFS' when in reality it is doing HTTPS
is going to cause confusion. Are we adding IPFS support or are we not?
I'm also cautious about adding support for protocols where there is no
established URL syntax defined. URLs are designed for and meant to work the
same across clients and servers, and without a detailed spec which explains
how it works, the format risks becoming tool specific or that we need to break
behavior going forward.
Do I understand it correctly that these IPFS URLs are designed to work
identically independently if the protocol is HTTPS-via-gaweway or the "real"
IPFS protocol?
> Initially I considered including the stateful peer behavior into curl, but
> that is a lot of code and probably introduces runtime weight curl is better
> off avoiding. The gateway approach gives the same result to the end user,
> with a much simpler patch and faster runtime.
How does a user even connect to/access IPFS ? How would a user know a gateway
to connect to? It seems much easier to provide HTTPS URLs to such users with a
known gateway host in the URL. I mean, clearly anyone invoking this curl for
IPFS would need to know that it speaks the HTTP-gateway flavor.
> The main purpose of putting it into the curl tool is ergonomics.
See, there's a big difference between the tool and libcurl. I asked about why
it needs to be in the library. You now answer why it should be in the tool. I
think there's a huge difference in adding the support in the tool vs the
library.
I'm much easier to persuade adding this to the tool than to the library. To
me, the tool seems like a reasonable layer to do "HTTPS URL translations" in
rather than in the library.
> Increasingly we are seeing IPFS urls intermixed with HTTP urls in eg
> database tables, etc.
I'm sure *you* see that more often, I'm not so sure that's universally true.
> While it¢s possible to educate the ecosystem about how to convert from
> network to gateway URLs, the transform is safe and clean enough to do once
> in a library.
Since these URLs still don't work as-is, these users still need education. I
find that a very peculiar and surprising kind of URL.
Date: Mon, 21 Feb 2022 10:06:53 +0100 (CET)
On Fri, 18 Feb 2022, Chris Anderson wrote:
My job is to resist feature creep and question all additions. Everything we
add must be considered and properly motivated.
> The HTTP gateways serve as a compatibility layer for clients that aren¢t
> running a full node.
I understand how that is convenient and practical for end users wanting to
reach IPFS hosted resources. But it's not speaking IPFS the protocol then, it
speaks HTTP(S). Using a scheme called 'IPFS' when in reality it is doing HTTPS
is going to cause confusion. Are we adding IPFS support or are we not?
I'm also cautious about adding support for protocols where there is no
established URL syntax defined. URLs are designed for and meant to work the
same across clients and servers, and without a detailed spec which explains
how it works, the format risks becoming tool specific or that we need to break
behavior going forward.
Do I understand it correctly that these IPFS URLs are designed to work
identically independently if the protocol is HTTPS-via-gaweway or the "real"
IPFS protocol?
> Initially I considered including the stateful peer behavior into curl, but
> that is a lot of code and probably introduces runtime weight curl is better
> off avoiding. The gateway approach gives the same result to the end user,
> with a much simpler patch and faster runtime.
How does a user even connect to/access IPFS ? How would a user know a gateway
to connect to? It seems much easier to provide HTTPS URLs to such users with a
known gateway host in the URL. I mean, clearly anyone invoking this curl for
IPFS would need to know that it speaks the HTTP-gateway flavor.
> The main purpose of putting it into the curl tool is ergonomics.
See, there's a big difference between the tool and libcurl. I asked about why
it needs to be in the library. You now answer why it should be in the tool. I
think there's a huge difference in adding the support in the tool vs the
library.
I'm much easier to persuade adding this to the tool than to the library. To
me, the tool seems like a reasonable layer to do "HTTPS URL translations" in
rather than in the library.
> Increasingly we are seeing IPFS urls intermixed with HTTP urls in eg
> database tables, etc.
I'm sure *you* see that more often, I'm not so sure that's universally true.
> While it¢s possible to educate the ecosystem about how to convert from
> network to gateway URLs, the transform is safe and clean enough to do once
> in a library.
Since these URLs still don't work as-is, these users still need education. I
find that a very peculiar and surprising kind of URL.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-02-21