My understanding is that the curl position was around making sure UX (defaults) are safe and don't tie the user to any third-party gateway.
Default behavior in the merged curl PR got adjusted and now the only gateway that is used implicitly is the localhost one. Using an external, potentially untrusted public gateway requires explicit opt-in from the user via IPFS_GATEWAY env variable.
FWIW, in recent years IPFS ecosystem made content-addressing over HTTP viable and useful. Standards and specifications got created. Verifiable responses have standardized content types registered at IANA.
Web Browser use cases without native ipfs:// and ipns:// should use subdomain HTTP gateways like localhost in Kubo, or public dweb.link, cf-ipfs.com, which provide Origin per root CID, sandboxing web apps from each other.
Default behavior in the merged curl PR got adjusted and now the only gateway that is used implicitly is the localhost one. Using an external, potentially untrusted public gateway requires explicit opt-in from the user via IPFS_GATEWAY env variable.
FWIW, in recent years IPFS ecosystem made content-addressing over HTTP viable and useful. Standards and specifications got created. Verifiable responses have standardized content types registered at IANA.
For practical info, see:
"Deserialized responses" vs "Verifiable responses" at https://curl.se/docs/ipfs.html
"Deserialized responses" are designed to be used on localhost, "Verifiable responses" are something one would use with a gateway they don't trust
Client docs at https://docs.ipfs.tech/reference/http/gateway/#trustless-ver...
Server specification at https://specs.ipfs.tech/http-gateways/trustless-gateway/