IPNS publish fails in offline mode

[krl]

At the moment, the ipfs name publish assumes that you are online, and also takes several seconds to return. I think a better approach would be to return immediately, and begin broadcasting the new name as soon as you have peers.

Making apps wait 5 seconds for publishing a name also creates some unnecessary UI problems.

@whyrusleeping @jbenet

[jbenet]

At the moment, the ipfs name publish assumes that you are online, and also takes several seconds to return. I think a better approach would be to return immediately, and begin broadcasting the new name as soon as you have peers.

Makes sense there's a usecase for fast return. but default action should be able to wait until name is resolvable (readable) by others. standard semantics writer. there may also be an error or failure to publish. Waiting is the safe bet from a UX-correctness standpoint.

i think --no-wait is perhaps a flag that can satisfy the requested "fire and forget" semantics. do note though that you must then do your own checking with the dht to see if the name has indeed been published to the network, and if not, show errors accordingly

also, the waiting time may be related to an odd waiting time i've been seeing recently. it happens on ipfs add as well. there's an odd hang after all output has been printed, and before the command exits.

[jbenet]

Although, --no-wait is fine as well as it has same semantics as ipfs add in that the content will only be resolvable by the rest of the world after some time. (hmmm maybe it should be --wait, and default to false... @whyrusleeping ?)

[krl]

If the default should be to wait for resolvable, what is the intended behaviour in offline or small (say three node) networks? I'm not sure that waiting belongs in this command at all.

[whyrusleeping]

I dont think the ipfs add stuff and the publish issue are related. unless the provides code in bitswap changed recently to block on Provide (it didnt use to). The long wait you might be seeing in add is likely filesystem flushing happening at the end since we do adds in batches now.

The waiting in publish is rather strange though, when offline we should see that we have no peers to send to and return kb.ErrLookupFailure. I'll take a look at that

[whyrusleeping]

@krl could you provide a repro? running:

ipfs name publish /ipfs/QmVtU7ths96fMgZ8YSZAbKghyieq7AjxNdcqyVzxTt3qVe

returns immediately with:

Published to QmZHw7PhRGQwGKgVAaE6vT2b98wF63PSZbyjNNHeJdMPTD: /ipfs/QmVtU7ths96fMgZ8YSZAbKghyieq7AjxNdcqyVzxTt3qVe

Running it with an object that doesnt exist locally returns:

Error: blockstore: block not found

Immediately.

[krl]

@whyrusleeping

time ipfs name publish /ipfs/QmVtU7ths96fMgZ8YSZAbKghyieq7AjxNdcqyVzxTt3qVe
Published to QmReJX55vhC5HbkBEZFW9V37vvirR1E7s2JW63cRt23BiN: /ipfs/QmVtU7ths96fMgZ8YSZAbKghyieq7AjxNdcqyVzxTt3qVe

real    0m6.203s

can anyone else check? @jbenet @mappum ?

[krl]

It seems like it returns immediately if daemon is not running, otherwise it blocks for several seconds.

[whyrusleeping]

@krl if the daemon is running, then the 'delay' is publishing to the dht. perfectly normal.

Good to close?

[jbenet]

@whyrusleeping no, the point is that @krl wants to be able to return immediately, which is a valid UX use case.

and, publish is slow for me, always. (>5s)

I think we should add --wait=false as an option. i.e. default to --wait=true

[krl]

Yep, and for my usecase it would also be enough that the command updates the internal ipns entry first, before publishing.

[whyrusleeping]

@krl what is your usecase? perhaps you would want to use ipns through the mfs api? it does what you want with the 'returning as soon as the internal ref is updated'

[whyrusleeping]

related: #3114