Description
This one slipped between our fingers:
Problem
Gateway.APICommands is ignored, go-ipfs 0.8.0 uses hardcoded list of commands:
(cmd/ipfs/daemon.go#L669 → core/commands/root.go#L166-L198
Why this matters
This is blocking our users from running their own delegated routing service without additional nginx magic as noted in libp2p/js-libp2p#371:
We were trying to use
Gateway.APICommandsin context of ipfs/js-ipfs#2155 (comment) but it did not work, and @mburns had to redirect to API port at Nginx level.
How to fix it?
Unsure, needs more analysis.
I see two ways to resolve this:
(A) keep implicit safelist, extend it with values added to APICommands
A backward-compatible way to fix this is to keep current implicit defaults from core/commands/root.go#L166-L198 when Gateway.APICommands is empty, but if we do this, how can gateway operator disable /api/v0 entierely if they wish to do so?
(B) no /api/v0 by default, only explicit opt-in safelist via APICommands
Perhaps we should make a breaking change and disable /api/v0 by default on Gateways, unless user explicitly safelisted commands via Gateway.APICommands ? This feels like a way safer default. We have some features that depend on /api/v0 and /ipfs/ endpoint does not provide replacement for them yet, so better to avoid this (eg. we don't want user to safelist dht/put but break refs as a side effect)
It always felt to me like something that should be opt-in, but would appreciate feedback if someone thinks otherwise.