Welcome to version 3 of Krondor.Org!

Where are we now?

After the insights gained from v2, I recognized several key areas for improvement:

• Gas fees on Ethereum were prohibitively expensive for blog content management
• The need for a more robust and flexible content management system
• The desire for self-hosted infrastructure while maintaining decentralized capabilities

This led to the development of Leaky - a content-addressable CMS that maintains the distributed nature of my previous implementations while addressing their limitations.

What’s New in v3?

The major improvements in v3 include:

• Removal of blockchain dependencies in favor of pure IPFS-based content addressing
• A more sophisticated data model with directory-like structures
• Schema validation support for content metadata
• A clean separation of concerns between CLI, server, and common libraries
• A clean separation from CMS feature code and the curating / serving of content. All content is now managed with our new headless CMS and pulled via the frontend you’re using now.
• A more intuitive git-like interface for content management

Data Model

The v3 data model has evolved significantly from v2’s flat object structure. The system is built around four key concepts:

1. Nodes: Directory-like structures that can contain links to either other nodes or data objects. Each node can have:

   • Links to other nodes (for directories)
   • Links to data with optional metadata (for files)
   • A schema definition for validating metadata

2. Objects: Metadata containers that include:

   • Creation and update timestamps
   • Custom properties that can be validated against schemas
   • Flexible property types including strings, integers, floats, booleans, links, lists, and maps

3. Schemas: JSON Schema-like definitions that validate object metadata at the node level, supporting:

   • Type validation (string, integer, float, boolean, link, list, map)
   • Required field specifications
   • Property descriptions
   • Per-directory schema inheritance

4. Manifests: Version control structures containing:

   • A pointer to the root node
   • A link to the previous version
   • Build and version information

These data types are linked together by IPLD links and stored in IPFS as traversable DAGs. This allows for a more easily extensible and flexible data model that can be used to represent a wide variety of content.

Here’s an example JSON representation of how this all fits together:

{
  "type": "directory",
  "links": {
    "blog": {
      "type": "directory",
      "links": {
        "post.md": {
          "type": "file",
          "data": "<cid>",
          "metadata": {
            "created_at": "2024-01-01T00:00:00Z",
            "updated_at": "2024-01-02T00:00:00Z",
            "properties": {
              "title": "My First Post",
              "author": "John Doe",
              "tags": ["blog", "tech"]
            }
          }
        }
      },
      "schema": {
        "title": {
          "type": "string",
          "required": true
        },
        "author": {
          "type": "string",
          "required": true
        },
        "tags": {
          "type": "list",
          "required": false
        }
      }
    }
  }
}

This hierarchical structure offers several advantages over the previous version:

• Natural path-based content organization that maps directly to web URLs
• Rich metadata support with type validation at both directory and file levels
• Improved content discovery through directory traversal
• Better separation of content, metadata, and validation rules

Why the Changes?

The v2 implementation, while functional, had several limitations:

• Reliance on Ethereum made simple content updates expensive
• Flat object structure made content organization difficult
• Limited metadata validation capabilities
• Complex gateway traversal due to custom IPFS structures

Leaky addresses these issues by:

• Using pure IPFS for content addressing, removing blockchain dependencies
• Implementing a hierarchical structure that maps naturally to web paths
• Supporting schema validation for robust content management
• Providing a simple HTTP server for traditional web access

CLI Usage

The CLI interface maintains the git-like feel from v2, but with improved functionality:

# Initialize a new leaky project
leaky-cli init --remote https://leaky.krondor.org

# Add and commit content
echo "About us" > about.md
leaky-cli add -v
leaky-cli push

# Pull latest content
leaky-cli pull

Content is now accessible via both IPFS gateways and the Leaky server:

ipfs.io/ipfs/<root-cid>/about
# or
https://leaky.krondor.org/<root-cid>/about

What’s Next?

While v3 represents a significant improvement, there are still areas to explore:

• Enhanced caching and performance optimizations
• Support for more complex content types and relationships
• Implementation of a static site generator – rather than have this website you’re using stylize and format content, we should be able to do this natively with our new data model and server implementation

The move to a pure IPFS-based solution with a dedicated server component provides a solid foundation for these future improvements while maintaining the distributed nature that made the previous versions unique.

Hope you enjoyed this update on the evolution of krondor.org and the introduction of Leaky!