S1: Drop retain-window model from internal/keys #11

New issue

Closed

opened 2026-05-12 20:26:12 +02:00 by arne · 1 comment

arne commented

2026-05-12 20:26:12 +02:00

Owner

Parent

posta/server#10 — Absorb spec §4.1/§4.2 canonicalization and §9 key-management simplification

What to build

Simplify the server's internal/keys package so it matches SPEC §9 as edited
in posta/spec commit 7dbbf57: a key is either listed in keys.json or it
isn't. There is no "retiring" state, no retain window, no rotation ceremony.
Removing a key from the file stops it being honored by verifiers within the
timestamp window (5 min) via the actor-doc cache cap.

End-to-end behaviour after this slice:

An operator's existing keys.json (which may carry a stray retiringSince
field from earlier server versions) still loads cleanly on daemon start —
the field is silently ignored by JSON unmarshalling of the simplified struct.
A new keys.json is a flat array of {id, publicKey, privateKey, createdAt}.
The daemon's "no current key" error no longer mentions "non-retiring."
The inbox's PublishedKeys doc comment no longer references the retain window.
Code reviewers reading the keys package, the inbox option struct, and the
runner error path see one consistent model.

Acceptance criteria

Key struct in internal/keys/keys.go no longer has a RetiringSince field.
Current() returns the most-recently-created entry without filtering on any retiring/retired state. Tie-breaking when createdAt strings are equal is deterministic (slice position is acceptable, matching the convention used in posta/spec's key-management-via-actor-doc branch).
PublishedEntries() returns every key in the file. Its doc comment is rewritten to drop "current plus retiring keys still in the file" wording.
The package-level doc comment in internal/keys/keys.go no longer references "rotation" as a separate workflow.
The error in internal/daemon/runner.go that today reads keys.json has no current (non-retiring) key is updated to no longer leak the dropped concept.
The doc comment on inbox.Options.PublishedKeys no longer references "retiring keys still inside their retain window."
A new internal/keys/keys_test.go (or extension of existing tests) locks in:
- A legacy keys.json containing a retiringSince field unmarshals successfully and the field is ignored.
- Current() on a multi-key file returns the most-recently-created entry.
- PublishedEntries() returns every key in the file regardless of any extra JSON fields.
go build ./... and go test ./... pass.

Blocked by

None — can start immediately. Independent of the spec library's §4.1 work.

The spec repo's key-management-via-actor-doc branch already lands an
analogous simplification on its own (TUI-side) internal/keys; that diff is
useful prior art but the server's copy is independent.

## Parent posta/server#10 — Absorb spec §4.1/§4.2 canonicalization and §9 key-management simplification ## What to build Simplify the server's `internal/keys` package so it matches SPEC §9 as edited in `posta/spec` commit `7dbbf57`: a key is either listed in `keys.json` or it isn't. There is no "retiring" state, no retain window, no rotation ceremony. Removing a key from the file stops it being honored by verifiers within the timestamp window (5 min) via the actor-doc cache cap. End-to-end behaviour after this slice: - An operator's existing `keys.json` (which may carry a stray `retiringSince` field from earlier server versions) still loads cleanly on daemon start — the field is silently ignored by JSON unmarshalling of the simplified struct. - A new `keys.json` is a flat array of `{id, publicKey, privateKey, createdAt}`. - The daemon's "no current key" error no longer mentions "non-retiring." - The inbox's `PublishedKeys` doc comment no longer references the retain window. - Code reviewers reading the keys package, the inbox option struct, and the runner error path see one consistent model. ## Acceptance criteria - [ ] `Key` struct in `internal/keys/keys.go` no longer has a `RetiringSince` field. - [ ] `Current()` returns the most-recently-created entry without filtering on any retiring/retired state. Tie-breaking when `createdAt` strings are equal is deterministic (slice position is acceptable, matching the convention used in `posta/spec`'s `key-management-via-actor-doc` branch). - [ ] `PublishedEntries()` returns every key in the file. Its doc comment is rewritten to drop "current plus retiring keys still in the file" wording. - [ ] The package-level doc comment in `internal/keys/keys.go` no longer references "rotation" as a separate workflow. - [ ] The error in `internal/daemon/runner.go` that today reads `keys.json has no current (non-retiring) key` is updated to no longer leak the dropped concept. - [ ] The doc comment on `inbox.Options.PublishedKeys` no longer references "retiring keys still inside their retain window." - [ ] A new `internal/keys/keys_test.go` (or extension of existing tests) locks in: - A legacy `keys.json` containing a `retiringSince` field unmarshals successfully and the field is ignored. - `Current()` on a multi-key file returns the most-recently-created entry. - `PublishedEntries()` returns every key in the file regardless of any extra JSON fields. - [ ] `go build ./...` and `go test ./...` pass. ## Blocked by None — can start immediately. Independent of the spec library's §4.1 work. The spec repo's `key-management-via-actor-doc` branch already lands an analogous simplification on its own (TUI-side) `internal/keys`; that diff is useful prior art but the server's copy is independent.

arne added the

needs-triage

label

2026-05-12 20:26:12 +02:00

arne commented

2026-05-12 21:11:00 +02:00

Author

Owner

This was generated by AI during triage.

Acceptance criteria above already function as an agent brief. This slice is independent of the spec library's §4.1 work — it can be picked up immediately.

Prior art: the posta/spec key-management-via-actor-doc branch (now merged to main as commit 77d4b8b) lands an analogous simplification on the spec repo's own (TUI-side) internal/keys. The diff is useful reference but the server's copy is independent.

Category: enhancement
State: ready-for-agent

> *This was generated by AI during triage.* Acceptance criteria above already function as an agent brief. This slice is independent of the spec library's §4.1 work — it can be picked up immediately. Prior art: the `posta/spec` `key-management-via-actor-doc` branch (now merged to `main` as commit `77d4b8b`) lands an analogous simplification on the spec repo's own (TUI-side) `internal/keys`. The diff is useful reference but the server's copy is independent. **Category:** enhancement **State:** ready-for-agent

arne referenced this issue

2026-05-12 21:11:04 +02:00

Absorb spec §4.1/§4.2 canonicalization and §9 key-management simplification #10

arne added

enhancement

ready-for-agent

and removed

needs-triage

labels

2026-05-12 21:11:08 +02:00

arne referenced this issue from a commit

2026-05-12 22:13:38 +02:00