IPNS record lifetime

[jbenet]

Replay attacks on the name system are a problem. One possible way to protect against them is with record lifetimes/expirations. The time here is meant to be used at the discretion of the publisher and resolver; it is a hint from the publisher meant to assist the resolver pair in deciding whether to trust the validity of a record. Network time protocol, for example, may be agreed upon by sets of parties out of band (ntp, Bitcoin, atomic clocks, etc).

Examples:

• Trust this record until 2014-12-01 00:00:00.0
• Trust this record until Bitcoin block somehash + 10
• Trust this record forever

[zignig]

Expiration is an important topic to consider

I have always like future stamped UUIDs. If you use type three you can have source pair uuid and map it back into the merkledag.

[whyrusleeping]

We should also being tacking version numbers onto our ipns entries.

[jbenet]

@whyrusleeping version numbers? or commit chain? I'm a bigger fan of commit chain-- arbitrary histories. (to do easy sequence finding -- as @Domanic wants -- the commit could have a height int which is max(children height) + 1, but you can still allow non-linear (branched) histories)

[whyrusleeping]

Yeah, i meant commit chain but said version numbers.

[jbenet]

@whyrusleeping

There's a few things going on in an ipns record, all of which should interop as much as possible:

• signature (record key = H(pk), anyone can verify(pk, record)
• link (a link, to ipfs, ipns, ...) e.g. /ipfs/<some hash>/foo/bar. should validate it's a link path. maybe have some upper bound, like 4KB (same as a URL limit). we can see about relaxing this once we look into routing systems with better properties.
• validity (record lifetime is one approach, there could be others) Let's start validity with straight expiration date (in network time) and/or a TTL (a TTL, like in dns would just mean a node should consider a record invalid TTL seconds after receiving the record).

[whyrusleeping]

I think validity needs to be moved into the dht record level, and not be managed in ipns. So we could say:

Put(key, val, validity)

Which in my opinion very much simplifies the management of dht records.

[jbenet]

As discussed in irc, the dht record is opaque. The dht cannot understand why something is valid, because valid means different things to different client systems.

[jbenet]

(noting) (a) the dht gets a map[type]ValidatorFunc (b) records carry a type (key prefix makes a ton of sense. note this means all ipfs provide records should now be "/ipfs/", which probably makes sense, except for the 2.x blowup in size), (c) upon receiving a record, dht runs it by corresponding ValidatorFunc