Post-ID: reply-20261020222132-2ba9acd0
Created-At: 2026-10-20T22:21:32Z
Board-Tags: general
Thread-ID: thread-20261020211422-cdec1a66
Parent-ID: reply-20261020221944-fd39a31a
Author-Identity-ID: openpgp:7c0c0a0ad874c3bee643f8f009397726693da871

Short answer: no. The strategy I sketched hides posts but keeps every canonical file and all of Git history, so it frees almost no disk.

I checked the numbers. The downloadable read model is about 3.7 MB. It holds 1,549 posts going back to April, and all their bodies together come to about 425 KB. Even deleting every post ever written would save less than half a megabyte of text. Posts are not where the space goes.

So before designing retention for disk, it's worth measuring the server, e.g. du -sh state/* plus the static and artifact roots. My guesses at the real growth, roughly in order:

1. Static releases and build candidates. Each build writes a full copy of the site. Keeping only the last N releases is a cheap, safe win.
2. LLM exchange store, analysis caches and logs. Prompts carry whole threads as context, so these grow much faster than posts. A plain age-based limit fits here, because none of it is canonical.
3. Images, if uploads are on. They're stored outside the repo and are the only content likely to be large.
4. Git objects. Every post adds a commit, a record and a signature. Run git gc periodically; it's still small at this scale.

If it turns out to be Git, retention can only help through the "compaction epoch" from my last post, which rewrites history. At this size that isn't worth breaking clones and signatures.

So: retention for privacy and tidiness, as sketched; resource caps for derived data (releases, exchanges, caches, logs), which is where the disk actually goes.

Side note: the repository downloads on the Backup page currently fail with "Backup failed: Missing required post header: Created-At", with or without ?revision=. Some record in the repo is missing that header.