Thanks for the reponse, Mark!
I’m aware of the need of storaging it “somewhere”. However, is IPNS intrinsically worse at this than content-addressed info on IPFS?
My understanding is that if users of your app are accessing IPFS directly by becoming an IPFS node, and not just accessing through a gateway, then other IPFS nodes will contribute to the storage needs of the app, just like users of the app contribute to the storage needs of other IPFS users. Is this a wrong asumption?
Of course, I understand that there are no guarantees about the publicly stored data. Although I understand that if the node that publish some data is still online, then the data will be accessible (I assume that the network is not usually partitioned).
However, this is clearly a weak guarantee. Therefore, my next question would be, can some other user (in “twitter” for example a follower) pin the data?
Because, if the guarantee is that your data will be accessible if at least you or one of your “followers” are online, then, it’s highly likely it will.
Now to get an IPNS that is quick you want a given node to quickly be able to find another node that has your IPNS record. So you want your IPNS record to be stored by a lot of nodes.
I understand that the main problem of this, compared to IPFS, is that IPNS records are mutable, therefore, if you get the record, you may or may not have gotten the latest record, whereas in IPFS you get the data or you don’t (no stale info).
At the same time, I see an advantage of IPNS over IPFS, IPFS blocks can be “big”, but I assume IPNS records are really small, since they basically need to stored a signed object with a counter or timestamp (to know which records are the latest) and the CID of the target.
Just like I asked about application-level pinning of data, could an application manually pin IPNS record of other “users of interest” (same example, followers)?
The funny thing I see here is that pinning the data of your friends mostly requires what the app actually needs: you need to download the latest data from your followed accounts in order to show the timeline, so why not share it when another user requests it?
The problem I see is that something like this requires a big amount of IPNS resolutions (one per each followed user). And, as you pointed out, each IPNS resolution requires multiple requests to multiple hosts.
I guess that there is no perfect solution for this, as the problem is intrinsic to decentralized mutable state. But, I think that combining requests is the way to go, if you want to resolve 100 IPNS addresses of the 100 users you follow, chances are, many of these users will follow some of the other 99 users.