Questions bout hosting a static blog on IPFS

I am looking into hosting a simple static blog on IPFS. However, there are a few things I can´t get my head around in understanding IPFS which I hope somebody can clarify for me:

  1. Tutorials say that you have to just upload the entire folder on the blog with relative links to a node. That works but IPFS works with CIDs and hashes. How does a browser know what CID corresponds to for example css/main.css in a html file?
  2. How is uploading the entire blog folder every time there is an update scalable? When you just update 1 file, what is the point of re-adding the entire website folder? But if you upload file by file, I suppose you have to create all the ipns records yourself and replace all relative file links in the html files with these IPNS links right?
  3. The IPNS record is based on your public key. If the computer/node you are creating the IPNS records from gets destroyed, does that mean you have the create new IPNS records and the old onces cannot be updated anymore?
  4. In relation to 3, IPNS records have a 24 hour life span (and are linked to a specific node?). From a censorship perspective, if the initial node I published/pinned to (lets say pinata) gets blocked what does that mean for the IPNS records (and thus the ability to access the content). Lets say Node 1 gets blocked but I pinned the files on Node 2, do the files continue to live on AND am I still able to update the IPNS records?

Thanks in advance.

You don’t upload, you “add” things to your IPFS daemon. If you are using a 3rd party service like Piñata and that requires you you upload somewhere then that is not an IPFS thing itself, that is a 3rd party service. The HTTP gateway through which the website is accessed perfoms transaction from <root_cid>/css/main.css to <main_css_cid> server side. Or when using Helia/Service-worker (IPFS Service Worker Gateway | production@54f86b6) this can happen in the browser.

How is uploading the entire blog folder every time there is an update scalable? When you just update 1 file, what is the point of re-adding the entire website folder? But if you upload file by file, I suppose you have to create all the ipns records yourself and replace all relative file links in the html files with these IPNS links right?

I don’t know, how big is your blog that re-adding the full site bothers you? If the daemon you add-to has WriteThrough: false (kubo/docs/config.md at master · ipfs/kubo · GitHub) then the write of an existing block is skipped anyways. If it becomes a problem, you can always work via MFS (ipfs files) which is lazy loaded and allows to modify a subfolder-folder in an ipfs-DAG separately. I personally just re-add the whole folder every time because I can allow myself 2 extra seconds on deploy.

The IPNS record is based on your public key. If the computer/node you are creating the IPNS records from gets destroyed, does that mean you have the create new IPNS records and the old onces cannot be updated anymore?

See ipfs key –help. You can generate separate keys and ipfs name publish with them, and back them up or move them somewhere else.

You can re-publish the records anytime, however there might be old copies with old values pointing to the blocked host for a while. Depends a lot on how successful the republishing is when finding the nodes etc. Kubo etc would normally keep looking for providers when one doesn’t work so theoretically it should be able to locate an updated/working location eventually. Again, depends a lot on the quality of the peers involved and how well they are doing their job of announcing, responding to announcements, providing blocks etc etc.

Thanks for the quick answer, that helps. I have some followup remarks.

Interesting, what happens then if you are not using a HTTP gateway but an direct IPFS/IPNS link via your node (for example via the IPFS companion browser extension).

Well, this it not really about the blog but I was just thinking a bit ahead about scalability. A blog does not differ so much from a news site with the news site publishing multiple stories each day. That builds up quickly and means you have to republish the entire website several times a day just to publish an article.

Okay, but that means that somebody has to republish content if the source node is blocked, right? Or does pinning the content on other nodes keep the data AND IPNS records alive?

It’s possible, and even straightfoward, to build your tooling so you only import the files that are new/changed, and use ipfs files commands to place them inside directory try at the right location. It all depnds on how large your data set is and how often you update if it’s worth it.

Then the client does the traversal and retrieves block by block. I.e. fetches <root_cid>. Parses the block, see that it has a link named css with <css_cid>, fetchs <css_cid>, parses the block etc..

Yes, the other nodes should publish the ipns record from that point with the same key.

Thanks @hector and @Rashkae for the answers. It is clear now.

I think it’s worth pointing out that pinning the data and publishing the IPNS records are completely separate, and don’t have to be on the same node at all. There should only be 1 node publishing the IPNS record, but there can be multiple nodes pinning the data. Publishing the IPNS record would be a very lightweight task that can be done with practically any internet connection, as long as it can be left running continuously.