desirable IPNS properties

[krl]

• should be easy to find latest record
  even when the record has not been updated in a long time
• prevent un-noticed targeted updates
  you should not be able to selecively serve an update to only one peer, without this being obvious after syncing up with other nodes.
• should not be able to selectively leave out updates
  say the name is a series of patches to a program,
  you should not be able to serve a later record, without also serving the intermediary values
• request for latest value has a TTL
  set this to MAX, maybe one hour, to continously recieve update events from the dht as the pointer changes

[wking]

On Sun, May 24, 2015 at 04:36:41PM -0700, kristoffer wrote:

• should be easy to find latest record
  even when the record has not been updated in a long time

See also the validity discussion in ipfs/kubo#999.

• should not be able to selectively leave out updates
  say the name is a series of patches to a program, you should not be
  able to serve a later record, without also serving the intermediary
  values

I'm not sure about this. Are we trying to detect (and subsequently
blacklist or something) malicious DHT nodes? I see two parallel
approaches to this:

a. Publishers who want to protect against this sort of selective
serving should publish commit objects (once we get Merkle objects
for commits). That allows consumers to follow the
(publically-signed) graph of parent objects back as far as they
want.
b. The DHT algorithm should allocate several providers for a given DHT
key, and make it difficult for an attacker to mine node keys until
they monopolize the providers for a given DHT resource.

(a) seems fairly simple. I know nothing about DHT algorithms, so I
can't say much about (b). But for widely-pinned recources there will
be many providers for a given object (and maybe there's similar logic
for DHT entries?), so it should be hard for a malicious censor to keep
word of new publications from leaking out.