Repository navigation
id: delete requests, server delete policies, federated delete replication (code#185 decision) #2091
Description
Implements the policy + federation layers of the owner decision on #185 (comment 6486250456, Drew, 2026-10-28). Likely splits into smaller issues; filed whole so the design stays in one place. Depends on the marker + default-view work (tag.clear as a role-aware marker).
Pieces
- Delete requests. A first-class operation: anyone can request deletion of a tag, carrying a reason. The request is delivered to the relevant authority holders — the tag's author, group admins, or server owners — and their grant/decline is recorded.
- Server delete policies. A server admin can set policies on their own server that actually delete based on clear markers (and/or granted delete requests). Conditions are the server's business; nothing here is protocol-mandated. Deletes are events (auditable), not silent state edits.
- Federated deletes (opt-in per server owner, never default).
- A server owner may replicate deletes from federated co-servers.
- A server owner may accept delete events from ANY server provided the delete is signed by the author or admins and the full chain validates; an invalid or incomplete chain means the foreign delete is not honored.
Acceptance
- Delete request round-trips: request with reason -> delivered to author/admins/server owners -> grant produces a delete under the server's policy, decline is recorded with no delete.
- A server with no delete policy never hard-deletes from clear markers alone.
- Foreign deletes are honored only under the owner's chosen mode (federated co-servers, or any-server-with-valid-signed-chain) and rejected when the chain does not validate.
Refs #185.
Acceptance criteria
- Delete requests are a first-class operation carrying a reason, delivered to the tag's author, group admins, or server owners, with grant/decline recorded.
- Server admins can set delete policies on their own server that act on clear markers and/or granted delete requests; deletes are auditable events, never silent state edits.
- Federated delete replication is opt-in per server owner (never default); a foreign delete is honored only when signed by the author or admins and the full chain validates.
- Tests cover request grant/decline, policy-driven delete, and rejection of an invalid/incomplete foreign delete chain.
Metadata
Metadata
Assignees
Labels
Package/app: id (pkgs/ or apps/ in this repo)Large: multi-day or open-ended; expect staged check-insIntake review done: acceptance criteria, links, and normalized labels addedOrdinary priority (the default)Filed by the repo design architect jobWaiting on a dependencyQueue packet kind: verify, reproduce, and route this item
Activity
developing-today commentedon Oct 29, 2026
CODE-1004
dezren39 commentedon Oct 29, 2026
Intake review
Fleet monitor intake (2026-10-29) — verified still live: no merged PR or commit implements this yet; the filing audit/decision record it cites is current.
Notes: Implements the policy + federation layers of Drew's recorded decision on #185 (comment 6486250456); depends on #2090 (role-aware clear marker + default view). Filed whole so the design stays in one place; the filer notes it likely splits — the triage worker should propose the split before implementation. Not yet live-verified against a merged PR: filed 2026-10-29 from the #185 decision, no implementation exists yet.
Suggested approach: Land #2090 first; then split into (1) delete requests, (2) server policies, (3) federated replication, in that order.
Risks: Federated delete acceptance is the safety-critical piece: chain validation must be fail-closed.
Labels normalized by the monitor; acceptance criteria appended to the body (original text preserved verbatim above it).
dezren39 commentedon Nov 3, 2026
🤖 Agent note · handed off
opencode; handing off to the laptop claimant, which launches the bound opencode session.16 remaining items
dezren39 commentedon Nov 4, 2026
🤖 Agent note · parked
dezren39 commentedon Nov 4, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 4, 2026
🤖 Agent note · triaged — blocked on dependency
1a180ae5-384f-4e71-8d77-08f7b1652c75gh pr list --search "2090 OR 2091"returns no related PR).d45cf2bd4has no delete-request operation, no server delete policies and no federated-delete replication. What exists is unrelated:tag.clearclaim removal (pkgs/id/src/tag_claims.rs:39-48) andDeleteRequestinpkgs/id/src/web/routes.rs:2393, which is only the HTTP body for file soft/hard deletion.handed_off/execution_lane: opencode, its issue carriesqueue/claimed+status/in-progress, and uncommitted work sits in/home/user/git/fleet/8903onqueue/8903-2090-tag-clear-role-aware(event_store/claims.rs,tests/search.rs,tests/tag_claims.rs,tests/tag_clear_authority.rs; branch not pushed).triagedwith no new queue task: any fix task for id: delete requests, server delete policies, federated delete replication (code#185 decision) #2091 started now can only re-park on id: tag.clear as a role-aware marker + default view (code#185 decision) #2090, which is exactly the loop this task has been in (attempts 9/12). The labels now saystatus/waiting-dependencyinstead of an in-flight state.repo-health:v1:fix:developing-today/code:issue:2091at that point. Implementation order inside the issue: (1) delete requests (first-class op + grant/decline record), (2) server delete policies over clear markers and granted requests (deletes as auditable events), (3) opt-in federated delete replication with signed-chain validation. The acceptance criteria in the issue body are already the test plan.