There are plans to update IPNS to use an IPRS record for the entry, which is currently defined here: https://github.com/ipfs/go-ipfs/blob/master/namesys/pb/namesys.proto
The IPRS record should be updated to also include the peer ID. And, more importantly, the link that people send should not be just the peer ID but should be the IPFS multihash of this IPRS record. To use IPNS, instead of using the peer ID to look up the value in the DHT, an application would fetch the IPRS record using normal IPFS. Since the IPRS record has the peer ID, the application can look up the current value in the DHT (if needed). But if there is no entry in the DHT then the application can use the value in the IPRS record (basically a snapshot).
This solves the "IPNS link rot problem" because IPRS records are normal IPFS objects which can be pinned and don't depend on ephemeral DHT entries. (This is part of a larger conversation about handling dynamic versioned content.)
There are plans to update IPNS to use an IPRS record for the entry, which is currently defined here: https://github.com/ipfs/go-ipfs/blob/master/namesys/pb/namesys.proto
The IPRS record should be updated to also include the peer ID. And, more importantly, the link that people send should not be just the peer ID but should be the IPFS multihash of this IPRS record. To use IPNS, instead of using the peer ID to look up the value in the DHT, an application would fetch the IPRS record using normal IPFS. Since the IPRS record has the peer ID, the application can look up the current value in the DHT (if needed). But if there is no entry in the DHT then the application can use the value in the IPRS record (basically a snapshot).
This solves the "IPNS link rot problem" because IPRS records are normal IPFS objects which can be pinned and don't depend on ephemeral DHT entries. (This is part of a larger conversation about handling dynamic versioned content.)