v2.0.0

Welcome to version 2 of Krondor.Org!

Where are we now?

For this iteration, I maintained the following insights from v1:

• If you can only work in one language, you should do so!
• Static site development with Leptos is a promising tool for building SPAs on IPFS
• My use case would really benefit from a dynamic content publishing solution With that in mind I recognized the need to start building my CMS. I had a working prototype from v0 of a distributed implementation built on Ethereum and IPFS. I decided to develop a v2 that implemented:
• A RootCid pointer on Ethereum
• An IPFS based content storage solution
• An object based data model with change tracking and arbitrary metadata for all my my content
• An easy to use CLI for managing blog content
• And a web-based viewing solution for making my content as portable as possible This would allow me to both reap the benefit of a CMS and keep my infrastructure distributed and interchangeable

Data model

I implemented on object-based data model that links the entirety of my content in a single piece of json data. Objects are denoted as such:

<path> : {
	cid: <object_cid>,
	created_at: <timestamp>,
	updated_at: <timestamp>,
	metadata: <json>
}

Semantically this enforces that objects are pieces of data, pointed at by a key, with deterministic hashes, and variable metadata. This makes it straightforward to account for changes by key-based lookups, and allows applications to consume arbitrary metadata about the content that they have access to. It also makes it simple to link to the content on IPFS if it’s available there.

All the objects on my site are pointed at by a Manifest:

{
	objects: {
		<path> : {
			cid: <object_cid>,
			created_at: <timestamp>,
			updated_at: <timestamp>,
			metadata: <json>
		}
	},
	previous_cid: <previous_manifest_cid>,
	version
}

This allows me to identify the entirety of my site’s content by pushing an instance of a Manifest to IPFS, which advertises it on the decentralized web with a CID.

I can either hand someone that CID directly and they should be able to link to all of my other content on IPFS, or I can publish it to Ethereum for a more lasting and public pointer that is signed by my advertised public key.

Why not just use unix-fs?

My implementation does not use UnixFs, which seems like it would have been a good choice. Not using UnixFs makes linking to content over IPFS gateways and the web more difficult, but not impossible. This was a headache when I was building my web app. But I went through with it because I did not want to have to deal with traversing UnixFs data, and I couldn’t extend UnixFs to use my variable metadata. It also kinda bugged me that MFS hashes aren’t deterministic, so I opted to avoid it all together.

CLI Usage

I designed the CLI to feel very similar to Git, since I essentially wanted to bring versioning to IPFS for my specific use case. After initializing my local device, I can interact with my infrastructure as a simple version controlled object store:

# Initialize a new space to pull and stage changes from in the current directory
krondor-org init
# Pull the latest content from Ipfs and update the local staging area
krondor-org pull
# Stage changes from the current directory against the local staging area
krondor-org stage
# You can also tag files with metadata that will be stored in the manifest
# Here are example tags that are used in the development environment setup
# Creates a new piece of 'audio' content
krondor-org tag --name audio --path audio/freak-mic-test.mp3 --value '{"title": "Freak on a Leash (Sample)", "project": "mic_test"}'
# Push the staged changes to Ipfs and update the RootCid contract
krondor-org --admin-key <YOUR_PRIVATE_KEY> push

Content is pushed to IPFS, and a new Manifest is published linking to all of it.

What would be better than this?

While the interface is moving in the right direction this iteration, building it has made me realize a few things:

• Gas fees on Ethereum are too high to justify publishing this blog on MainNet, it might be desirable to start pointing to my content with a tool like IPNS.
• Fleek might not be a great service for what I’m trying to do with my static site + CMS. If I can just host both my site and content with a basic IPFS api, that would be ideal.
• Maybe it’s time to start thinking about deploying my own server for this, as while I can still use distributed protocols for serving content, I would like to control hosting and publishing it.

Hope you enjoyed the read!