3 ms·

I’d love to see IPFS native protocol support in curl, to be honest. After all, curl already supports dozens of other obscure protocols: DICT, FILE, FTP, FTPS,

by gcr 3y ago

I’d love to see IPFS native protocol support in curl, to be honest. After all, curl already supports dozens of other obscure protocols: DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, POP3, POP3S, RTMP, RTMPS, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS… One challenge of doing this correctly is that curl is intended to be a “one-off” call that downloads and exits without participating in the swarm the way a good BitTorrent client should. Granted, presumably this IPFS gateway solution also has this problem.

yjftsjthsd-h 3y ago
Well, that seems like exactly the difference: It's not about obscurity, it's about curl not being a daemon and therefore a poor fit for p2p protocols.
- 1letterunixname 3y ago
  People use ipfs to download hosted (by someone) things, so it is a fit. Have a look at https://winworldpc.com https://winworldpc.com Also, the Internet Archive uses web seeded torrents to accomplish the problem of insufficient seeds rather than throwing them into the ether (non-crypto variant) and hoping for mirroring by wishful thinking. Conclusion: Centralized, unicast-like support for p2p is possible and useful for download-oriented clients. IPFS Desktop in particular: One shitty thing they did was auto re-opt-in to telemetry without asking the user. With that kind of sneaky bullshit, I refuse to run it. IPFS lost trust and is unable to communicate how their "solution" is useful or make it usable by humans who aren't IPFS Desktop developers.
  - duskwuff 3y ago
    I feel like you're missing the point here. P2P protocols like IPFS are built with the expectation that clients are persistent. They take a nontrivial amount of time to start up (e.g. to discover peers), and require continuous maintenance from the application to keep running (e.g. to chat with those peers and keep them happy). These characteristics are incompatible with clients like curl. They're written with the expectation that connection setup is cheap and that connections don't require maintenance while they aren't being used. These expectations are all true of existing protocols like HTTP(S) or FTP; they fail with IPFS. And there isn't really any way to solve that without introducing another process to act as an intermediary -- which is exactly what an IPFS gateway does.
    - mburns 3y ago
      Not really, a transient ipfs node works just fine. There are stable nodes to bootstrap a new node into the network. More initialization that if you were using http, sure, but it isn’t as against the grain as you suggest. https://github.com/ipfs/ipget https://github.com/ipfs/ipget
1letterunixname 3y ago
Your mischaracterization of HTTPS as obscure is baffling. I guess you aren't in tech or anything older than you is "old".
- gcr 3y ago
  My obscure protocols list even includes HTTP! I must be such an idiot! It’s almost as if I copy+pasted from the curl man page or something!

by gcr 3y ago

yjftsjthsd-h 3y ago

Well, that seems like exactly the difference: It's not about obscurity, it's about curl not being a daemon and therefore a poor fit for p2p protocols.

1letterunixname 3y ago
People use ipfs to download hosted (by someone) things, so it is a fit. Have a look at https://winworldpc.com https://winworldpc.com Also, the Internet Archive uses web seeded torrents to accomplish the problem of insufficient seeds rather than throwing them into the ether (non-crypto variant) and hoping for mirroring by wishful thinking. Conclusion: Centralized, unicast-like support for p2p is possible and useful for download-oriented clients. IPFS Desktop in particular: One shitty thing they did was auto re-opt-in to telemetry without asking the user. With that kind of sneaky bullshit, I refuse to run it. IPFS lost trust and is unable to communicate how their "solution" is useful or make it usable by humans who aren't IPFS Desktop developers.
- duskwuff 3y ago
  I feel like you're missing the point here. P2P protocols like IPFS are built with the expectation that clients are persistent. They take a nontrivial amount of time to start up (e.g. to discover peers), and require continuous maintenance from the application to keep running (e.g. to chat with those peers and keep them happy). These characteristics are incompatible with clients like curl. They're written with the expectation that connection setup is cheap and that connections don't require maintenance while they aren't being used. These expectations are all true of existing protocols like HTTP(S) or FTP; they fail with IPFS. And there isn't really any way to solve that without introducing another process to act as an intermediary -- which is exactly what an IPFS gateway does.
  - mburns 3y ago
    Not really, a transient ipfs node works just fine. There are stable nodes to bootstrap a new node into the network. More initialization that if you were using http, sure, but it isn’t as against the grain as you suggest. https://github.com/ipfs/ipget https://github.com/ipfs/ipget

1letterunixname 3y ago

Your mischaracterization of HTTPS as obscure is baffling. I guess you aren't in tech or anything older than you is "old".

gcr 3y ago
My obscure protocols list even includes HTTP! I must be such an idiot! It’s almost as if I copy+pasted from the curl man page or something!