Phase 1 of docs/subgroups-multiple-parents.md, the wire. It ships dark: the event
can now state a lineage of any size and nothing in this build produces one of more
than one, because the row that would hold it does not exist until the next phase.
A room's lineage was never really a field. `GroupKeyState` carried one parent and one
certificate because a group was founded with a parent and never gained another; the
moment it can be adopted, "the parent" is a set that had only ever held one thing.
**`SubgroupLineage` is that set, and it holds the two invariants a caller cannot be
trusted to remember.** No parent twice -- two entries naming one group is one parent
asked twice, and `of` refuses rather than folding them, because each carries its own
certificate and picking one would be this device deciding which of the parent's
statements counts. And one canonical order, sorted by parent id, so two devices
assembling the same lineage from the same certificates emit the same bytes. `plus` and
`minus` are the two edits an adoption and a disavowal make; `minus` returning null is
"nobody's child" rather than a failure, and revokes nothing -- a certificate is a
signature and exists forever, and what it removes is the child's half of the link,
which is the half that decides.
**The pairs are adjacent, and that is for other people's builds.** A reader that
predates this takes the first `parent_group` and the first `birth_certificate` off the
tags and checks them against each other. Emitted as `id, certificate, id, certificate`
it gets one real parent and that parent's own certificate, verifies them, and files a
true but partial lineage -- one parent, correctly. Emitted as all the ids and then all
the certificates it would pair the first id with a certificate that may belong to
another parent, fail `certifies`, and drop the **whole state** -- losing the row that
says which ceremony's share signs for that room, which is a worse outcome than not
knowing about the second parent. The sort is what makes the pairing deterministic
rather than incidental.
**`parseLineage` counts each half twice, by tag name and by successful parse.** A half
that is present and broken reads as absent through a parser, and only the broken kind
would slide the pairing along by one and pair an id with somebody else's certificate.
So an uneven number of halves, a half that does not parse, and a repeated parent are
all refused, and `claimsParentage` -- unchanged, reading tag names alone -- is still
what tells "claims nothing" from "claims something unreadable".
**Two places refuse a second parent for now, and say so rather than truncating.**
`propose` checks the lineage is one before it builds a row that can only hold one, and
`parentageOf` drops a state claiming more. Taking the first of two would file a lineage
the group did not sign and leave the device believing a group has one parent while its
own members see two -- the same reasoning the existing all-or-nothing rule is built on.
Nothing emits a second yet, so neither fires except on a state from a newer build,
which is exactly the case that wants refusing rather than guessing.
`SubgroupParentage` is untouched: still one pair, still unchecked, still the thing a
lineage is made of.
Nineteen tests. `SubgroupLineageTest` is new and pure, with no crypto at all -- the
certificates in it are deliberately nonsense, because whether one is good is
`certifies`' question and is asked on every read rather than at the door; it pins the
two invariants, case-insensitivity on both, and that a certificate rides along with its
own parent through the sort. Five go to `GroupKeyStateTest`, and the one worth keeping
if any of this is rewritten asserts the *tag order* and then that the first id and the
first certificate an older reader would take are a matched pair.
443 common tests, 933 jvm tests, `m3Audit` meets every budget.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Kgothatso NgakoandClaude Opus 5
0690932252