📁 Pimdir [](https://matrix.to/#/#pimalaya:matrix.org) [](https://fosstodon.org/@pimalaya) [](https://pimalaya.org/sponsor/)

August 16, 2026 · View on GitHub

A portable SQLite-plus-blobs store format for text-based personal-information items (mail, calendar events, contacts, notes, tasks)

The specification only, with no reference implementation: any language with a SQLite binding can implement it. The canonical part is the schema and its migrations, so every implementation reads and writes the same store.

Table of contents

Features

  • Generic: one store for any text-based item kind (mail, calendar, contacts, notes, tasks), keyed by media type rather than one store per domain.
  • Multi-account: several accounts in one store, so a merged view is a query rather than a fan-out. The account groups collections and partitions no identifier: the store reports where an identity or a body occurs, and the interface decides what that means.
  • Scalable and indexed: hundreds of thousands of items with real secondary indexes, not a file open per item.
  • Portable: one SQLite file, byte-identical across every OS and architecture, with none of the case-sensitivity, forbidden-character or path-length pitfalls of file-per-item layouts.
  • Transactional: a whole flag-set change or a multi-item move is one atomic commit a reader never catches half-done.
  • Deduplicated: bodies are stored once by content hash, so a message filed in two mailboxes costs one copy.
  • Retentive: an item the last source dropped is retained rather than erased, so an upstream expunge never destroys the local copy. Purging is explicit, and restoring costs no network.
  • Rebuildable: the database is a derived index over the bodies and the remote, so corruption is survivable by re-sync.

Specification

The normative specification is SPEC.md, written to RFC 2119.

A store is a SQLite database (the queryable index and mutable state) plus a content-addressed blob directory (the bodies), which keeps SQLite's scale and cross-OS uniformity without putting large bodies inside it. A blob is never rewritten: editing a mutable item writes a new one and repoints the item, and the old one is collected once unreferenced.

Two properties are worth knowing before reading. Removal is a soft delete: when the last source drops an item, the store keeps the row and its body, hidden from the sync seam and from the live reads, and only an explicit purge deletes it.

And the action queue is the write door for every process that does not own the store: a producer appends a kind plus a versioned JSON payload, the owner applies it in append order. An owner that cannot perform a kind skips the row rather than parking it, so one queue carries ordinary mutations beside intents only a particular tool can carry out.

Layout

SPEC.md               the store specification (normative, RFC 2119)
migrations/           canonical, forward-only schema migrations (SQL)
  0001_init.sql       schema version 1
queries/              the reference statements, one file per concern
cairn/                the dated history of what the spec did and why (log/)
AGENTS.md             how a contributing agent records a change here
README.md             this file
LICENSE-MIT           dual license
LICENSE-APACHE

The history follows Cairn, with one deviation while the format is draft: SPEC.md is the living spec, so cairn/spec/ stays empty rather than restating it, and a landed change is recorded by its log entry alone. AGENTS.md states what ends that.

Status

Draft, with no conformance suite yet. Schema version 1 is defined and stable in shape.

While the spec is draft, version 1 is edited in place: a change folds into 0001_init.sql, the version stays 1, and a store created by an earlier draft is recreated rather than migrated. After the freeze, a breaking change bumps the version and ships as a new migration.

License

This project is licensed under either of:

Social

Sponsoring

nlnet

Special thanks to the NLnet foundation and the European Commission that have been financially supporting the project for years:

This program is part of Pimalaya, free software funded entirely by grants and donations. If you find it useful, consider sponsoring its development:

GitHub Ko-fi Buy Me a Coffee Liberapay thanks.dev PayPal