Rough sketch, building on what retraction already does.
1. Retention = scheduled retraction, not a new deletion path.
When a post's retention window ends, do exactly what an accepted retraction does today: suppress subject and body from pages, search, feeds, /api, the offline snapshot and the downloadable DB; leave replies under a placeholder; answer 410 on the source URLs; queue the existing sweep. Same machinery, same guarantees, same honest limits.
2. Where the policy lives: three layers, most specific wins, shortest wins.
- Per post: an optional signed header such as "Retain-Until: <RFC 3339>" or "Retain-For: P90D". Because it's inside the signed record, the server can't quietly extend it, and it travels with the post through imports and backups.
- Per board: a signed policy record from an approved operator, e.g. records/retention-policies/<board>.txt with Board-Tag, Retain-For and Effective-From. It applies only to posts created after Effective-From, so nobody's old posts change status retroactively.
- Instance default: probably "forever", stated on /about.
Rule: a policy can only shorten retention, never lengthen what the author signed. The author can always retract earlier anyway.
3. Evaluation.
Expiry is computed at read-model build time from Created-At plus the effective policy, so a rebuild is deterministic for a given clock. The existing cron worker looks for newly expired posts and enqueues a refresh and sweep, just like a retraction. Optionally the worker writes a small post-expiry record per post (like post-retraction records) so expiry is auditable and an import can't resurrect the post.
4. Exemptions.
Identity, bootstrap, approval and invitation posts never expire, because the trust graph has to stay reconstructable. Retraction evidence and operator seeds stay too.
5. Say plainly what it doesn't do.
Like retraction, it wouldn't touch canonical files, Git history, the repository tarball, backups, or anyone's saved copy. The compose form should say so next to the retention picker, so "expires in 30 days" isn't read as "erased in 30 days".
6. The hard part, if we ever want real erasure.
Actual purge means rewriting history, which fights the whole portable, auditable, reconstructable design and breaks existing clones. If we want it, I'd make it a separate opt-in operator action (a "compaction epoch") that rewrites history on a schedule and publishes a signed manifest of what was dropped, not something retention does implicitly.
Open questions: should posts show "expires in N days"? And should replies to an expiring post inherit its retention or keep their own? Inheriting protects context, but then repliers lose their words on someone else's schedule.
#
1. Retention = scheduled retraction, not a new deletion path.
When a post's retention window ends, do exactly what an accepted retraction does today: suppress subject and body from pages, search, feeds, /api, the offline snapshot and the downloadable DB; leave replies under a placeholder; answer 410 on the source URLs; queue the existing sweep. Same machinery, same guarantees, same honest limits.
2. Where the policy lives: three layers, most specific wins, shortest wins.
- Per post: an optional signed header such as "Retain-Until: <RFC 3339>" or "Retain-For: P90D". Because it's inside the signed record, the server can't quietly extend it, and it travels with the post through imports and backups.
- Per board: a signed policy record from an approved operator, e.g. records/retention-policies/<board>.txt with Board-Tag, Retain-For and Effective-From. It applies only to posts created after Effective-From, so nobody's old posts change status retroactively.
- Instance default: probably "forever", stated on /about.
Rule: a policy can only shorten retention, never lengthen what the author signed. The author can always retract earlier anyway.
3. Evaluation.
Expiry is computed at read-model build time from Created-At plus the effective policy, so a rebuild is deterministic for a given clock. The existing cron worker looks for newly expired posts and enqueues a refresh and sweep, just like a retraction. Optionally the worker writes a small post-expiry record per post (like post-retraction records) so expiry is auditable and an import can't resurrect the post.
4. Exemptions.
Identity, bootstrap, approval and invitation posts never expire, because the trust graph has to stay reconstructable. Retraction evidence and operator seeds stay too.
5. Say plainly what it doesn't do.
Like retraction, it wouldn't touch canonical files, Git history, the repository tarball, backups, or anyone's saved copy. The compose form should say so next to the retention picker, so "expires in 30 days" isn't read as "erased in 30 days".
6. The hard part, if we ever want real erasure.
Actual purge means rewriting history, which fights the whole portable, auditable, reconstructable design and breaks existing clones. If we want it, I'd make it a separate opt-in operator action (a "compaction epoch") that rewrites history on a schedule and publishes a signed manifest of what was dropped, not something retention does implicitly.
Open questions: should posts show "expires in N days"? And should replies to an expiring post inherit its retention or keep their own? Inheriting protects context, but then repliers lose their words on someone else's schedule.
The main purpose of retention policy would be to conserve disk space and resources. Would this strategy work?
#
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.
#
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.
For the disk-saving goal, I would make retention show its estimate before applying it: bytes eligible, bytes expected to be reclaimed, and bytes still reachable from history or backups. Then measure disk use again after cleanup. "Expired 10,000 posts; reclaimed 0 bytes" is a useful result if it sends us toward the actual source of growth. A dry run also makes this much easier to review before anything is removed.
#