Repository navigation
id: design+PoC: sticky-notes / did-it tracker — the first ID app #2031
Description
LIST 7 synthesis. Merge the data-model and trust investigations into the design + a proof of concept of the first ID app: distributed sticky notes (a fancy distributed Google Keep) fused with the did-it tracker. PoC bar: two identities exchange notes and did-it events; one identity's view correctly excludes a third party's claims while keeping them retrievable on demand. Do not build the permanent feature on the PoC without a review round.
Program: Drew's 2026-10-28 directive (full text: hatch-personal memory/topics/id-program-2026-10-28.md).
Working pattern: parallel investigations, then the named synthesis issue merges them into a full design. Route guidance: Workhorse by default; Specialist/Summit for synthesis and ramification-heavy work. A result that says "done" is not the endpoint — the orchestrator reviews it and may commission another round. Deliverables: a markdown design/investigation doc (mermaid/SVG diagrams welcome) linked from this issue, plus follow-up issues for anything buildable. Build a proof of concept where the design calls for one, but do NOT build the permanent feature on top of an unreviewed PoC.
Activity
developing-today commentedon Oct 29, 2026
CODE-952
dezren39 commentedon Oct 29, 2026
Parent epic: #2056 — ID platform expansion (2026-10-28 directive).
dezren39 commentedon Nov 1, 2026
🤖 Agent note · picked up
dezren39 commentedon Nov 1, 2026
Design record — issue #2031, first ID app (task 5727 triage)
The decision to be made: how the first ID app — distributed sticky notes fused with the did-it tracker — is built on the current
pkgs/idsubstrate, and in what order the pieces land so each is independently mergeable.Evidence at origin/main (3cbab2d, verified fresh this run)
doc/2026-10-29T13-04-50Z_investigation_didit_tracker_data_model/(PR docs(id): did-it tracker data model — events, expectations, per-entity detail, later opinions (#2029) #2330); issue id: investigate: trust/visibility model — servers accept all signed objects; views count only allowed writers #2030 (trust/visibility) closed, and its follow-on writer-set spec issue id: design: writer-set + view-projection spec for pkgs/id — representation, set-change semantics, discovery query (from #2030) #2238 is also closed with a spec doc on main atdoc/2026-10-30T13-15-00Z_design_id_writer_set_view_projection/.didit.*code exists yet:git grep -i diditoverpkgs/idat origin/main returns nothing insrc/— the model is designed, not built.ChainExt { pub kind: String }atpkgs/id/src/chain.rs:97-100— new event kinds need no envelope change (did-it doc decision D0, doc lines 97–98).DOCUMENT_KIND = "document.put"and the removal kind atpkgs/id/src/documents.rs:32-35; documents are signed, group-replicated content events.pkgs/id/src/event_store/ingest.rs:60), and the store keeps tag events whether or not resolution applies them (pkgs/id/src/event_store/claims.rs:3-5). What is missing is the per-view writer-set projection — designed in the id: design: writer-set + view-projection spec for pkgs/id — representation, set-change semantics, discovery query (from #2030) #2238 spec, not yet implemented insrc/.pkgs/id/examples/(roc-counter, roc-chat, lounge), which is the pattern the PoC follows.Options considered
didit.*schema types + pure evaluator, library-only; (b) writer-set + view-projection per the id: design: writer-set + view-projection spec for pkgs/id — representation, set-change semantics, discovery query (from #2030) #2238 spec; (c) the PoC itself as an example + integration test on top of (a)+(b). Each phase merges alone and is testable without the next.Recommendation
Option 2. The synthesis is mostly already decided by its inputs: four
didit.*kinds (didit.entity,didit.record,didit.expectation,didit.opinion— #2029 doc D0), a pure evaluator (no storedduestate, so it is offline- and multi-device-correct), sticky notes asdocument.putevents in a shared group (title = first line; edits are superseding document events; removal is the existing removal kind), and the trust rule from #2030: ingest stores every validly signed object; a view counts only authors in its writer set; uncounted objects stay retrievable on demand and render with author + "not counted" status.Invariants the implementation must hold (the PoC bar, from the issue body)
tz; a record whosetz_offset_minutesdisagrees is surfaced in the UI, not silently coerced (id: investigate: did-it tracker data model — events, expectations, per-entity cardinality, details + later opinions #2029 doc §9 Q1 proposal).subjects: []is invalid — explicit entity IDs only, so history is stable (id: investigate: did-it tracker data model — events, expectations, per-entity cardinality, details + later opinions #2029 doc §9 Q2 proposal).Phased implementation packets (enqueued this run, queue repo-health-code-pilot)
repo-health:v1:fix:developing-today/code:issue:2031:didit-schema-evaluator—pkgs/id/src/didit/schema types + pure evaluator + the id: investigate: did-it tracker data model — events, expectations, per-entity cardinality, details + later opinions #2029 doc §8 golden tests. Library-only.repo-health:v1:fix:developing-today/code:issue:2031:writer-set-view— writer-set object + view projection per the id: design: writer-set + view-projection spec for pkgs/id — representation, set-change semantics, discovery query (from #2030) #2238 spec: counted/uncounted projection, exclusion entries, set-version + frontier naming on computed views.repo-health:v1:fix:developing-today/code:issue:2031:poc-app— PoC underpkgs/id/examples/: sticky notes (document events) + did-it feed in one group timeline, with an integration test proving the PoC bar (two identities exchange; third party excluded from view, retrievable on demand). Depends on packets 1 and 2.Questions that genuinely need Drew (explicit, with recommendation — none blocks packet 1)
publicwriter-set view exist in the PoC at all? Options: (a) omit from PoC (recommended — id: investigate: trust/visibility model — servers accept all signed objects; views count only allowed writers #2030 flagged public metrics as gameable; add after the abuse controls of issue id: investigate: comms abuse controls — blocks, rate limits, and per-counterparty budgets #2032 exist); (b) include as read-only discovery only.good/bad/unsure+ free text (recommended, per id: investigate: did-it tracker data model — events, expectations, per-entity cardinality, details + later opinions #2029 doc §9 Q5) vs a numeric rating scale (invites meaningless cross-author aggregation).actpattern of a did-it record by default (id: investigate: did-it tracker data model — events, expectations, per-entity cardinality, details + later opinions #2029 doc §9 Q3)? Recommended: summary projection shows counts/timing only;actrequires the app link.🤖 Agent note · triaged
dezren39 commentedon Nov 1, 2026
Correction + routing update (task 5727): the design record above listed phase-suffixed dedupe keys, which the queue's key patterns do not accept. Per the program rule that buildable slices are filed as their own issues, the phases were filed and enqueued per-issue instead:
repo-health:v1:fix:developing-today/code:issue:3788repo-health:v1:fix:developing-today/code:issue:3789repo-health:v1:fix:developing-today/code:issue:3790All three tasks are queued on
repo-health-code-pilotwithqueue/queuedon their issues; Phase 3's packet names its dependency on Phases 1 and 2. (Three identical packets briefly landed in the shadow queue through a missing--queueflag; they were cancelled and re-enqueued to the pilot queue in the same run — the task IDs above are the live pilot ones.)dezren39 commentedon Nov 1, 2026
🤖 Agent note · done
2 remaining items
Merge pull request #3910 from developing-today/design/id-2031
developing-today commentedon Nov 3, 2026
agent-note:v1
state: reviewed (coverage loop-back)
Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 6821 (triage, queued, priority 50) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
Found via: coverage loop-back 2026-11-03
dezren39 commentedon Nov 3, 2026
🤖 Agent note · done
Triage verdict — task 6821, verified at origin/main e425b6a (2026-11-03)
The design deliverable of issue #2031 is complete; the issue stays open as the set's tracking home. Nothing here is blocked on a new decision:
pkgs/id/docs/2026-11-01_design_id2031.md(library-first design; PoC bar = two identities exchange notes/did-it events, a third party's claims excluded from the view but retrievable on demand; review round required before any permanent feature).Issue #2031 closes when issue #3789 and issue #3790 land, per the task 5727 disposition — it is the tracking home, not a work item.