papers

From section 3.7.2 of the IPFS paper [1], on IPNS ("Human Friendly Names"): While IPNS is indeed a way of assigning and reassigning names, it is not very user friendly, as it exposes long hash values as names, which are notoriously hard to remember. These work for URLs, but not for many kinds of offline transmission. Thus, IPFS increases the user-friendliness of IPNS with the following techniques. [1] https://github.com/ipfs/papers/raw/master/ipfs-cap2pfs/ipfs-...

As for your first point, you should really first learn more about how IPFS handles content addressing. If you look at section 3.5 the paper[1], you see that a IPFS object consists of a free-form data field, and an arbitrary amount of links to other IPFS objects. This is a very flexible format that allows for caching. You talk about a page with comments. You could (this is an example) create three 'models': a Page, a PageBody and a Comment (which 'inherit' from IPFSObject). A Page would contain links to one PageBody and multiple Comment objects. Every time a comment is posted, a link is added to the Page object (so its hash changes), but the PageBody (where the majority of the page size presumably is) doesn't have to change. All peers can keep the same PageBody cached, while the latest Page contains all the desired comments. This caching m

We have IPNS, which allows you to have a mutable pointer to immutable content in ipfs. On top of that, you can put your IPNS name (which is still a longish ugly hash) into a DNS record to hide everything away (although youre still depending on DNS at that point) If you want to read more about ipns, its discussed in section 3.7 of the paper[1]. Do note that a few things have changed since the paper was last updated, so its not the source of truth right now. [1]: https://github.com/ipfs/papers/raw/master/ipfs-cap2pfs/ipfs-...

A PDF of paper quoted, 'IPFS - Toward The Permanent Web (DRAFT 1)', may be found here: https://github.com/ipfs/papers/blob/master/ipfs-ttpw/ipfs-to...