Error: Key does not exist. on pass account id to name.publish

[MicrowaveDev]

• Version: 0.35.0
• Platform: Darwin mac.local 17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64

Type: Bug

Severity: Medium

Description: Error on trying to pass account Peer ID instead of name to ipfs.name.publish

(node:20297) UnhandledPromiseRejectionWarning: Error: Key 'QmUctS4HYzuFrqNQmjnRoRn6kBnMecBZobBQfsPzo46nbA' does not exist. ENOENT: no such file or directory, open '/root/.jsipfs/keys/pkcs8/QmUctS4HYzuFrqNQmjnRoRn6kBnMecBZobBQfsPzo46nbA.data'
    at _error (/root/my-app/node_modules/libp2p-keychain/src/keychain.js:53:38)
    at store.get (/root/my-app/node_modules/libp2p-keychain/src/keychain.js:386:16)
    at ReadFileContext.fs.readFile (/root/my-app/node_modules/datastore-fs/src/index.js:216:16)
    at ReadFileContext.callback (/root/my-app/node_modules/graceful-fs/graceful-fs.js:90:16)
    at FSReqWrap.readFileAfterOpen [as oncomplete] (fs.js:237:13)
(node:20297) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:20297) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Steps to reproduce the error:

const IPFS = require('ipfs');
const node = new IPFS({
  pass: 'traffic enough crater wear tissue term town have switch exhibit onion asset'
});

const keys = await = node.key.list();
const peerId = keys[0].id;

node.name.publish('QmdFuxvDj27kW3j3DbosoicC828jm7ZtJNbVubFQ8aTbNV', {
  key: peerId
});

[alanshaw]

@vasco-santos do you have a sec to look into this one please?

[vasco-santos]

Hello @Jonybang , thanks for reaching out

Currently, you cannot access the keychain without starting a node with a pass (how to start with a pass)

In the current code example, I cannot reproduce your error because I cannot get node.key.list(). However, you should use the key name instead of the id in the publish. Take this as an example and the following untested code:

const IPFS = require('ipfs');
const node = new IPFS({});

const keys = await = node.key.list();
const keyName = keys[0].name;

node.name.publish('QmdFuxvDj27kW3j3DbosoicC828jm7ZtJNbVubFQ8aTbNV', {
  key: keyName
});

Let me know if you were able to get this solved.

[MicrowaveDev]

@vasco-santos sorry, i forgot about pass, i've fixed issue reproducing code.
However, documentation says:

key:      // string - Name of the key to be used or Peer ID. Default: 'self'

but Peer ID actually not working.

[MicrowaveDev]

I have no problems with passing name instead of peer id, but it makes my code more complicated, i have only peer id on input, so i made hotfix like this:

if(_.startsWith(account, 'Qm')) {
  account =_.find(await node.key.list(), {name: account}) || {}).id;
}
node.name.publish(`${storageId}`, {
  key: account
});

But it would be great if js-ipfs code will follows the documentation, so i could remove this hotfix in the future 😊

[alanshaw]

However, you should use the key name instead of the id in the publish

What's the reason for this @vasco-santos? Is it a bug?

[vasco-santos]

@vasco-santos sorry, i forgot about pass, i've fixed issue reproducing code.
However, documentation says:

key:      // string - Name of the key to be used or Peer ID. Default: 'self'

but Peer ID actually not working.

In fact, we do not support the key as a peer-id, just the name, which in the majority of the cases is the user-friendly approach.

That is a misleading doc and should be modified. However, @Jonybang are you willing to give it a try in adding support for supporting a peer id?

However, you should use the key name instead of the id in the publish

What's the reason for this @vasco-santos? Is it a bug?

Documentation bug yes! We only support the name of the key

[alanshaw]

@vasco-santos would you mind opening a PR to fix the docs for now? 🙏

@Jonybang does this answer your question? Did you get things working now?

[vasco-santos]

Done!

[MicrowaveDev]

@alanshaw now docs is match to code, yes 😅
But i think its not right - to restrict implementation in that way, because in fact we bind hash to peer id, not to name, and name may changing. Anyway this is a discussion question and not a bug anymore, so i will close this issue. Maybe i should to create new issue for discussion? if so, in what repo?

[vasco-santos]

@Jonybang I do not agree with your reasoning.

When you generate a key for an ipfs node using using key.gen

key.gen('key-name')

You define a key that you want your node to use. After this, you start your node, which will be node with peer id x and you do:

name.publish(value, { key: ´key-name' })

or:

const keys = await node.key.list()
const keyId = keys[1].id // for ease of example

name.publish(value, key: keyId })

Of course, the best approach depends on the use case. However, as we define the name when you create the key, and you can also rename it, the name would fairly be easier to use and remember, then the id belonging to it. Also, the default value is self, the key name, as in the go-ipfs implementation. Moreover, in a use case that prefers to use the id instead of the name, it is also quite easy to obtain the id.

We are not restricting the implementation in any way. I implemented that api using only the key name and forgot about the key id support. Each subsystem of ipfs has a lot of different parameters and configurations and we intended to provide full support to the users, while also adding new features and improving performance. This way, sometimes full support has to come after adding new features that people cannot really use.

Anyway, you can create an issue for discussion of Adding key id support to name publish in this repo, and I would happily review a PR to add it 🙂

[MicrowaveDev]

@vasco-santos i think there is a misunderstanding. I didn't said that passing name is bad, its good and very useful, you done a great job guys, thank you. But it would be cool if there will a possibility to pass peer id too because it permanent and in fact used for point to hash, that's all 😊
I will create discussion PR

[alanshaw]

it would be cool if there will a possibility to pass peer id too

+1 please send PR! 😁