ipfs name publish --allow-offline=true doesn't work when offline

[khinsen]

go-ipfs version: 0.4.21-
Repo version: 7
System version: amd64/darwin
Golang version: go1.12.5

Steps to reproduce (on a computer without internet connection):

1. ipfs daemon
2. ipfs name publish --key=<name-of-an-existing-key> --allow-offline=true <some-ipfs-path>

Result:

Error: failed to find any peer in table

The command (2) succeeds if any of the following conditions hold:

1. There is an internet connection.
2. The daemon was started in the presence of an internet connection, which was lost subsequently.
3. There is no daemon running at all.

I have hesitated between labeling this issue as a bug or as misleading documentation, since the observed behavior could well be intentional, with "offline" meaning "no daemon" rather than "no network connection" (as #4442 suggests). But I don't see a use case where this makes sense.

Note: my own use case for --allow-offline is unit tests that I don't want to fail for lack of a network.

[eingenito]

@khinsen this is definitely a bit confusing. I think this offline is referring to a daemon instance that has been started with the --offline flag: ipfs daemon --offline which prevents IPFS from even attempting to connect peers and participating in the DHT. It is not meant to squelch the error you see above which is an 'online' ipfs node that can't reach peers and therefore can't publish the name to the DHT even though it's otherwise configured to do so.

It's meant to allow the publishing of the name record to the local instance only, not optionally. Although your interpretation is also a completely valid feature.

[khinsen]

@eingenito Thanks for your comments, which provide some enlightenment and some additional confusion.

I didn't know about the --offline option to ipfs daemon, which ipfs daemon --help does not list. It is in the documentation though. And with that, the --allow-offline makes some more sense. Still I don't see why it should make a difference between a daemon being intentionally offline and a daemon being accidentally offline. "Allowing" offline operation should apply to either. If the goal is to make non-distribution of the name a requirement, I'd expect something like --require-offline.

Looking at this from the application developer's point of view, I see three situations:

1. I want to make sure the name binding gets known all over the world.
2. I want to make sure the name binding stays local to my node.
3. I don't care what happens outside of my node.

The configuration of the daemon is outside of the application developer's influence, so I'd expect the daemon to listen to what I want and either do it or raise an error, depending on its configuration and environment. From that point of view, the current behavior of --allow-offline, which is "publish the name if the daemon is online, don't publish it if the daemon is intentionally offline, and raise an error if the daemon is accidentally offline", makes little sense.

[eingenito]

@khinsen - I totally get your assertion, and it makes sense. That said the current --allow-offline flag was added intentionally: #4442, and probably isn't considered a bug. I don't know the actual use case, but I would guess it has to do with the practice of adding content while the daemon is not running to work around the slowdown caused by the daemon trying to publish lots of provider records while adding. After restarting the daemon the records will (maybe) eventually get published by the reproviding system. So --allow-offline make a little more sense historically (to me) in that context.

But I think there's a valid case to be made for a feature that ignores the success or failure of writing a new ipns name to the DHT. It too would get picked up by the reprovider system and published once the daemon had managed to connect to other IPFS hosts. Such a feature could obviate the need for the current flag. People are probably using --allow-offline so it probably wouldn't be removed (although it might be fine to just make it an alias for the new behavior).

I'm going to guess that it's not on any of the core team's roadmap but you're welcome to submit a PR for it. It might be tricky tho.

You said that you wanted this for unit tests; is it worth exploring that angle? A unit test for adding an ipns name that actually makes a call to a running IPFS instance is obviously more of an integration test (which is fine). If you want to assert on IPFS behavior there are lots of examples of such tests in the IPFS repo and lots of them actually bring up more than one IPFS node: https://github.com/ipfs/go-ipfs/tree/f9e9f2854b98eb8397360372b997690a79e5b60d/test/sharness

Don't know if that's helpful.

[khinsen]

@eingenito Thanks again for your reply! Don't count on me for a PR or anything like that - I am neither a systems programmer nor a Go programmer. I come from the application developer's side, trying to use the HTTP API for my purposes, which come down to using IPNS as a namespace for storing datasets.

This also explains why publishing a piece of data is a unit test and not an integration test from my point of view: it's just two calls to the HTTP API (publish, then get and compare).

It also explains why "offline" for me means "no network connection", whatever the cause. I don't know (and I think I cannot even find out) which options were given to the daemon I am connecting to. All I care about it whether I can publish something IPFS-wide or only locally.

For now, it looks like my best option is to pass --allow-offline=true and also check for and ignore the error returned by an accidentally offline daemon. This looks like the only combination that gives consistent behavior from an application's point of view when it doesn't matter if the publishing step is actually broadcast to other peers.