One optional tag -- `["subgroupFor", "<kind>", "<id>"]` -- and it is the whole of
the link between a subgroup and the dialect, artifact, translation or project it
was made for. The certificate is the only artefact in the relationship that is
signed, travels, and is already read on both sides, so the link goes there
rather than in a local column nobody else can see or a room name that is not an
identity.
The signature already covers the tags, since an event id hashes over them, so
nothing is added to the claim by putting it there -- only to what a parent admin
can see before agreeing. That is the same bargain `SubgroupKeyTag` made.
Both halves or neither. An id alone would have to be looked up in four tables to
be understood, and a reader without the kind cannot tell "a project this device
does not hold" from "not a project at all"; a kind alone names a category. The
pair follows `PayloadKindTag`/`PayloadIdTag`, which carry the same two for the
same reason.
The tag sits after the named tags and before the run of `p` tags, and the
position is load bearing rather than incidental: a reader that predates this
takes the tags it knows off the front and ignores the rest, while one inserted
into the admin run would split the founding roster for anybody reading
positionally. `SubgroupLineage` fixes its order for the same kind of reason, and
a test asserts the position rather than trusting the comment.
`certifies` is untouched, and that is the point of the third test. The origin
joins the name and the `p` tags as founding history: a certificate may name a
row this device will never hold, because a subgroup's members need never have
been in the parent, and a certificate with no origin at all is valid because
every one signed before today has none. What the quorum signs is the intention
that the room be for that entity; nothing vouches that the entity exists, and
nothing can.
Phase 4 of docs/subgroups-for-entities.md.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Kgothatso NgakoandClaude Opus 5
8d1e341131