Gateway.APICommands configuration is ignored

[lidel]

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.APICommands in 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.

[aschmahmann]

We're going to go with option A here.

[BigLep]

@lidel : is this a good candidate for @schomatis ?

[schomatis]

Yes, assigning.

[schomatis]

@lidel Working on this, do we want an extra config for

how can gateway operator disable /api/v0 entierely if they wish to do so?

?