Are there theorical limits to how frequently and how many total IPNS updates can be performed?

What happens if the IPNS record is updated every 1 second, or 1 minute, or 5 minutes, and the sequence number grows to tens of thousands or millions?

Will it still be possible to retrieve the current (or at least a recent) IPNS record via DHT? Or will the query take tens of minutes/hours and make it unusable?

Haven’t tested myself, but my understanding is the following:
IPNS will be propagated from peer to peer as soon as they are emited. Each peer will only keep the newest record and ignore the older ones (each IPNS has a timestamp) even if they receive them after the newest. Each peer will serve the newest record they know about, timestamp-wise.
When you request the latest IPNS record, you will ask several peers. IIRC IPFS will accept a record if 3 different peers say a particular record is the last one. I don’t know if it checks a signature from the IPNS key (I think not yet implemented, but it will in the future). I don’t know if it checks against the timestamp yet either.
So, i don’t know if you will end up with an outdated record (if you don’t check the date), or fail to fetch (because you always hear about a newer record, but never reach the threshold of 3).
To avoid problems, the time between updates should be much larger than the time it takes for records to propagate in the network (just like blockchain). I don’t know where the practical limit is as of now.
I think a better solution for frequently updated data would be to have a stable IPNS record pointing to DB like orbit-db or similar.

Maybe there’s some way to use PubSub to broadcast near realtime (at least as fast as PubSub can do) updates about IPNS which can arrive faster than the actual IPNS changes can propagate? I’m assuming it’s not a challenge to also be able to verify that the Pub event is authentic and came from the actual peer which owns the IPNS. This idea seems so obvious it makes me wonder if I’m totally missing something, like why this might be redundant or unable to achieve any performance advantage. I don’t know much about PubSub yet.

@wclayf with pubsub you can only get updates while you’re online and listening. Whereas with IPNS you can get a record that was last updated while you were offline, like weeks ago.

@estebanabaroa I was saying that if PubSub can achieve faster delivery than an IPNS update, then PubSub can be used in addition to IPNS updates to build more responsive systems. In other words the PubSub would just be broadcasting the new CID, which might arrive even faster than the IPNS update can complete, but you’d still be doing the actual IPNS updates too as the permanent source of truth.

Actually I think there is IPNS over PubSub as an experimental feature already, if I’m not mistaken. I forgot the obvious.

1 Like

Yes, there is:

An there is also unimplemented ideas around IPNS over DNS (with a big loss in decentralization, obviously).