IPNS resolve fails using ECC key

[reardenlife]

ipfs v.0.4.19-dev

I installed ipfs on server #1, generated ECC key and published some content on IPNS using that key. Content resolves OK, although with a huge lag:

[root@v48807 dompoc]# ipfs key list -l
QmQBojsRJJrwvqDdbmWbmbZ7GCTnhHmzri5DhEqLP2zVXq self
QmafEdQrhntRYzKu3V2Mn4Rd21Px9Hpfgbw6YBvCNJyDJH addr1
QmVHUFuEj1v8YvWKS3p5NHNdZy66Ds4bLevt8KrbPPgWHh addr2
QmafEdQrhntRYzKu3V2Mn4Rd21Px9Hpfgbw6YBvCNJyDJH mykey
[root@v48807 dompoc]# date && ipfs name resolve /ipns/QmafEdQrhntRYzKu3V2Mn4Rd21Px9Hpfgbw6YBvCNJyDJH && date
Sun Mar  3 22:21:26 MSK 2019
/ipfs/QmaKVGFUQtGFfschpohWmWicmZwUPeTHLu74kymn3vupBj
Sun Mar  3 22:22:26 MSK 2019

Then I installed ipfs on a different server and tried to resolve that IPNS path and failed. Although the node itself (see above, the self key) is available:

[root@329020 ipfs]# date && ipfs name resolve /ipns/QmafEdQrhntRYzKu3V2Mn4Rd21Px9Hpfgbw6YBvCNJyDJH || date
Sun Mar  3 19:31:46 UTC 2019
Error: could not resolve name
Sun Mar  3 19:32:47 UTC 2019
[root@329020 ipfs]# ipfs ping QmQBojsRJJrwvqDdbmWbmbZ7GCTnhHmzri5DhEqLP2zVXq
PING QmQBojsRJJrwvqDdbmWbmbZ7GCTnhHmzri5DhEqLP2zVXq.
Pong received: time=166.36 ms
Pong received: time=125.47 ms
Pong received: time=32.16 ms
Pong received: time=79.04 ms
Pong received: time=160.03 ms
Pong received: time=85.26 ms
Pong received: time=189.14 ms
Pong received: time=134.40 ms
Pong received: time=81.88 ms
Pong received: time=1.53 ms
Average latency: 105.53ms

Interestingly, the resolution of an address generated by using the self key (RSA) works fine:

[root@329020 ipfs]# date && ipfs name resolve  /ipns/QmQBojsRJJrwvqDdbmWbmbZ7GCTnhHmzri5DhEqLP2zVXq && date
Sun Mar  3 19:41:26 UTC 2019
/ipfs/QmaKVGFUQtGFfschpohWmWicmZwUPeTHLu74kymn3vupBj
Sun Mar  3 19:41:36 UTC 2019

I am not sure what to do at this point and how to debug it. Any help will be appreciated.

[reardenlife]

The whole thing is quite funny, because a while ago it was working: libp2p/libp2p#62 (comment)

The only difference now is that I didn't build ipfs from scratch, but copied the compiled binary from the source server. And the second server geographically situated farther right now. So it should not matter.

The main question is how to debug it.

I looked into the config and realized that the "self" key is situated there. I am not sure if I can just put my ECC key there. Let me try.

Edit:

So I inserted base64-encoded private key and ran ipfs. Then I ran $ipfs publish w/o --key argument and made sure that it publishes at QmafEdQrhntRYzKu3V2Mn4Rd21Px9Hpfgbw6YBvCNJyDJH

I went to the second server and pinged QmafEdQrhntRYzKu3V2Mn4Rd21Px9Hpfgbw6YBvCNJyDJH, made sure that it is online. Then I tried to do name resolve. Same thing. "Error: could not resolve name"

[reardenlife]

It appears to me that there might be a problem related to the availability of public keys: libp2p/go-libp2p-kad-dht#139 (comment)
But in my case, since the version of ipfs is 0.4.19 and it calculates peerid differently than the latest stable one (namely, it does NOT embed the short public keys), it seems that the majority of nodes spit out my ipns record as invalid one.

How I can make sure that this is the case?

Anyways, if that is the case, how I was able to successfully ping the peer ID of which is calculated via my ECC key?

[reardenlife]

Hm...

--enable-namesys-pubsub

Got it working with above option enabled.

Well, but now if I will update the IPNS record on a publisher's service, it still resolves the old value on the second server. There must be a way to invalidate a record.

[lordcirth]

IPNS records have the --lifetime option, after which they are invalid.

[reardenlife]

@lordcirth

Good.
So you are proposing to use short lifetimes?
If so, in this case the node should be constantly online to re-publish something on IPNS. So once it goes offline, the other nodes are unable to retrieve the content from node's IPNS path?..

There are should be some other way to update how IPNS record resolves.

[lordcirth]

The settings you want depend on whether it's better to resolve an old value or fail. A long lifetime but short ttl will mean that resolves will frequently take the full 60 seconds, but will fall back to an old value if that's all that's available.

EDIT: By the way, rather than using date && command && date, you could just use time command.

[lidel]

Closing (ed25519 been the default for a while, no issues)