Yes, but depending on how it’s chunked and structured you would only be maintaining the diff blocks.
I really wish someone would clarify the current state of IPNS with regard to the pub/sub implementation. These are well known issues with the default IPNS implementation but I believe it’s not the case or at least not nearly as bad with the experimental pub/sub implementation. (it doesn’t help that it’s still listed as experimental).
I also really with evaluations of IPNS were made in comparison to DNS which would be a much better comparison and takes some time to propagate updates as well.
So IPNS used to have a LOT of issues due to problems with the DHT (issues publishing, looking up values etc.). The IPNS-pubsub thing was meant to help with that.
Now the DHT works wayyy better, with sub-second lookups and constant monitoring from Probelabs etc. I’d expect IPNS to work much better than it used it, but I haven’t tried it recently.
Any idea of what that means for the IPNS-pubsub implementation? (I remember reading something about pubsub being deprecated but I wasn’t clear on the details of that)
ipns-over-pubsub (opt-in feature behind Ipns.UsePubsub in Kubo, implementing IPNS PubSub Router spec) is a separate feature from “General purpose” ipfs pubsub commands. It is here to stay.
You can enable Ipns.UsePubsub today and have both DHT+Pubsub backends for IPNS. It is not enabled by default because of this remaining work (mainly, having some GC for unsubscribing from pubsub names that were not resolved for a while).
Deprecation of ipfs pubsub commands from Kubo RPC is not related to IPNS. Removal of “generic” pubsub commands was briefly considered in kubo#9717, but as noted in my last comment, no longer planned because we no longer have to maintain 1:1 interop of these commands with js-ipfs (sunset, replaced with Helia), and Kubo can improve own pubsub defaults in future releases.