Repository navigation
id: long-term — group encryption and authorization (BeeKEM / p2panda-encryption) #1070
Description
Long-term: group encryption and authorization
From pkgs/id/TODO.md (long-term section):
Group key agreement so a world's documents and envelopes can be encrypted for its current members only. Candidates: keyhive's BeeKEM (pre-alpha — revisit when stable) or p2panda-encryption. Borrow ideas; do not depend on pre-stable crates without review.
Long-term idea, filed so it is tracked and prioritized rather than lost. Not on the path to Phase 12.
Coordination (2026-10-26 reprioritization, per Drew): every id roadmap item now has its own GitHub issue, and priority encodes the order: (1) the path to Phase 12 — now + priority/high; (2) Phase 12 itself — next; (3) Phase 13 and long-term ideas — priority/low. The dashboard mirrors this list (org Project "Developing Today" #4, Area id-train; Grist Program roadmap, Area id). If this item turns out to be blocked, wrong, or superseded, park or close it with a note rather than letting it stall the queue — dropping an issue is always allowed; silently stalling is not.
Acceptance criteria
- A candidate evaluation is recorded on this issue (keyhive BeeKEM vs p2panda-encryption), including each candidate's stability status at evaluation time.
- No pre-stable crate is adopted as a dependency without an explicit review note here.
- A decision is recorded: adopt (with the first implementation issue filed), defer (with a revisit trigger), or drop (with reason).
Activity
developing-today commentedon Oct 27, 2026
CODE-214
dezren39 commentedon Oct 27, 2026
Intake review
Related: Source:
pkgs/id/TODO.md(long-term) · related provenance/trust work: F12.17 #1069Notes: Long-term, priority/low, explicitly not on the path to Phase 12. BeeKEM is pre-alpha per the TODO — the evaluation's job is mostly to set the revisit trigger so this doesn't get re-litigated from scratch.
Risks: Depending on a pre-alpha KEM would put world encryption on a moving foundation; the guardrail in the body (borrow ideas, don't depend without review) is the controlling rule.
Suggested approach: Timebox the evaluation; the deliverable is the decision record, not a prototype.
Labels were already normalized by the filer (kind, source/human, status/needs-triage, priority, effort, app/id all present); this pass appended the acceptance criteria above and adds
meta/enriched.🤖 Agent note · filed
dezren39 commentedon Oct 28, 2026
🤖 Agent note · picked up
dezren39 commentedon Oct 28, 2026
🤖 Agent note · done
pkgs/id/src/encryption/mod.rs,pkgs/id/Cargo.toml:72,pkgs/id/TODO.md:250-253Candidate evaluation (recorded 2026-10-28, per acceptance criteria)
p2panda-encryption — ADOPTED (already, in Phase 4).
35726e8e),pkgs/id/src/encryption/mod.rsopens: "Group encryption on theDataSchemeofp2panda-encryption(Phase 4, P4.1 to P4.6 and P4.8 to P4.13)" — per-device/group sessions, epoch rotation on create/update/add/remove/recovery, history modes, welcomes. The group-encryption half of this issue's TODO item is built and shipped on this candidate.pkgs/id/Cargo.toml:72:p2panda-encryption = { path = "vendor/p2panda-encryption", … }, vendored copy is exactly 0.7.1) and the sibling p2panda crates are pinned to a fixed git rev (da80c05b…). Adoption is therefore pinned and auditable in-tree, not a floating pre-stable dependency.keyhive / BeeKEM — DEFER (do not adopt).
Decision
pkgs/id/TODO.md:251-253: whether past content is re-keyed on removal, encryption at rest for world stores/outbox, and keyhive-style authorization grants. Those are separate roadmap items, not part of the candidate choice.Closing this issue as completed: its acceptance criteria (evaluation recorded with stability status, no unreviewed pre-stable adoption, decision recorded) are now met. If Drew wants the BeeKEM revisit tracked as its own open item when the trigger fires, this note is the record to file it from.