Gerard Klijs: tech

Gerard Klijs: tech https://blog.gklijs.tech/tech/2026 2026-10-23T14:00:00Z Gerard Klijs vados vados 0.3.0: dates, feeds and fewer scripts https://blog.gklijs.tech/tech/2026/vados-0-3-0 2026-10-23T14:00:00Z 2026-10-23T14:00:00Z

Dated posts, Atom feeds, link previews, inline icons and highlighted code: what vados gained since 0.1.0, and the scripts this blog could delete.

Three weeks ago I wrote that vados finally had a command line. Since then there have been two releases, 0.2.0 and now 0.3.0, and the second one is the one that made this blog simpler instead of just bigger. Before the release I did a dry run: I built the unreleased code and generated this blog with it next to the old version, then compared the output. That turned up a surprise in my own setup. Half of what the blog needed from scripts around vados is now vados's job, so those scripts are gone. <h2>Writing a blog</h2> A page can now have a <code>date</code>, and a section can list its pages by it with <code>childOrder: dateDesc</code>. A new post shows up first without renumbering anything. Until now I gave the newest post the lowest <code>order</code> and ran a Python script to rebuild the cards on the year page and the home page. That script is deleted. The home page now just says <code>"latest": { "from": "/tech", "limit": 4 }</code>, and a page can show the newest dated pages from anywhere on the site. The same dates drive Atom feeds. Set <code>"feed": true</code> on a section and vados publishes <code>feed.xml</code> with every post's summary and full content. For now a feed lists only the direct children of the page it is on. On this blog the posts sit one level down, under the year, so the feed lives at <a href="/tech/2026/feed.xml">/tech/2026/feed.xml</a>. I'd like it to look deeper, as <code>latest</code> already does. <h2>Being found</h2> <ul> <li>Link previews: <code>og:</code> and Twitter tags, canonical URLs, and a 1200×630 JPEG crop of the page's image, because LinkedIn doesn't reliably show WebP.</li> <li><code>sitemap.xml</code> and <code>robots.txt</code>, structured data for search engines, and the <code>rel="me"</code> and <code>fediverse:creator</code> tags Mastodon uses to verify you and credit you under a link.</li> <li>Every title now ends with the site's name, and every page has a proper <code><h1></code>.</li> </ul> Most of this needs one new line in <code>main.json</code>, the <code>siteUrl</code>, which is also why <code>vados check</code> now warns when it's missing. <h2>Faster pages</h2> Icons used to come from the Material Design Icons web font: about 400 KB of render-blocking CSS and font for a handful of icons. In 0.3.0 they're inlined as SVG. This blog used to run a Node script after every build to cut that font down to the icons I used. That script is gone as well. The hero image is fetched early, every <code><img></code> has its dimensions, and on phones the tiles and social icons no longer fight over the same space. Code blocks in Markdown are highlighted at build time now too, with a small stylesheet that is only linked on pages that have code. <h2>Between 0.1.0 and here</h2> 0.2.0 added a site description and a favicon, and the text vados puts on every page (skip link, navigation labels) now follows the site's language: English, Dutch, German, French or Spanish. It also fixed the breadcrumb announcing "page" instead of the page's title. <pre class="highlight"><code class="language-sh">cargo install vados </code></pre> <ul> <li>crates.io: <a href="https://crates.io/crates/vados">vados</a></li> <li>GitHub: <a href="https://github.com/gklijs/vados">gklijs/vados</a>, with the full <a href="https://github.com/gklijs/vados/blob/main/CHANGELOG.md">changelog</a></li> </ul> If you read this blog in a feed reader, you can now subscribe. That was the last thing it was missing. This blog is built with vados, too, and now with 0.3.0. Photo: <a href="/photos/2026/fort-in-the-grass">Fort in the grass</a>, by me. Thick walls, small windows and nothing running inside: roughly what I want from a static site, too. Skyhooks, cranes and a library I didn't write https://blog.gklijs.tech/tech/2026/skilj-and-security 2026-10-23T00:00:00Z 2026-10-23T00:00:00Z

Much of skilj was written by AI, and I don't know every bolt of it. What it prevents anyway, what it can't, and why agents only get a keyhole.

I don't know every nut and bolt of <a href="https://github.com/gklijs/SkilJ">skilj</a>. That's an odd thing to admit about a library I build and maintain on my own, and a worse one to admit in a post about security. But it's true, and the rest of this post doesn't make much sense without it. Much of skilj was written by Claude. I steer, I decide, I review, and I wrote very little of the code myself. Not because I had a principled plan, but because it was simply too tempting. When the code shows up faster than I can think about it, "I'll write it by hand to be sure" stops being a serious option. So I'm slightly uncomfortable, and I'd rather say so than write the usual paragraph about taking security very seriously. <h2>Skyhooks and cranes</h2> Daniel Dennett, in <a href="https://en.wikipedia.org/wiki/Darwin%27s_Dangerous_Idea">Darwin's Dangerous Idea</a>, makes a distinction between skyhooks and cranes. A skyhook lifts things from above, with nothing holding it up: a mind-first force that makes design something other than mechanism. A crane also lifts, but it stands on the ground, and you can see how it works. In software, the old skyhook was the author. The code is fine because the person who wrote it understood it. Review was a second person who understood it too. That was never fully true, but it was true enough that we built our habits on it. With AI writing the code, that skyhook is gone. Later, in <a href="https://philosophynow.org/issues/129/From_Bacteria_to_Bach_and_Back_by_Daniel_Dennett">From Bacteria to Bach and Back</a>, Dennett's phrase for it is "competence without comprehension". Termites build mounds that ventilate themselves, and no termite understands ventilation. A model that writes a correct access check is in a similar position. Searle would call it a <a href="https://plato.stanford.edu/entries/chinese-room/">Chinese Room</a>: symbols shuffled by rules, with no grasp of what they mean. Dennett argued that the room's pull comes from the details it leaves out, like how large the software would have to be. I'd like to think he's right about the model. At the end of a long day, I'm less sure about me. So it has to be cranes. Things that stand on the ground and can be checked: Tests. AI-written code needs proper tests, at the very least. The obvious problem is that the tests are also written by AI. A test that checks the wrong thing passes just as confidently as one that checks the right thing. Many entries in the design log say that a fix's test was seen failing without the fix, and what it did before. Karl Popper would recognise the idea as <a href="https://en.wikipedia.org/wiki/Falsifiability">falsifiability</a>: a theory that no observation could contradict isn't telling you anything, and neither is a test that no bug could make fail. It's the closest thing I have to a test for the tests. Tests that can't quietly not run. Many of the tests need Postgres. A test that skips because the database didn't answer looks exactly like a test that passed. CI <a href="https://github.com/gklijs/SkilJ/blob/main/docs/architecture.md#ci-silent-skip-guard">fails the build</a> if anything skipped. That guard <a href="https://github.com/gklijs/SkilJ/blob/main/docs/architecture.md#what-the-tests-cover">had a hole of its own</a>, by the way, which is roughly the point of this post. <a href="https://github.com/gklijs/SkilJ/blob/main/specs/skilj.allium">A spec</a> separate from the code, which says what the system guarantees. The design log records an <code>allium check</code> after changes to it. A design log. <a href="https://github.com/gklijs/SkilJ/blob/main/docs/architecture.md"><code>docs/architecture.md</code></a> runs to section 225. In Plato's <a href="https://websites.umich.edu/~lsarth/filecabinet/PlatoOnWriting.html">Phaedrus</a>, Socrates tells of a king who warns that writing gives the appearance of wisdom rather than wisdom itself. Socrates adds that a text can't defend itself when you question it. He would have had opinions about generated code. The design log is my attempt at something that does answer back. Ask it why something is the way it is, and it tells you: every decision has its reasoning, and each fix says what was wrong. I have not read all of it in one go, and I'm not sure anyone has. (We only know about Socrates' story because Plato wrote it down, which I choose to read as permission.) A list of what nothing checks. <a href="https://github.com/gklijs/SkilJ/blob/main/CONTRIBUTING.md#what-the-tests-do-and-dont-verify"><code>CONTRIBUTING.md</code></a> sorts the guarantees into three piles: what holds by construction, what tests verify, and what nothing verifies. That last pile is short, and I'm more proud of it existing than of anything in the other two. None of that removes the real limit, which is me. There is only so much code you can review in a day, and an AI does not get tired before you do. <h2>The blind watchmaker reads your code too</h2> Richard Dawkins called natural selection <a href="https://en.wikipedia.org/wiki/The_Blind_Watchmaker">"the blind watchmaker"</a>: it produces things that look designed, without seeing ahead or understanding what it makes. I find that a fair description of how a lot of code gets written now. It's also, less comfortably, a fair description of how a lot of code gets attacked. Nobody needs to understand your codebase anymore to find the place where the authorization check and the query disagree. They can ask a model to look, and it will read a surprising amount of it without complaint. That cuts both ways, and in skilj's case I've mostly been on the friendly side of it. The bugs I caught myself were mostly about naming and about whether an API made sense to use. Some of the security bugs came out of review passes, one of them an automated review of code a model had written. Some examples: <ul> <li>A caller allowed to submit commands, but not to read events, could submit a command it knew would be rejected. The rejection helpfully listed every event the decision had looked at. Read access, one deliberate failure at a time. (<a href="https://github.com/gklijs/SkilJ/blob/main/docs/architecture.md#ultra-review-fixes">§18</a>)</li> <li>In a bounded context shared by several tenants, a caller with read access could query another tenant's projection by key. Closing that properly took <a href="https://github.com/gklijs/SkilJ/blob/main/docs/architecture.md#cross-tenant-projection-read-fix-owner-tag">six sections of the log</a>, because once you add owner scoping to one door, you have to find all the other doors.</li> <li>A server error used to answer with Postgres' own text, like <code>relation "bc_acme_corp.events" does not exist</code>. Each bounded context has its own schema, so that message tells a stranger your tenant names and your table layout. (<a href="https://github.com/gklijs/SkilJ/blob/main/docs/architecture.md#database-error-logging">§93</a>)</li> <li>The one-time secret for creating the first superadmin stayed valid in memory. Revoke every superadmin, and on any process that hadn't restarted since, whoever had read the startup log days earlier could claim the deployment again. (<a href="https://github.com/gklijs/SkilJ/blob/main/docs/architecture.md#bootstrap-secret-first-claim">§109</a>)</li> </ul> So I think skilj is more secure than it would have been if I had written it alone in the same time. But the bar isn't "better than me alone". skilj is about storing data, often personal data, and it's open source, so anyone with a model and an afternoon can go through it. That bar is a lot higher, and I can't honestly say it's cleared until someone other than me and my tools has tried. <h2>What skilj does prevent</h2> The guarantee I trust most is the one that holds by construction, whatever the tests do. No command sneaks past its consistency check. All commands of a bounded context are decided under one Postgres row lock, and the check, the events and the idempotency key commit or roll back together. Two people racing for the last seat don't both get it. <a href="/tech/2026/why-skilj-has-no-aggregates">Why skilj has no aggregates</a> goes into how that works. The rest is ordinary code with tests behind it, which, as established, is a crane and not a skyhook: <ul> <li>Callers don't see what they can't use. Each caller gets a GraphQL schema <a href="https://github.com/gklijs/SkilJ/blob/main/docs/architecture.md#caller-scoped-schema">built from their own grants</a>, so another tenant's types don't even exist for them. Before that, a query that merely mentioned a type would pass or fail validation depending on whether it existed, which is a very polite way of handing out the tenant list.</li> <li>Requests are <a href="https://github.com/gklijs/SkilJ/blob/main/docs/architecture.md#graphql-body-cap">bounded</a>. Body size, query depth and complexity, aliases, page sizes, subscriptions per websocket. One query that reads everything stopped working a while ago.</li> <li>JWTs are checked properly: issuer, <a href="https://github.com/gklijs/SkilJ/blob/main/docs/architecture.md#jwt-audience-required">audience</a>, algorithm, expiry and <a href="https://github.com/gklijs/SkilJ/blob/main/docs/architecture.md#jwt-nbf-check">not-before</a>. The not-before check was missing, so a token meant for next week worked fine today.</li> </ul> Then there's personal data, which is where an event log is at its most awkward. Events are supposed to be immutable, and people have the <a href="https://en.wikipedia.org/wiki/Right_to_be_forgotten">right to be forgotten</a>. <ul> <li>Sensitive fields are encrypted per person. <code>forgetSubject</code> destroys that person's key, and their fields become noise while the rest of history stays intact. This is called <a href="https://en.wikipedia.org/wiki/Crypto-shredding">crypto-shredding</a>.</li> <li><a href="https://github.com/gklijs/SkilJ/blob/main/docs/architecture.md#private-fields-third-protection">Private fields</a> are stored as is, but redacted on every event and command read for anyone not entitled to them.</li> <li><a href="https://github.com/gklijs/SkilJ/blob/main/docs/architecture.md#blind-tags">Blind tags</a> enforce "one account per email address" without storing the address. The tag is a keyed hash of the normalized value, with a separate key per constraint, so hashes can't be joined across bounded contexts. If the key leaks, it <a href="https://github.com/gklijs/SkilJ/blob/main/docs/architecture.md#blind-index-key-rotation">can be rotated</a>, and skilj re-wraps every stored hash without needing the original values. It's the one place in skilj where being blind is the feature.</li> <li><a href="https://github.com/gklijs/SkilJ/blob/main/docs/architecture.md#211-secrets-rotatable-credentials-an-adapter-fetches-never-a-normal-read">Secrets</a>, like an adapter's OAuth refresh token, are never returned by a normal query. Only the one adapter granted the secret can fetch it, and rotating it destroys the old version's key in the same transaction.</li> </ul> <h2>Agents get a keyhole, not a key</h2> One part of skilj was designed with AI on the calling side. I saw the need for an agent that can operate on specific data, and only that. Giving an agent direct access to a database is risky, because an agent is not deterministic. The same prompt can do something sensible a hundred times and something creative the hundred-and-first. Nietzsche wrote in his notebooks that there are no facts, only <a href="https://en.wikipedia.org/wiki/Perspectivism">interpretations</a>. For a language model that isn't a provocation. It's a description of the job. Whatever text reaches the agent, a ticket, an email, a web page, gets interpreted, and some of that text was written by someone hoping for a particular interpretation. So the REST API <a href="https://github.com/gklijs/SkilJ/blob/main/docs/architecture.md#rest-wire-contract">exists for narrowly scoped callers</a>. A token is scoped to exactly one registered type: one command it may submit, or one kind of event it may read or create. It can be scoped to one owner as well. An agent that handles refund requests can ask for refunds, for that customer, and do nothing else. It can't browse, it can't query around, and it can't write SQL, however politely it's asked to. That limits the blast radius. It does not limit intent. If an agent reads a cleverly worded support ticket and decides a refund is in order, and its token allows refunds, skilj accepts the refund. I don't know of a technical fix for <a href="https://genai.owasp.org/">prompt injection</a>, and I'm not going to pretend skilj has one. What it has is <a href="https://github.com/gklijs/SkilJ/blob/main/docs/architecture.md#214-generic-command-approval-issue-98">command approval</a>: a command type can require that a submission is a proposal, which someone else approves. The agent may ask; another account decides. It's <a href="https://en.wikipedia.org/wiki/Separation_of_duties">separation of duties</a>, which is old, and which nobody had to invent for AI. <h2>What skilj can't prevent</h2> Popper also wrote that our knowledge can only be finite, while our ignorance must necessarily be infinite. I can't list the infinite part. This is the finite part I know about. Your <code>decide()</code> function. skilj makes sure a command is decided against the right events, atomically. Whether the decision is right is your code. If it lets someone withdraw more than their balance, skilj will record that mistake with perfect consistency. A stolen token. skilj checks that a token was issued by an IdP you trust. Whether the person holding it is the person it was issued to is outside what any library can see. Dennett's last public worries were about <a href="https://www.theatlantic.com/technology/archive/2023/05/problem-counterfeit-people/674075/">counterfeit people</a>: AI convincing enough to pass for a real person. A convincing voice on the phone talking a helpdesk into resetting an account never reaches skilj as anything but a valid token. Backups from before someone was forgotten. Crypto-shredding destroys a key in the live database. Last week's backup still has it, wrapped under the master key. With both, the forgotten person is remembered again. Blind tags have the same shape: rotating a leaked key protects every copy taken after the rotation. With the leaked key and an older copy, an attacker can hash guesses and look them up, and email addresses are unfortunately very guessable. Private fields in your projections. Redaction happens when events are read. A projection folds events as they are stored, so if its state keeps a private field, every reader of the projection gets it. skilj <a href="https://github.com/gklijs/SkilJ/blob/main/docs/architecture.md#advertised-vs-enforced">warns at startup</a> for every projection that consumes one, because sometimes a staff-only view needs it. A warning is a nudge, not a wall. SQL at compile time. Each bounded context has its own Postgres schema, so table names are only known at runtime, and the compile-time checked queries of <a href="https://github.com/launchbadge/sqlx"><code>sqlx</code></a> can't be used. That's over 300 statements built with <code>format!</code>. What gets formatted in is the schema name, which is validated and quoted, but a misspelled column compiles fine and fails when it runs. The Postgres suites are the only check. A mixed-version rollout. Add a blind tag while an older skilj version is still running, and that older instance doesn't know the tag should be hashed. It stores the value in the clear. None of the startup checks can catch it, because the old version predates them (<a href="https://github.com/gklijs/SkilJ/blob/main/docs/architecture.md#blind-tags">§205</a>). Dependencies. <a href="https://github.com/EmbarkStudios/cargo-deny"><code>cargo deny</code></a> fails CI on every known <a href="https://rustsec.org/">advisory</a>. The unknown ones are, so far, unknown. Your database superuser with your master key. They can read everything. That's less a limitation of skilj than a description of what those two things are. And an audit. skilj is <a href="https://github.com/gklijs/SkilJ/blob/main/README.md#status-and-stability">pre-1.0</a>, has one maintainer, and has had no independent security audit. A lot of review, much of it written down, but nobody has been paid to break it. <h2>Making good mistakes</h2> Dennett wrote in <a href="https://www.themarginalian.org/2013/05/29/intuition-pumps-daniel-dennett-on-making-mistakes/">Intuition Pumps</a> that the chief trick to making good mistakes is not to hide them, especially not from yourself. The <a href="https://github.com/gklijs/SkilJ/blob/main/docs/architecture.md">design log</a> is, for a large part, a list of my mistakes and Claude's, and I've stopped trying to tell which was whose. What matters is that each one is written down, with its fix, and where the log can show it, a test that failed before the fix, so the same mistake has to find a new way in. If you find one that isn't written down yet, I'd like to hear about it. If it's a real hole, please use <a href="https://github.com/gklijs/SkilJ/security/advisories/new">GitHub's private vulnerability reporting</a> rather than an issue. I'll write it into the log either way, and credit you there if you want the credit. Photo: <a href="/photos/2026/batman-grappling-gun">Batman, grappling gun</a>, by me. He also works alone, and has also never been audited. Why skilj has no aggregates https://blog.gklijs.tech/tech/2026/why-skilj-has-no-aggregates 2026-10-22T12:00:00Z 2026-10-22T12:00:00Z

Dynamic Consistency Boundaries instead of aggregates: how skilj checks a rule that spans a student and a course in one decision, and what it costs.

<a href="https://github.com/gklijs/SkilJ">skilj</a> is a Rust library for building event-sourced applications on Postgres, and 0.1 was just released. Most event-sourcing libraries are built around aggregates. skilj has none. This post explains why, using one example that aggregates handle badly. <h2>The example: enrolling a student in a course</h2> We have two rules: <ol> <li>A course never has more students than its capacity.</li> <li>A student is never enrolled in more than three courses at once.</li> </ol> The command is <code>EnrollStudentInCourse { student_id, course_id }</code>. With aggregates, you first choose your consistency boundaries. You would naturally get a <code>Course</code> aggregate and a <code>Student</code> aggregate, each with its own event stream, and each able to guarantee only its own invariants. Rule 1 belongs to <code>Course</code> and rule 2 belongs to <code>Student</code>. A single enrolment has to satisfy both, and no single transaction can see both streams. That leaves the usual options, and each has a cost: <ul> <li>A saga or process manager. Reserve a seat on the course, then check the student, and release the seat if the student is already at three. That means two writes, a temporary state that other readers can see, and compensation logic you have to get right.</li> <li>A bigger aggregate. Make <code>Enrolment</code> or <code>School</code> the aggregate. Now every enrolment in the whole school competes for one stream, and every command replays a history that is mostly unrelated to it.</li> <li>Give up on one rule. Check the student limit against a read model and accept that it will occasionally be wrong.</li> </ul> None of these is a domain decision. They are workarounds for a modelling choice that had to be made before you knew which rules you would need. <h2>Dynamic Consistency Boundaries</h2> Sara Pellegrini and Milan Savić named the alternative <a href="https://dcb.events">Dynamic Consistency Boundaries</a> (DCB). Events are not appended to a stream that belongs to an entity. Instead they go into one log per bounded context, and each event carries tags. A <code>StudentEnrolled</code> event is tagged with both <code>student: s1</code> and <code>course: c7</code>. A command says which tags it needs. Its decision is then made against every earlier event that carries one of those tags. That is exactly the history the command depends on: no more, and no less. In skilj the enrolment looks like this (trimmed from <a href="https://github.com/gklijs/SkilJ/blob/main/skilj-demo/src/courses.rs"><code>skilj-demo/src/courses.rs</code></a>): <pre class="highlight"><code class="language-rust">impl CommandType for EnrollStudentInCourse { type Payload = EnrollStudentInCoursePayload; type Event = CoursesEvent; const NAME: &'static str = "EnrollStudentInCourse"; // Ask for both histories: this student's and this course's. fn tag_mappings() -> Vec<TagMapping> { vec![ TagMapping::new("student", "student_id"), TagMapping::new("course", "course_id"), ] } fn decide(payload: &Self::Payload, matching_events: &[Self::Event]) -> CommandDecision { let Some(capacity) = course_capacity(matching_events, &payload.course_id) else { return reject("course_not_found"); }; let roster = active_students_in_course(matching_events, &payload.course_id); if roster.len() as i64 >= capacity { return reject("course_full"); } let schedule = active_courses_for_student(matching_events, &payload.student_id); if schedule.len() >= MAX_ACTIVE_COURSES_PER_STUDENT { return reject("student_course_limit_reached"); } accept("StudentEnrolled", &payload) } } </code></pre> <code>decide</code> is a pure function. It gets the union of one student's history and one course's history, checks both rules, and returns either the events to append or a rejection. There is no saga, no reservation and no compensation. The command that needs both facts simply asks for both. Other commands ask for less. <code>OpenCourse</code> only needs the <code>course</code> tag. An enrolment of a different student in a different course shares no events with this one and never reads them. The boundary is defined per command, which is what "dynamic" means here. Uniqueness rules, such as "an email address can be registered once", follow the same pattern. The command asks for the <code>email</code> tag and rejects if any event already has it. You don't need a unique index or a reservation table. (skilj can also make that tag a keyed hash, so the address is never stored in the clear, but that deserves its own post.) <h2>How skilj keeps it atomic</h2> A pure <code>decide</code> function is only half of the story. Two enrolments racing for the last seat must not both be accepted. The DCB specification describes an optimistic approach: you append with a condition that says "fail if any event matching my query was added after position N", and retry if it fails. skilj chooses something simpler. All commands for one bounded context are serialized through a single Postgres row lock. While a command holds the lock, skilj reads its matching events, runs <code>decide</code>, appends the result with a gapless sequence number, and commits. Because nothing can interleave, there is no conflict to detect and nothing to retry. skilj's test suite races two enrolments for the last seat to check this. Serializing commands sounds slow, and there is a ceiling, so here it is. Concurrent commands are group-committed: callers queue up, one of them takes the lock and decides the whole batch, and commits once. Under load the batches grow, so the lock cost is shared. On a development machine, one bounded context handles roughly 400 to 850 commands per second when commands touch different entities, and around 100 per second when every command hits the same entity with a growing history. Snapshots help with the second case. The full numbers and method are in <a href="https://github.com/gklijs/SkilJ/blob/main/docs/performance.md"><code>docs/performance.md</code></a>. Different bounded contexts never share a lock, so the real lever is to split unrelated domains or tenants into separate contexts. If one context needs thousands of commands per second, skilj is not the right tool, and the README says so. <h2>What you get on top</h2> The tags make the rest of the library easier to build: <ul> <li>GraphQL and REST APIs generated from the registered event and command types. Each caller's GraphQL schema only contains what their grants allow, and it can act as an Apollo Federation subgraph.</li> <li>Projections and snapshots for reads, so queries don't have to replay events.</li> <li>Personal data handling. Sensitive fields are encrypted per subject, and <code>forgetSubject</code> makes them unreadable without rewriting the log.</li> <li>The things every event-sourced system ends up building: deadlines, idempotency keys, upcasting, command approval, parked deliveries with redrive, and bridges to Kafka, AMQP 1.0, NATS JetStream and Temporal.</li> </ul> All of it runs on one Postgres database. There is no separate event store to operate. <h2>Try it</h2> You only need Rust. The template starts its own embedded Postgres: <pre class="highlight"><code class="language-sh">cargo install cargo-generate cargo generate --git https://github.com/gklijs/SkilJ.git templates/skilj-template --name my-wallet cd my-wallet && cargo run --bin server </code></pre> It prints commands you can paste to make a deposit, see an overdraft rejected, and query the balance. skilj is pre-1.0 and has one maintainer. Releases follow semver the way Cargo does, and schema upgrades are automatic and forward-only. I'd like to hear where the API feels wrong, which features are missing, and whether DCB works for your domain. Issues and discussions are open at <a href="https://github.com/gklijs/SkilJ">github.com/gklijs/SkilJ</a>. A note on the name: skilj is an anagram of my last name, Klijs. In Swedish, "skilja" means to separate, which turned out to describe the design: each command is decided apart from everything it doesn't touch. Photo: <a href="/photos/2026/sun-on-the-water">Sun on the water</a>, by me. schema_registry_converter 6.0 https://blog.gklijs.tech/tech/2026/schema-registry-converter-6 2026-10-22T09:00:00Z 2026-10-22T09:00:00Z

Eight years after 0.1.0, the Rust crate for Kafka's Schema Registry gets its biggest update: runtime Protobuf encoding, schema ids in headers, and 7.5 million downloads.

Originally posted on LinkedIn on 22 October 2026. Eight years ago I published version 0.1.0 of a small Rust crate. It solved one problem: reading Kafka messages that a Java service had encoded with Confluent Schema Registry. Today I released 6.0.0, the biggest update since that first version. Some numbers I didn't expect when I started: <ul> <li>7.5 million downloads on crates.io, 1.4 million of them in the last 90 days</li> <li>546 GitHub repositories depend on it, plus 10 published crates</li> <li>27 contributors and 28 releases since 2018</li> </ul> <h2>Why use a schema registry?</h2> Kafka itself doesn't care what you put in a message; to Kafka it's just bytes. That's great for throughput, but it means the producer and every consumer have to agree on the format, usually without talking to each other. A schema registry turns that agreement into something you can check: <ul> <li>Each message carries a small schema id, so the full schema doesn't travel with every record.</li> <li>Compatibility rules reject a breaking change before it reaches production, not after a consumer starts failing.</li> <li>Avro, Protobuf and JSON Schema all work, so teams can keep the format they already use.</li> <li>A Rust service and a Java service can read each other's data with no glue code.</li> </ul> <h2>What's new in 6.0</h2> <ul> <li>A new <code>ProtoEncoder</code> for Protobuf messages that are only known at runtime. It can also encode straight from JSON.</li> <li>Protobuf decoding is rebuilt on protox and prost-reflect.</li> <li>JSON Schema validation now uses the jsonschema crate, with compiled validators cached.</li> <li>The schema id can be read from and written to Kafka headers everywhere, not only in the payload.</li> <li>A declared minimum Rust version (1.88), and the crate is on the 2024 edition.</li> </ul> It's a major release, so there are breaking changes. The release notes have a short "Upgrading from 5.x" section. Thanks to everyone who filed an issue, sent a PR or just used it in production. If you run Kafka with Rust, I'd love to hear what you're building. <ul> <li>GitHub: <a href="https://github.com/gklijs/schema_registry_converter">gklijs/schema_registry_converter</a></li> <li>crates.io: <a href="https://crates.io/crates/schema_registry_converter">schema_registry_converter</a></li> </ul> Photo: <a href="/photos/2026/train-in-a-hurry">Train in a hurry</a>, by me. skilj 0.1.0: separating things, on purpose https://blog.gklijs.tech/tech/2026/skilj-0-1-0 2026-10-19T00:00:00Z 2026-10-19T00:00:00Z

The first skilj release with a compatibility promise, what it does, why the name fits, and an honest word on where it stands.

Originally published as a LinkedIn article on 19 October 2026. The code has since moved from Codeberg to GitHub; the links are updated. I tagged skilj 0.1.0 today. After a long run of 0.0.x releases that came with no promises at all, this is the first version where I'm willing to say: upgrades within 0.1 won't break your code. So, what is it? skilj is a Rust library for building event-sourced applications on top of Postgres. You describe your domain as events (things that happened) and commands (requests to make something happen), and skilj takes care of storage, consistency, and serving it all over GraphQL and REST. First, the name, because people ask. It's an anagram of my last name, Klijs. I only found out later that skilja is Swedish for "to separate". I'm taking that as a sign, because separating things is pretty much the whole design. Commands are kept apart from the history they don't care about. Most event sourcing libraries make you pick an aggregate up front, an Account or an Order, and every command replays that aggregate's full history. skilj uses a Dynamic Consistency Boundary instead: events carry tags, and a command is checked against exactly the events that share its tags. Enrolling a student in a course can check both the student and the course in one atomic decision, without either of them having to "own" the other. No more arguing in a meeting room about which aggregate a feature belongs to. (You can still argue about naming. I can't fix everything.) Personal data is kept apart from the event log. Sensitive fields are encrypted per person, so when someone asks to be forgotten, you throw away their key and their data turns into noise, while the rest of history stays intact. There are also "blind" tags, so you can enforce things like "one account per email address" without ever storing the email address in plain text. And reads are kept apart from writes, with projections, snapshots and the rest. On top of that it generates the APIs from your types. The GraphQL schema is tailored to whoever is calling, it can act as an Apollo Federation subgraph, and there are live subscriptions. And there's a list of things you usually end up building yourself: deadlines and recurring schedules, idempotency keys, command approval with a second pair of eyes, upcasting old events, parking failed deliveries so you can retry them, and bridges to Kafka, AMQP, NATS JetStream and Temporal. All of it lives in one library on one Postgres database. No extra event store to run, patch and get paged about at 3am. Some numbers from the road to 0.1: <ul> <li>15 crates published to crates.io</li> <li>a design log in the repo that is now at section 221, with the reasoning behind each decision, including the ones I got wrong first</li> <li>one target directory that grew to 187 GB this week and filled my disk in the middle of release prep. Rust compile times are a lifestyle.</li> </ul> To be honest about where it stands: it's pre-1.0, it's built and maintained by one person, and it hasn't had an independent security audit. What 0.1 does promise is semantic versioning, automatic database upgrades (tested all the way back to the very first release's schema), and a minimum Rust version that's checked in CI. If you want to kick the tires, this gives you a running project with a small wallet example: <pre class="highlight"><code class="language-sh">cargo generate --git https://github.com/gklijs/SkilJ.git templates/skilj-template </code></pre> Feedback, issues, and "why on earth did you do it like this" questions are all very welcome. <ul> <li>GitHub: <a href="https://github.com/gklijs/SkilJ">gklijs/SkilJ</a></li> <li>crates.io: <a href="https://crates.io/crates/skilj">skilj</a></li> </ul> Photo: <a href="/photos/2026/path-through-the-trees">Path through the trees</a>, by me. Tiered storage for a DCB event store? https://blog.gklijs.tech/tech/2026/tiered-storage-for-dcb 2026-10-14T00:00:00Z 2026-10-14T00:00:00Z

Measurements on moving old event payloads to S3, why DCB keeps the tag index hot forever, and an open question on when an event can go cold.

Originally posted as a question to the DCB community on 14 October 2026. The issue it links has since moved from Codeberg to GitHub, with the same number. I'm working on skilj, a Rust event store on Postgres built around DCB. I've been exploring moving old event payloads to object storage such as S3, because an event store only grows. In DCB the hard part is clear: a consistency query has to see every matching event forever. A uniqueness claim from five years ago still decides today's command. So the tag index has to stay hot, and only payloads can move. I measured it with 200k events, two tags each, on Postgres: <ul> <li>~100 B payloads: only 16% of the storage could move, so it's not worth it</li> <li>~1 KB: 57%</li> <li>~4 KB: 65%</li> <li>about 500–800 bytes per event stay hot whatever the payload size (row, indexes, tag index)</li> </ul> The open question is when an event can safely go cold. Age or event count is easy, but it hurts long-lived tags: a command deciding on an old account would fetch its whole history from S3. My current thinking is that an event is cold once every query that can match it is covered, by a snapshot past it or by a "latest only" query item that a newer event answers. I'm curious: <ul> <li>Has anyone hit storage limits with a DCB store, or is it more about backups and vacuum?</li> <li>How do other DCB implementations handle very long-lived tags: snapshots, or something else?</li> <li>Any other approach I'm missing?</li> </ul> The write-up with the numbers, a design sketch and what KurrentDB, Kafka and Axon do is in <a href="https://github.com/gklijs/SkilJ/issues/92">skilj issue #92</a>. Nothing is built yet, so all ideas are welcome, including "don't". Photo: <a href="/photos/2026/floor-after-floor">Floor after floor</a>, by me. skilj 0.0.10 speaks Federation https://blog.gklijs.tech/tech/2026/skilj-0-0-10-federation 2026-10-11T00:00:00Z 2026-10-11T00:00:00Z

skilj joins a supergraph as an Apollo Federation v2 subgraph, with consistency queries, 25-50x faster catch-up and database epochs.

Originally posted on LinkedIn on 11 October 2026. The code has since moved from Codeberg to GitHub; the link is updated. Apollo held their summit last week and everyone came home talking supergraphs. Our timing was good: in this release skilj's GraphQL endpoint can join a supergraph as an Apollo Federation v2 subgraph. Quick refresher: skilj is an event-sourcing framework in Rust on Postgres. You define commands and events, and you get GraphQL and REST APIs, projections, snapshots and messaging bridges. <h2>Federation v2</h2> <ul> <li>Plugs into Apollo Router (2 and the 3.0 preview), Hive Router or Gateway, Cosmo, or schema stitching.</li> <li>Projections become entities, and each lookup is checked against the caller's own permissions.</li> <li>CI composes the schema with both Apollo's and Hive's composition on every build.</li> </ul> <h2>Commands read only what they need (Dynamic Consistency Boundaries)</h2> <ul> <li>Consistency queries: a command names exactly the events its decision depends on.</li> <li><code>nothing()</code>: for commands that need no history. On one hot account that took us from 110–160 to 2,500–5,000 commands/s.</li> <li>Snapshots as query items: a transfer between two accounts can decide on a snapshot of each.</li> <li>New warnings for slow reads and slow decides, with defaults taken from our benchmarks, so you find out before your users do.</li> </ul> <h2>Speed</h2> <ul> <li>Projection catch-up is 25–50× faster.</li> <li>Fewer round trips and no connection ping per command. With 1 ms to Postgres, a single caller went from 46 to about 26 ms per command.</li> <li>Batches are written as sets, and sync projections fold a whole batch at once.</li> <li>A small Kafka producer setting (<code>linger.ms=0</code>) takes outbound from about 165 to about 2,000 events/s.</li> </ul> <h2>Safety</h2> <ul> <li>Database epochs: after a failover or restore, a stale position is refused instead of quietly skipping events.</li> <li>Per-message idempotency keys, so NATS and AMQP redeliveries are no longer lost.</li> <li>Command dry-runs: see what a command would decide without persisting anything.</li> <li>A conformance suite that checks GraphQL and REST give the same answers.</li> </ul> Plus a pile of fixes, new benchmarks and deployment guidance in <code>docs/performance.md</code>. We're still at 0.0.x, so some things broke: <code>nextCursor</code> on <code>GET /v1/events</code> is now an opaque string, <code>submit_command</code> takes snapshot states, and a few signatures changed in <code>skilj-graphql</code> and <code>skilj-bridge</code>. Read the CHANGELOG before you upgrade. All 15 crates are on crates.io, and the code is at <a href="https://github.com/gklijs/SkilJ">gklijs/SkilJ</a>. Photo: <a href="/photos/2026/where-the-roads-meet-the-sea">Where the roads meet the sea</a>, by me. vados 0.1.0: now you can run it https://blog.gklijs.tech/tech/2026/vados-0-1-0 2026-10-07T00:00:00Z 2026-10-07T00:00:00Z

Four years after shipping a static site generator without a binary, vados gets a command line: init, check and authoring commands.

Originally posted on LinkedIn on 7 October 2026. Four years ago I published vados 0.0.3 to crates.io. It was a static site generator you couldn't actually run, because I'd only shipped the library. No binary. Just vibes. Today I'm fixing that with vados 0.1.0. Some background: the project's built around Bulma (the CSS framework), and Bulma is also a Dragon Ball character. So I went looking for the fastest Dragon Ball character and found Vados, who can destroy and recreate entire planets. Turns out that's basically what a static site generator does to your output folder every build. Naming things is hard, so I let anime do it. What's new: <ul> <li><code>vados init</code> sets up a new site, ready to deploy on Netlify.</li> <li><code>vados check</code> tells you everything that's wrong with your site before your visitors do.</li> <li>Commands to add pages, images, menu items and social links without hand-editing JSON. My favourite kind of JSON is the kind I don't type.</li> <li>Accessibility built in: skip links, landmarks, labels on every icon button, and alt text is required, not optional.</li> <li>Luma integration, so you can embed an event or a register button on a page. I built this before I even had a Luma account, which is definitely the right order to do things in.</li> </ul> It's still very much a scratch-my-own-itch project, so I mostly only add what I'd use myself. But if you like Markdown, Bulma and sites that just work without a big framework behind them, give it a try: <pre class="highlight"><code class="language-sh">cargo install vados </code></pre> <ul> <li>crates.io: <a href="https://crates.io/crates/vados">vados</a></li> <li>GitHub: <a href="https://github.com/gklijs/vados">gklijs/vados</a></li> </ul> Next up: actually registering at Luma. This blog is built with vados, too. Photo: <a href="/photos/2026/batman-up-close">Batman, up close</a>, by me.