Local Gateway option

[magik6k]

This is an alternative / more contained version of #4150

((todo) some gx stuff still needs fixing)

[Stebalien]

(I meant "shepherd" but this also works)

@Voker57, I'd appreciate your review if you have time.

[Voker57]

This does not include a lot of code from my PR that tries to make the API actually offline beyond stuff that readonly gateway uses, but it could work I guess if nobody tries to use it for something else, mine does not cover all cases either.

Also, I don't like "negating" config option, it's a bit confusing.

[magik6k]

Also, I don't like "negating" config option, it's a bit confusing.

When adding options to the config, old nodes will use zero value for added fields, which in this case would break existing setups.

[Stebalien]

When adding options to the config, old nodes will use zero value for added fields, which in this case would break existing setups.

We really need a comprehensive config system with layers. One has to exist...

[magik6k]

Also, convincing the read only HTTP API to not fetch blocks is going to be harder, we should probably just implement the context hints.

[Stebalien]

@magik6k what's your opinion on this? Should we block this on context hints due to the read-only API (given that it's exposed on the gateway)?

[magik6k]

I don't see a nice way to work around this without context hints, so we can probably call this blocked for now. I'll try to put context hints near the top on my todo list though.

[Stebalien]

SGTM.

[Voker57]

@magik6k

When adding options to the config, old nodes will use zero value for added fields, which in this case would break existing setups.

Isn't that handled by go-ipfs-config? Voker57/go-ipfs-config@9c41d63

[magik6k]

Rebased

This covers the gateway + commands that support CoreAPI, few things are missed:

• /get - might be hard to port, but doable
• /dns - needs to get into coreapi (probably under .Name())
• /ls - Can be rewritten to use coreapi, but that's going to be quite hard (it can be worked around manually for now)
• /dag/get - needs to be ported to coreapi
• /dag/resolve - same as above

[magik6k]

Isn't that handled by go-ipfs-config? Voker57/go-ipfs-config@9c41d63

Nope, code in config/init.go only gets called on init. If values are missing from existing node config, they are set to zero value (which is false in this case). Using FetchBlocks would basically disable fetching blocks on gateway for all existing nodes (and other programs that create config.Config manually, expecting that (almost) zero-value config will just work).

[Stebalien]

Small nits.

Now, on to naming... thinking about this a bit, FetchBlocks/NoFetchBlocks is kind of cryptic. Most users just care about content, not blocks. Maybe something like RetrieveContent (download?)? I'm not sure but we should probably avoid using the word "blocks" if possible.

[magik6k]

Now, on to naming...

It's currently Gateway.NoFetch in config, which shouldn't be too confusing imo. (the coreapi option name is different, but I guess it can be because it's 'lower level')

[Stebalien]

It's currently Gateway.NoFetch in config, which shouldn't be too confusing imo. (the coreapi option name is different, but I guess it can be because it's 'lower level')

Ah. Fair enough.

[magik6k]

Should be ready

(Depends on ipfs/iptb-plugins#11, ipfs/go-ipfs-config#19)