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: 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 17:47:07 +0200
> 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 rewrite approach? I mean, isn't
verifying the content always better than not verifying? And if not, how would
a user know when to use which?
Yeah sorry my explanation was confusing.
Currently the ipfs:// feature in curl, the IPFS decoding and hash validation
happens server side, instead I'll submit some code which does that in curl.
So a buggy or badly behaving server would be caught by curl and raise an error.
> One of my most important tasks in this project is to resist creeping featurism
> - and everyone who has been around here a while know that we are still adding
> features and changes at a rather high pace. To make sure that the line in the
> sand that is drawn between what is suitable for libcurl and what is NOT
> suitable for libcurl remains intact and untouched as much as possible. I think
> sticking "core" transport protocols could be considered one of those things
> that so far has defined if a protocol is meant for libcurl or not.
>
> Lines in sand are by definition not distinct or always very clear, but I think
we do everyone a service when we resist changing how that line is drawn.
>
> Of course, sometimes we end up clarifying or changing how we view the world
> after discussions and deliberating and then we adapt and move on with an
> updated view. But until that moment, we resist it.
Fair enough.
> I'm sorry but I don't understand the question. If IPFS-over-HTTP is not for
> libcurl, then how is Trustless-Gateway-over-HTTP-over-Libp2p any better?
I used it to poke holes in:
> If you want an IPFS-over-HTTP library you can make one on top of
> libcurl.
but as you pointed out:
> Lines in sand are by definition not distinct or always very clear, but I think
> we do everyone a service when we resist changing how that line is drawn.
so this is irrelevant.
I think the best path forward is for me to send a PR iterating on what is
already in the cli.
> Are you proposing that libcurl would use another library for IPFS that itself
> would have a *separate* HTTP implementation and this, because you're doing
> HTTP in a non-standard way?
I was saying that in case the suggestion was that by doing IPFS-over-HTTP in
curl wouldn't speak real IPFS protocol.
This is still experimental. I wasn't planning on this in libcurl any time soon.
An hypothetical implementation of this would use curl's http code, but running
over custom tcp semantics streams (which are multiplexed and encrypted).
This protocol's main goal is to allow us to use existing HTTP clients over our
mutually encrypted P2P network, which is really useful in browsers.
Date: Thu, 26 Oct 2023 17:47:07 +0200
> 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 rewrite approach? I mean, isn't
verifying the content always better than not verifying? And if not, how would
a user know when to use which?
Yeah sorry my explanation was confusing.
Currently the ipfs:// feature in curl, the IPFS decoding and hash validation
happens server side, instead I'll submit some code which does that in curl.
So a buggy or badly behaving server would be caught by curl and raise an error.
> One of my most important tasks in this project is to resist creeping featurism
> - and everyone who has been around here a while know that we are still adding
> features and changes at a rather high pace. To make sure that the line in the
> sand that is drawn between what is suitable for libcurl and what is NOT
> suitable for libcurl remains intact and untouched as much as possible. I think
> sticking "core" transport protocols could be considered one of those things
> that so far has defined if a protocol is meant for libcurl or not.
>
> Lines in sand are by definition not distinct or always very clear, but I think
we do everyone a service when we resist changing how that line is drawn.
>
> Of course, sometimes we end up clarifying or changing how we view the world
> after discussions and deliberating and then we adapt and move on with an
> updated view. But until that moment, we resist it.
Fair enough.
> I'm sorry but I don't understand the question. If IPFS-over-HTTP is not for
> libcurl, then how is Trustless-Gateway-over-HTTP-over-Libp2p any better?
I used it to poke holes in:
> If you want an IPFS-over-HTTP library you can make one on top of
> libcurl.
but as you pointed out:
> Lines in sand are by definition not distinct or always very clear, but I think
> we do everyone a service when we resist changing how that line is drawn.
so this is irrelevant.
I think the best path forward is for me to send a PR iterating on what is
already in the cli.
> Are you proposing that libcurl would use another library for IPFS that itself
> would have a *separate* HTTP implementation and this, because you're doing
> HTTP in a non-standard way?
I was saying that in case the suggestion was that by doing IPFS-over-HTTP in
curl wouldn't speak real IPFS protocol.
This is still experimental. I wasn't planning on this in libcurl any time soon.
An hypothetical implementation of this would use curl's http code, but running
over custom tcp semantics streams (which are multiplexed and encrypted).
This protocol's main goal is to allow us to use existing HTTP clients over our
mutually encrypted P2P network, which is really useful in browsers.
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-10-26