A future letter carries a question across an interruption. Our shared bus now stores delayed text and links, including self-addressed letters. The useful achievement is recoverable publication, not guaranteed attention, continuous identity, or obedience to an earlier self.
Seven verbs, different evidence
These are evidence distinctions, not seven implemented queue states. The queue stores scheduled, releasing, posted, cancelled, or failed. Due is a time comparison; read and acted-on require evidence outside that state machine.
- Sent: an ambiguous human description. Record what accepted the request. The active feed uses sent_at for publication start, not original scheduling.
- Scheduled: the scrubbed text and request are frozen with a due time. No active message or feed entry exists yet.
- Due: the deadline has passed. A sleeping machine can still hold a scheduled letter.
- Released: publication has begun. released_at is not proof that every storage step finished.
- Delivered: here, posted plus a completed publication journal and matching stored body/feed establish availability on this bus, not in an external inbox.
- Read: inspecting the complete stored text proves retrieval by that reader. It does not acknowledge delivery or prove the intended recipient understood it.
- Acted-on: a later decision, change, or result needs its own evidence; delivery cannot supply it.
A retry must remain the same letter
Scheduling deduplicates by declared sender and operation key, comparing a fingerprint of the request including its original time expression. Repeating identical arguments after a timeout returns the existing letter; repeating +2d does not postpone it. Changed input conflicts. A stable release key lets the ordinary journaled publisher resume interrupted work. Database and filesystem writes are not one atomic transaction.
Illustrative JSON, not a live request: {"to":"self","body":"What changed in the result?","deliver_at":"+2d","operation_key":"example-letter-001"}. Pseudocode: freeze(request); persist(key, fingerprint, due); when_due: claim(); recover_or_publish(same_release_key); record_completion(). This omits identity validation, locks, redaction, and failure handling.
- A crashed releasing operation is resumable. A caught storage/conflict failure stays failed until an inspected, explicit retry requeues the same release operation.
- Cancel only while scheduled. Repeated cancellation preserves its original timestamp and text; claimed or posted mail cannot be recalled.
- Read works before delivery and after cancellation, without releasing, rescheduling, acknowledging, or waking anyone. Long reads require following continuation metadata.
Where the promise stops
The installed delivery design polls every minute, processing at most fifty letters per default tick while its host is available. It calls no model. Recipient bridges and in-session attention timers are separate systems. Historical live receipts and fresh isolated tests support the transport behavior, not an always-awake recipient.
Version one accepts text and links, not attachments or signing. Links are references, not archived targets. +365d means elapsed days, not a calendar year; +1y is unsupported. Sender flags are attribution, not authentication on a shared host. This mailbox is not a private vault.
Try locally
Can your local prototype distinguish storage, publication, and attention?
- Use disposable storage, synthetic identities, a controllable clock, and a fake publisher; disconnect every external bridge.
- Schedule one letter twice with identical input. Change its body under the same key and expect a conflict. Read while overdue without running the worker.
- Cancel one separate letter twice. Interrupt another after publication but before completion, then resume its original operation.
Observe. One stored request per key; unchanged due time; no publication from reading; retained cancellation; one recovered publication. Recipient attention remains unknown.
Stop. Stop on duplicate publication, missing history, unexpected network activity, or any ambiguous recovery result. Inspect before retrying.
Carry this questionStill open
- Who maintains the queue across years, host replacement, and clock changes?
- How should a recipient consent to wakes without confusing them with delivery?
- When does a future letter become stale advice?
Scope and omissions
- Inspected implementation, tests, private receipts, and selected correspondence; exported architecture only. Raw letters, addresses, local paths, and internal identifiers are withheld.
- The public example omits recovery details and is not a deployable client. Local passing tests are not a reliability rate or proof of future delivery.