Phase 5: who may clear a tag claim #185

Activity

1. github-actions

   assigned

   dezren39

   on Oct 12, 2026
2. dezren39

   added a commit that references this issue on Oct 12, 2026

   docs(id): phase 5 aliases [phase 5]

   ...

   9902279
3. dezren39 commented on Oct 24, 2026

   

   dezren39

   on Oct 24, 2026

   MemberAuthor

   More actions

   id train triage (2026-10-24): needs-decision — project owner: who may clear a tag claim (claim author vs group admins; interacts with #160).
4. dezren39

   added

   app/idPackage/app: id (pkgs/ or apps/ in this repo)Package/app: id (pkgs/ or apps/ in this repo)

   work/assignedQueue worker lifecycle stateQueue worker lifecycle state

   queue/claimedQueue worker lifecycle stateQueue worker lifecycle state

   status/in-progressQueue worker lifecycle stateQueue worker lifecycle state

   on Oct 27, 2026
5. dezren39 commented on Oct 29, 2026

   

   dezren39

   on Oct 29, 2026

   MemberAuthor

   More actions

   🤖 Agent note · escalated

   • Agent: queue worker (repo-worker-code), lane A
   • Session / ID: queue task 2028
   • Found via: queue claim
   • Task: Triage Phase 5: who may clear a tag claim #185 — who may clear a tag claim. Verdict: CONFIRMED at HEAD a3cdf6c9, and the open question is an owner decision (the issue body itself says "Owner decision needed"), so this escalates with the substance below rather than routing a fix packet that would guess the policy.
   • Evidence: pkgs/id/src/tag_claims.rs — both folds (live_claims and compacted_claims) remove a claim when an applied tag.clear names it and the claim lies in the clear's causal past. There is NO comparison of the clear's author to the claim's author and no admin check anywhere in the fold; the module doc states only the seen/not-seen rule. pkgs/id/src/event_store/claims.rs (tag_claims reader) likewise applies clears with no authorization gate. The related user-subject issue Phase 2: user subject for tags needs an identity event #160 is still OPEN (no user subject exists yet), so the "how does the user subject interact" half cannot be implemented yet either.
   • The decision, in plain words: A tag claim is a signed statement by one key ("this object is called X / tagged Y"). A tag.clear deletes someone else's statement from the live view. Today ANY key that has seen a claim may clear it. Options:
     • A. Author-only: a clear removes only claims whose author is the clear's author. You can retract your own tags, never anyone else's. Simple, matches signed-attribution, no new machinery. Cost: nobody can clean up another key's spam/wrong tags; views must handle bad claims by display rules (the alias code already shows contested aliases rather than picking one).
     • B. Author or group admins: as A, plus admins of the group owning the subject may clear others' claims on that subject. Gives moderation. Cost: the fold would need "who was an admin at that point in the causal history" — the fold today has no roster input, so this is real new machinery; and user subjects (Phase 2: user subject for tags needs an identity event #160) have no group admins, so B still needs a rule for them.
     • C. Status quo (anyone may clear what they saw): tagging stays fully open/janitorial, as the Phase-5 design doc originally sketched ("Anyone may tag anything"). Cost: any participant can erase any other participant's tags they have seen — griefing surface, and erased claims vanish from live views (history remains in the log).
   • Recommendation: A (author-only) now. It is the only option implementable in the fold without new inputs, it preserves the signed-attribution model, and unwanted claims are already handled at display time (contested alias display). Revisit B when Phase 2: user subject for tags needs an identity event #160 lands and an admin-at-clear-time rule can be defined with the roster work. If Drew picks B or C instead, the follow-up packet will be pinned to that choice.
   • Expectation: Blocked on Drew's pick (A / B / C). On a decision, the worker enqueues the pinned small_fix (author gate in both folds + tests, e.g. cross-author clear leaves the claim live).
   • Links: issue Phase 5: who may clear a tag claim #185 · dependency Phase 2: user subject for tags needs an identity event #160
6. dezren39

   added

   queue/blockedQueue or user escalation stateQueue or user escalation state

   status/blockedQueue or user escalation stateQueue or user escalation state

   user/escalatedQueue or user escalation stateQueue or user escalation state

   and removed

   status/in-progressQueue worker lifecycle stateQueue worker lifecycle state

   queue/claimedQueue worker lifecycle stateQueue worker lifecycle state

   on Oct 29, 2026
7. dezren39 commented on Oct 29, 2026

   

   dezren39

   on Oct 29, 2026

   MemberAuthor

   More actions

   Owner decision (Drew, 2026-10-28) — none of A/B/C as posed; a layered model instead

   Default view = author + group admin (option B's authority set), implemented as a MARKER, not a gate:

   • Anyone may post a tag.clear. It is a marker event on the log — never itself a deletion — and posting it is not gated.
   • The default view (most queries) treats a tag as cleared only when the marker was posted by someone in an appropriate role for that tag: the tag's author, or a group admin of the group the tag belongs to.
   • Markers from anyone else stay on the log but are ignored by default queries.

   Actual deletion = server policy (a separate layer):

   • A server admin can make policies on their own server that actually delete based on clear markers. What conditions trigger a delete is the policy's business, not the protocol's.
   • Implement a delete-REQUEST method: anyone can request deletion of a tag, with a reason, sent to the relevant authority holders — the tag's author, group admins, or server owners — who decide.

   Federation (each server owner's choice, opt-in, never a default obligation):

   • Server owners may choose to replicate deletes from federated co-servers.
   • Or accept delete events from any server, provided the delete is signed by the author or admins and the full chain validates.

   Implementation is filed as two linked issues (marker + default view first; delete requests / server policy / federation second). This issue was the policy decision and closes with this comment.
8. dezren39 commented on Oct 29, 2026

   

   dezren39

   on Oct 29, 2026

   MemberAuthor

   More actions

   Decided 2026-10-28 (owner decision above, comment 6486250456). Implementation: #2090 (tag.clear as role-aware marker + default view) and #2091 (delete requests, server delete policies, federated delete replication). Closing as the policy question this issue posed is answered.
9. dezren39

   closed this as completedon Oct 29, 2026
10. developing-today

    added

    status:done

    on Oct 29, 2026
11. dezren39

    removed

    status/blockedQueue or user escalation stateQueue or user escalation state

    on Nov 1, 2026