Published name lifetime inconsistent with DHT and default values

[BubuAnabelas]

Version information:

go-ipfs version: 0.6.0
Repo version: 10
System version: amd64/windows
Golang version: go1.14.4

Description:

I was making some changes to ipfs-watch-and-publish and noticed that ipfs name publish --lifetime accepts huge arguments (i.e. 1 year = 8760h) and still publish it successfuly. The default record lifetime is 24 hours and libp2p-kad-dht's default max record age is 36 hours so, I guess even if I pass "48h" as the lifetime parameter it would expire after 36 hours anyway.

It's kinda confusing, given that the DHT options are different across the nodes, maybe it could be useful to check that the lifetime parameter is lower than the local DHT's max record.

This can be related to libp2p/go-libp2p-kad-dht#397

[welcome]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

[aschmahmann]

@BubuAnabelas if you have documentation suggestions that could be reasonable.

However, it's worth pointing out that record attributes (e.g. lifetime) are part of the signed IPNS record which could be propagated using many different systems of which the public IPFS kademlia network is only one. For example, IPNS over PubSub does not delete records every 36h.

[BubuAnabelas]

I wasn't aware that IPNS over PubSub was already working and I'm not familiar with its internal features, please point me out to its docs or code.
Even though, as far as I'm concerned if I do ipfs name publish, it does publishes to the DHT nonetheless (with PubSub this changes or a flag is added?) so perhaps adding a line to the ipfs name publish --help output would be nice, clarifying that the DHT nodes have an EOL of 36h by default.

Also maybe changing the labels of this issue from king/bug to king/enhancement and topic/docs-ipfs?

[aschmahmann]

please point me out to its docs or code.

spec: https://github.com/ipfs/specs/blob/master/naming/pubsub.md
overview and how to use in go-ipfs: https://github.com/ipfs/go-ipfs/blob/master/docs/experimental-features.md#ipns-pubsub
code: https://github.com/libp2p/go-libp2p-pubsub-router

clarifying that the DHT nodes have an EOL of 36h by default.

Why do you feel that the particulars of the router here should be exposed to the user? In particular, it's worth noting that if you set the lifetime of your record to be 5 years and published it to the DHT it's actually possible that the record could still be in the DHT and valid 5 years from now since if you turn off your machine an interested third party could manually republish the record in the DHT for you.

The 36 hours business is just about how long a DHT server node is willing to keep data around for without it being reminded, but it's a pretty low level piece of information. Note, you may need to republish more frequently then this based on the churn rate of the network (i.e. the frequency of DHT servers going online and offline) and go-ipfs will automatically republish IPNS records as determined by your config file (https://github.com/ipfs/go-ipfs/blob/master/docs/config.md#ipnsrepublishperiod).

[BubuAnabelas]

My thought are specially considering the case in which a user doesn't want to keep go-ipfs running to automatically republish (or doesn't know it might be necessary) and I feel it can be a little misleading to publish with a long lifetime given that the actual lifetime of the record depends on many different factors.

Lets assume Alice (a non-technical user) wants to publish a website so she uses IPNS, she just runs ipfs name publish with a long lifetime, then she goes and closes ipfs daemon forever and some time later in the future she sends /ipns/Qm... to Bob. In the best case scenario Bob can access Alice website. In some more real world scenario, given that DHT servers store the record for 36h and nobody was interested in republishing Alice's record (or they went offline, as Alice was since she close her IPFS instance), Bob will not be able to access Alice's website.

I think this case is similar to what #590 was for pinning.

[lidel]

mildly related: #8586 (adding an explicit IPNS reprovider duration would make lifetime more useful, because other peers could keep republishing a valid signed record created by other peer)