I wrote a spec for a SQLite-based todo database and just release version 0.1.

todo.txt is an obvious inspiration, but I wanted to put my data in SQLite for a couple of reasons:

• SQLite is very stable, nearly as stable as plain text.
• Having your todos in a database opens up possibilities for querying, viewing, and extending that data much more easily than if it's in plain text.
• Having the data in SQLite in particular means multiple apps can interact with the database simultaneously, so I can have a CLI, a web app, and automation scripts touching the same todo list without risking corruption or data loss.

Now that the database schema is ready I just have to build the rest of the app...

The schema (not counting a tagging extension) in full:

-- todo-sqlite3
-- https://github.com/nathanielknight/todo-sqlite3

-- Foreign Key constraints are required.
PRAGMA foreign_keys = ON;


-- Core Items table
CREATE TABLE items (
    id INTEGER PRIMARY KEY,
    -- Every item has a title (not necessarily unique)
    title TEXT NOT NULL,
    -- Body can be markdown, plaintext, asciidoc, etc.
    body TEXT,
    -- Items can be archived to support soft-deletion
    is_archived BOOLEAN NOT NULL DEFAULT 0,
    archived_status_changed_at TIMESTAMP,
    -- Items have automatically updating created_at and changed_at timestamps
    created_at TIMESTAMP NOT NULL DEFAULT (unixepoch('now', 'subsec')),
    changed_at TIMESTAMP NOT NULL DEFAULT (unixepoch('now', 'subsec'))
);

-- The changed_at and archived_status_changed_at fields are automatically updated.
CREATE TRIGGER update_items_changed_at 
AFTER UPDATE ON items
BEGIN
    UPDATE items SET changed_at = unixepoch('now', 'subsec')
    WHERE id = NEW.id;
END;

CREATE TRIGGER update_archived_status_timestamp
AFTER UPDATE OF is_archived ON items
WHEN NEW.is_archived != OLD.is_archived
BEGIN
    UPDATE items 
    SET archived_status_changed_at = unixepoch('now', 'subsec')
    WHERE id = NEW.id;
END;

I just released version 0.1 of a plugin for Simon Willison's llm called llm-questioncache. It lets you send questions to your default LLM with a system prompt that elicits short, to-the-point answers. It also maintains a cache of answers locally so that you only have to hit the LLM once for each bit of esoteric knowledge.

It uses embeddings of each question to find similar questions so that (for example) if you ask

How do you compare two branches in git

and

How to compare different branches in git

you'll get the same answer.

If you've already got LLM installed you can try it out with

llm install llm-questioncache

Here's the PyPI package: https://pypi.org/project/llm-questioncache/

And here's the source code: https://github.com/nathanielknight/llm-questioncache

I just published the first (v0.1.0) release of tiddly-wiki-server, which implements the TiddlyWiki WebServer API in Rust using Axum, SerDe, and TiddlyWiki.

Motivation

One might ask why a new TiddlyWiki server is necessary, since

• TiddlyWiki5 includes a first-party NodeJS web server, and
• one of TiddlyWiki's beautiful features is that it works as as static HTML file.

These are valid points. I confess, this project fulfills quite a narrow use case: I like to self-host my tools on a small, cheap VPS, and the first-party NodeJS server consumes about 100MB of RAM. This isn't huge, but it's a decent chunk of my available resources. This server consumes much less (about 10MB, and that's before I've done anything to optimize it).

This was also a project that let me combine two technologies that I like an awful lot, so if it seems self-indulgent, well... maybe it is.

Components

The server makes use of some very nice Crates; I'll mention some of the big ones:

axum, a web framework

I've tried a number of Rust web frameworks (Tide, Rocket, simple-http-server); this one's the first one I feel like I really understood and was productive with (though that might also just be that I'm slowly getting better at Rust). Of particular note is that Axum is compatible with tower-http , so many services and middlewares that you might want already exist.

rusqlite, a SQLite binding

I use SQLite for most of my tiny side projects; this one's no exception. The TiddlyWiki back end mostly treats tiddlers as opaque bags of objects, so the database is little more than a key-value store.

serde_json, a loosely-typed JSON interface

If you're reading about Rust you're probably familiar with serde, but since I wanted to retain TiddlyWiki's fairly open schema I needed an ergonomic way to work with un-typed JSON objects.

Future Work

There are lots of ways this project could be added or improved:

• More testing; I want this server to be feature-compatible with the first party server.
• User authentication and access control
• Streaming large responses to keep memory small

If any of that sounds interesting to you, pull requests and bug reports are very much welcome!