Phase 3 of docs/subgroups-multiple-parents.md, the two consent surfaces. The note
calls the first of these the one change in the design that is not plumbing, and it is
the only one that would have shipped a member a question they could not read.
**`ProposedEvent`'s 30326 arm showed a derivation path and a ceremony id.** That was
right while a key state was proposed once, at founding, by the coordinator who chose
its lineage: the only question was which key the room signs with. A key state can be
re-announced now, and that is exactly how a group is adopted -- its own quorum accepts
a parent by signing a state that names one. A member approving that is deciding whether
their group should answer to another, and `m/9420/0/0 · a1b2c3d4e5f6` answers a
question nobody asked. The proposal is their only chance to check, since after it a
quorum has spoken.
So the parents lead when there are any, counted when there is more than one, in the
lineage's canonical order so two devices describe one proposal the same way. The
certificates are already in the tags the signature covers, so this costs a reader
nothing it does not hold. What the summary cannot say is which parents are being
*dropped*: that is a difference against the row this device holds and a summary is
pure, so it belongs to the screen, and there is a comment where somebody will look for
it.
**And the child's room now hears the offer.** `ChatMessage`'s 30329 arm assumed a
certificate in a room was that room's own act, because at founding it always is. An
adoption signs the certificate first, in the adopting group, and the child's admins had
no notice of it at all -- the first thing they would see is a proposal wanting their
signature. Founding at least shows them the intent, since `DkgRitualEvents` puts
`parent_group` on the ceremony proposal and the ritual screen names the group; adoption
has no ceremony and so no hint.
`SubgroupManager.classify` is the decision, pure and needing no database -- `certifies`
checks a signature against a room id, and a room id is a public key, so an offer can be
believed by a device that has never held the offering group's room. Two true things a
certificate can be, and the room it arrived in is the whole of the difference: this room
signed it about another, or another signed it about this one. A third room's business is
nothing here whoever signed it.
`TYPE_SUBGROUP_ADOPTION_OFFERED` writes a line and files nothing. It cannot file
anything -- `GroupSignedEvent` declares a foreign key onto `ChatRoom`, so a child device
with no row for the parent could not store the event -- and it does not need to, because
the certificate reaches these devices for real inside the key state that accepts it. The
wording carries that: a subgroup of theirs *only once this group agrees what it signs
with again, naming them*. An offer rendered as a fact about the lineage would be the
whole gap reopened from the other end.
**A test found a real one while writing this.** A group can sign, truthfully by every
check `certifies` makes, that it is its own parent: author, subject and named parent one
room, the id deriving from the key, the signature verifying. The self-parent guard
started out inside the offer branch, where it never ran -- the child branch catches such
a certificate first and reads it as an ordinary child, which would put a group in its
own list of subgroups. It is refused ahead of both branches now, and the test is named
for what it pins rather than for the branch it was written against. That case predates
this commit: `subgroupsOf` would have listed it today.
Eleven tests. Six for `classify` in `SubgroupBirthCertificateEventTest`, which is where
the three real quorums already are and where every case it decides is a question about a
certificate; four for the summary in `ProposedEventTest`, including a state claiming a
lineage it cannot state, which must read as the key alone rather than guess. One icon arm
in `ChatTranscript`, because a subgroup type missing from that mapping renders as a chat
bubble and looks exactly like a member having said it.
454 common tests, 947 jvm tests, `m3Audit` meets every budget.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
e81659bf3b