feat: add information on the features supported by the public IPFS gateways

[aschmahmann]

Describe your changes

Given how much use and attention the public gateways provided by the IPFS Foundation get and how diverse IPFS implementations could be (https://specs.ipfs.tech/architecture/principles/#ipfs-implementation-requirements), it would be good to say explicitly what these public gateways support.

Information here is pretty rough but wanted to get something out. cc @darobin @lidel

Files changed

• docs/concepts/public-utilities.md

What issue(s) does this address?

Does this update depend on any other PRs?

No

Checklist before requesting a review

• Passing the beta version of the Check Markdown links for modified files check. Action results can be viewed here.

Checklist before merging

• Passing all required checks (The beta Check Markdown links for modified files check is not required)

[2color]

WebTransport is only for browsers as far as I'm aware.

Suggested change

- WebTransport

[aschmahmann]

go-libp2p should support both receiving and dialing webtransport addresses (e.g. https://github.com/libp2p/go-libp2p/blob/6cebdd88366696a19b61dc209768c932a8f1ec4b/p2p/transport/webtransport/transport_test.go#L106)

[2color]

Pretty cool, but would be misleading. As far as I'm aware there's no reason a go peer would use WebTransport over QUIC. It would be misleading as it might wrongly suggest that browsers with WebTransport can be dialled over WebTransport.

[aschmahmann]

As far as I'm aware there's no reason a go peer would use WebTransport over QUIC

IIRC WebTransport would better help you hide you were using libp2p since it just looks like a regular HTTP/3 connection. However, independent of that some environments other than browsers might make WebTransport available before QUIC due to needing lower level access to QUIC (as opposed to WebTransport which for libp2p's case runs a Noise handshake on top to establish which PeerID is associated with the connection).

[aschmahmann]

@2color any idea why this is failing with
Status: 400 [Error: ENOENT: no such file or directory, access '/github/workspace/docs/concepts/nodes']? Seems like the check is in the wrong place but clicking through on the website seems ok and the link wasn't modified in this PR.

[2color]

@aschmahmann Yeah it seems that this action is triggering some false positives, e.g. https://github.com/ipfs/ipfs-docs/actions/runs/8673131916/job/23935698662

I would just ignore it for this PR.

[lidel]

@bumblefudge Try reviewing/merging #1886 first, I've fixed a bunch of broken links there, should make this one easier.

[lidel]

lgtm, should be enough until we finish ipfs/specs#453 and refer to it here

Merged small suggestions, we can refine in follow-up PR.