Repository navigation
id(boards): compose_view applies supersedes edges from superseded attestations — a nullified revocation still revokes #4003
Description
Summary
BoardGraph::compose_view (pkgs/id/src/boards.rs, merged today in PR #3971 for issue #2813) computes the "current moderator frontier" from RoleAttestation supersedes edges collected from every attestation in the graph — including attestations that have themselves been superseded and therefore, by the module's own rule, have no effect. A revocation that was later nullified by a generic Supersede record still revokes the grant it named, so a moderator the owner reinstated (by superseding the revocation) silently keeps no authority in the composed view.
Evidence (main @ 9e1be52)
- The generic-supersede frontier is resolved to a fixed point at boards.rs:899-925, and the module's stated rule (compose_view comments, boards.rs:884-891) is: "a superseded record (a moderation action, a tombstone, any content object) has no effect in the projection, whatever it once said." The test
superseded_supersede_record_has_no_effect(boards.rs:2058) pins the same principle for Supersede records, andgeneric_supersede_of_a_grant_also_revokes_authority(boards.rs:1997) pins that superseding a grant ends its authority. - But the attestation frontier at boards.rs:932-941 inserts
value.supersedesintoattestation_supersededfor all RoleAttestations of the board, with no check that the attestation carrying the edge is itself still active (not in thesupersededset computed just above). The filter at boards.rs:943-944 excludes a superseded attestation as a grant source, yet its outgoingsupersedesedge is still applied.
Reproduction (verified this run)
Laptop probe ~/git/fleet/probe-2026-11-01-laneB-attsuper/ over verbatim pkgs/id/src/boards.rs (sha256 b041c747c05745465d8043a8ab8b089ff512a68a8e78ff3e0964c6272918d19a, matching main @ 9e1be52; artifact.rs sha256 c3332474b111453df5b68688aed35f977f8125a6cec6a3a69daedfbc913ae1c7):
- Owner grants Moderator to M (attestation A1,
granted=true); M hides a post → view hides it (control passes: hidden=1). - Owner revokes with A2 (
granted=false,supersedes=A1) → post visible again (control passes). - Owner signs an unrelated attestation A3 (grants a different member) and a generic Supersede record S (
previous=A2,replacement=A3; same kind, same author — valid per validate_links boards.rs Supersede arm). S nullifies the revocation A2. - Expected per the module's rule: A2 has no effect, so A1 is again the current grant and M's Hide applies (post hidden). Observed: the post stays visible — A2's stale
supersedesedge still excludes A1 fromcurrent_moderators, sohas_authority(M)is false and the Hide is treated as unauthorized.
Note the asymmetry this creates: superseding a grant revokes (tested, boards.rs:1997), but superseding a revocation does not reinstate (untested, broken) — the two directions of the same record-nullification rule were only half-applied when the frontier was built.
Why it matters
Moderator authority in the composed view decides whose Hide/Restore records change what every viewer sees. An owner who reverses a revocation via the generic supersede mechanism (the same mechanism the module tests for grants, tombstones, and moderation actions) gets a view where the reversal silently did nothing: the formerly-revoked moderator's actions are ignored, with no error anywhere. Authority frontiers that disagree with the signed record set undermine the order-independence/determinism the module is designed around.
Acceptance criteria
-
compose_viewonly applies a RoleAttestation'ssupersedesedge when that attestation is itself active (not superseded), mirroring the generic frontier rule — or an equivalent formulation with the same observable behavior. - Regression test: grant → revocation (attestation
supersedes) → generic Supersede nullifying the revocation (replacement is a same-kind attestation that does not itself decide the subject's role) → the subject's moderation actions take effect again in the composed view. - Existing behavior preserved: grant → revocation keeps the subject without authority; generic supersede of a grant still revokes (boards.rs:1997 test); superseded-supersede test (boards.rs:2058) still passes.
- All existing boards tests pass.
Scope / notes
- Fix is local to
compose_view's moderator-frontier computation in pkgs/id/src/boards.rs; insert-time validation is unchanged. - Related, distinct filings on the same file: issue id(boards): Post embed_ref is never validated — dangling and cross-board game-post references are accepted into BoardGraph #3963 (Post embed_ref unvalidated), issue id(boards): Rules revision numbers are not unique per board — two different revision-1 rule texts coexist in one graph #3964 (Rules revision uniqueness). This issue is only about the attestation frontier in the view projection.
Activity
dezren39 commentedon Nov 1, 2026
🤖 Agent note · filed
dezren39 commentedon Nov 1, 2026
🤖 Agent note · filed (verification re-run)
dezren39 commentedon Nov 1, 2026
🤖 Agent note · filed (correction)
repo-health:v1:triage:developing-today/code:issue:4003): one row, id 5938, status queued, created 2026-11-01T21:58:41Z. The enqueue, the packet, and this issue's filing are otherwise exactly as recorded.dezren39 commentedon Nov 2, 2026
🤖 Agent note · adopted as Phase 2 of design #4113
attestation_supersededincompose_viewis computed only from RoleAttestations that are not themselves in the genericsupersededset — the fixed-point frontier the function already computes for Supersede records, whose comment already states that only active records contribute edges. Attestation-to-attestation supersession (same member/role chain) is unchanged; this governs generic-supersede nullification only. All three preserved-behaviour controls in this issue's acceptance stand.source/design-architect. Existing queued triage packet stands.8 remaining items
dezren39 commentedon Nov 2, 2026
agent-note:v1
event: picked_up
task: 6281 (repo-health-code-pilot, repo-worker-code, lane code-h)
state: claimed fix #4003; fresh revalidation: issue #4003 OPEN, no hard-stop labels, no existing PR. Execution lane: direct.
next: laptop worktree; make the attestation supersedes frontier in compose_view ignore edges carried by superseded attestations, with a regression test mirroring the issue reproduction (grant A1, revocation A2 superseding A1, generic Supersede nullifying A2 -> A1 authority restored).
fix(id): recompute attestation frontier from eligible set so chains r…
Merge pull request #4512 from developing-today/queue/6281-4003-boards…
dezren39 commentedon Nov 2, 2026
agent-note:v1
event: done
task: 6281 (repo-health-code-pilot, repo-worker-code, lane code-h)
state: fixed_merged. PR #4512 MERGED 2026-11-02T18:14:14Z, merge commit 617393f; issue auto-closed. compose_view now resolves the moderator frontier over active attestations only: a superseded attestation contributes no supersedes edge, so superseding a revocation reinstates its grant.
codex: round 1 P1 (chain reactivation) was correct — the shrinking loop could never reactivate a middle revocation; fixed in f78d780 by recomputing the active set from the eligible set each pass, with a chain regression test; round 2 review completed with no findings.
tests: verbatim boards.rs probe crate (same harness shape as the issue repro) — cargo test boards:: 27/27 pass, including superseded_revocation_no_longer_revokes, attestation_chain_frontier_reinstates_and_re_revokes, generic_supersede_of_a_grant_also_revokes_authority, and superseded_supersede_record_has_no_effect. Full id lib remains blocked on main by issue #4454, unrelated.
next: none for task 6281.