Skip to main content

A proposal to add #IPFS support to #libcurl

https://curl.se/mail/lib-2023-10/0073.html

I'm not convinced:
https://curl.se/mail/lib-2023-10/0074.html

Let the discussion flow!

Curl: Adding IPFS Trustless Gateway Protocol Questions

curl.se
#ipfs #libcurl
This entry was edited (6 months ago)
in reply to daniel:// stenberg://

Fennix :donor:
Fennix :donor:
• •
seems very reasonable to me. I think people would be surprised if libcurl started handling a new protocol like that and I can think of a lot of abuse cases that could suddenly appear.
in reply to daniel:// stenberg://

🔗 David Sommerseth
🔗 David Sommerseth
• •

Your argument is quite solid and sane, IMHO.

Even though I've not come to do any curl development (yet?), I think it makes perfect sense to let libraries do as little as possible - but do those things really well. And libraries can easily be stacked on top of each other - to provide a more specialised functionality.

To take a bit more childish view of this ... I always prefer to see software libraries as LEGO bricks where you combine them to build your master piece. I don't want a single piece giving me something I've been convinced I wanted (like Playmobil) and then get less flexibility to make it my own master piece.

This entry was edited (6 months ago)
in reply to daniel:// stenberg://

Man2Dev :idle:
Man2Dev :idle:
• •
can't you just allow it as experimental feature for now and just depricated if the code is abandoned is not up to curl standards
in reply to Man2Dev :idle:

daniel:// stenberg://
daniel:// stenberg://
• •
@Man2Dev sure we could, but why allow experimental code in if I don't think it belongs there in the first place?
@Man2Dev :idle:
in reply to daniel:// stenberg://

Man2Dev :idle:
Man2Dev :idle:
• •
I just skimmed through spec sheet and I guess you're right if you technically don't need it in libcurl to make ipfs work then by adding pointless code its just making another attack surface for libcurl
⇧