Skip to content

I'm excited to announce that pyindieblog-micropub, my Micropub endpoint software, officially gained a name. It's now called Kittybox! (cat lovers of #IndieWeb, rejoice! @anomalily @aaronpk)

Also I'm almost ready to deploy another rewrite of its Micropub endpoint, now asynchronous. I only need Markdown parsing for feature parity...

Kittybox is hosted on GitLab here. It has a CI pipeline, Issues section is used as my itches list and when I get my Raspberry Pi 4 I'll set up a Kubernetes cluster and it will auto-update if all tests are green!

Architecture

FIrst of all, Kittybox is asynchronous. This means that my website should become a lot faster under load. The typical ?q=source request takes just 7 milliseconds on my laptop with a test database of several posts! (It should become a little bit slower if there are more posts, but it's mostly fairly efficient since it doesn't fetch posts that it doesn't need)

Second, it still stores posts in Redis. I'm considering migrating to MongoDB or try to somehow store posts in flat files, accelerated with Redis caching. The problem with flat files is lack of scalability; I'll need to exploit NFS mounting if I want to scale my app in a multi-node Kubernetes cluster. The problem with Redis is the complicated indexing - you probably don't want to look at RedisBackend class, it's a mess of raw Redis calls. The problem with MongoDB is - I have no idea how it works and how fast it is. I'll probably need to use a caching layer - Redis again could work really well!

Third, it now supports arbitrary URL schemes for posts, so I'm no longer limited to single inflexible URL scheme. I can just specify an arbitrary URL on my domain to post it to.

Fourth, I've finally implemented newBase60 slugs (thanks @tantek for the format)

Fifth: if frontend passes AUTH command in a KittyQL query, Kittybox will show private posts.

Itches

Settings and configuration

RIght now I'm thinking about configuration -- most notably syndication endpoints. I'd like to be able to configure them at runtime, but Micropub protocol doesn't have that feature and I'll need to implement it as a separate extension. Current variants of solving this issue are:

  1. Introduce a new "action" in POST requests - "config", that would allow me to dynamically modify syndication endpoints and some other stuff with the same add-replace-delete workflow.
  2. Get a /micropub/config endpoint that will implement its own API
  3. Try to somehow package this into a MF2-like post and store it at a well-known URI.

Nickname cache

Remember what I said about arbitrary URLs? It also stores arbitrary MF2 objects. This means I can cache other people's h-cards in there to use for a nickname cache! This can be used by the frontend app to show rich h-cards on mentions.

I'm planning to do that with a client app flow like this:

  1. Enter the URL in the box and a shortname for the person in the second one
  2. It gets fetched, and the h-card gets posted at `https://fireburn.ru/people/<shortname>`
  3. When I need to autocomplete, I could probably use a [KittyQL](https://fireburn.ru/posts/1574643184) query to get the full address book and complete the name!
  4. When it gets posted, my post pre-processor will automatically go through and add links and rich mini-h-cards to @mentions.