ipfs name keep-alive add <friend’s node id>
Periodically get and store the IPNS record and keep serving the latest seen version to the network until the record’s EOL.
You'll be able to pin IPNS records like anything else once we have IPRS
Awesome
Waiting for this feature 👍
But doesn't it make more sense if they are automatically pinned by nodes? Or would it be resource heavy,?
Consider that if pinned those have to be updated constantly via signatures etc etc...
The issue here is that the signature on IPNS records currently expires and random nodes won't be able to re-sign them as they'd need the associated private key. We expire them because the DHT isn't persistent and will eventually forget these records anyways. When it does, an attacker would be able to replay an old IPNS record from any point in time.
When it does, an attacker would be able to replay an old IPNS record from any point in time.
Is it really considered more dangerous than possibility of practically disappearing whole materials published under certain IPNS key if one (just one!) publisher node with its private key once disappears too? Doesn't this publisher node look like the central point of failure? Outdated, but _valid_ records are really worse than no records at all?
I think that ability to replay is not an critical security issue, at least in condition that user is explicitly notified that the obtained result could be outdated. After all, «it will always return _valid_ records (even if a bit stale)», as mentioned in 0.4.18 changelog.
So what do you think about --show-publish-time flag on ipfs name resolve command? Do the IPNS records itself contain this data?
@lockedshadow I've been thinking about (and discussing this) this and, well, you're right. Record authors should be able to specify a timeout but there's no reason to remove expired records from the network. Whether or not to _accept_ an expired record would be up to the client.
Most helpful comment
Is it really considered more dangerous than possibility of practically disappearing whole materials published under certain IPNS key if one (just one!) publisher node with its private key once disappears too? Doesn't this publisher node look like the central point of failure? Outdated, but _valid_ records are really worse than no records at all?
I think that ability to replay is not an critical security issue, at least in condition that user is explicitly notified that the obtained result could be outdated. After all, «it will always return _valid_ records (even if a bit stale)», as mentioned in 0.4.18 changelog.
So what do you think about
--show-publish-timeflag onipfs name resolvecommand? Do the IPNS records itself contain this data?