service-fs — the WORM ledger backbone
Every record written to the PointSav platform — identity anchors, email communications, document artifacts — lands in service-fs, a per-tenant Write-Once-Read-Many (WORM) immutable ledger. Once written, records cannot be modified or deleted; the ledger is the tamper-evident backbone that Ring 2 services query and Ring 1 services write to. The WORM ledger design article describes the WORM design philosophy in detail.
service-fs is not a general-purpose filesystem. A local filesystem permits reads, writes, modifications, and deletions through a standard directory tree. service-fs exposes a narrow, append-and-verify surface: writing a new record, reading forward from a point in the log, and producing a signed proof of the ledger's current state — plus the cryptographic operations that let a caller verify a specific entry or confirm two checkpoints are consistent with each other. This narrow surface is what makes the ledger's integrity guarantees structurally sound rather than policy-enforced.
Key takeaways
- The service exposes append, read, checkpoint, and both single-entry and cross-checkpoint verification, over HTTP and over MCP — all implemented, not planned.
- The ledger is per-tenant — each Totebox holds its own isolated ledger; no cross-tenant reads are possible at the storage layer.
- Every entry chains cryptographically into the one before it (a linear SHA-256 hash chain), and a dedicated audit-log sub-ledger records every read event alongside the primary record ledger.
- Recurring Sigstore Rekor anchoring by FS anchor emitter creates an external, publicly verifiable timestamp chain for the entire ledger, running on a monthly cadence.
- Today's deployment is a standard Linux/BSD daemon with process-level isolation — a real but weaker guarantee than a microkernel-enforced boundary would provide. A seL4 microkernel envelope was explored as a bare-metal unikernel design under this same package name; that design now lives in its own separate vendor package, and no seL4 target is under active development inside the current
service-fscodebase.
The layered architecture
service-fs separates concerns into layers that can change independently:
- Anchoring: monthly work performed by FS anchor emitter, anchoring signed checkpoints to the public Sigstore Rekor log.
- Wire protocol: an HTTP interface (via axum) and an MCP server interface, both exposing the same underlying operations to different kinds of callers.
- Ledger contract: a stable Rust trait — append, read since a cursor, checkpoint, and both proof operations — that the wire layer and the storage layer both compose against, so either can change without breaking the other.
- Storage: today, a per-tenant POSIX-file-based hash-chain log using the C2SP tlog-tiles format for the on-disk tile structure and C2SP signed-note format for checkpoints.
Durability
The ledger's on-disk format follows open standards rather than a proprietary schema — C2SP tlog-tiles for the log itself, C2SP signed-note for checkpoints — so a future reader could decode the raw files with standard tools even without the platform's own software. Every write also lands in the audit-log sub-ledger, an independent WORM record of read activity alongside the primary data.
Threat model
- Operator tampering. Even an administrator with direct access to the storage can't alter a past record without breaking the hash chain — and a broken chain is detectable both locally and against the externally-anchored Rekor checkpoints.
- Vendor obsolescence. The open-standard on-disk format is designed to outlast any particular vendor's software.
See also
- FS anchor emitter — the periodic anchor emitter that checkpoints the ledger to Sigstore Rekor
- WORM ledger design — the design philosophy behind the WORM approach
- Machine-based authorization — the authentication system that governs who can act on the ledger's behalf
- service-content — entity extraction and knowledge-graph host — a Ring 2 consumer of records
service-fsholds