Files
amethyst/cli/tests/marmot
Claude 46845d9058 fix(marmot): frame published KeyPackages as MLSMessage — interop test 01 passes
Test 01 (bidirectional KeyPackage discovery with MDK) now passes. It was
failing on a four-byte omission.

`foundation/key-packages.md`: "a transport publication is unambiguously
the framed MLSMessage, not a bare KeyPackage struct." We published bare
bytes. That is not a cosmetic difference — a reader expecting the envelope
reads a bare KeyPackage's leading 0x0001 0x0001 as version 1, wire format
1 (mls_public_message), parses on as a PublicMessage, and dies several
fields later on a byte that means nothing. MDK reported
`UnknownValue(112)`, a number that appears nowhere in a KeyPackage, which
is why this was invisible from our side: our own decoder round-tripped our
own bytes perfectly. Only a second implementation could find it.

The KeyPackageRef stays over the INNER KeyPackage, as RFC 9420
MakeKeyPackageRef defines — framing the ref too would make our `i` tag
disagree with everyone else's. Bare bytes are still accepted on read:
every KeyPackage we published before this is bare and still inside its
lifetime, and refusing them would leave our own users unable to invite
each other until all of them rotated.

With framing fixed MDK got one field further and rejected the next thing:
"mls_extensions tag does not exactly match decoded KeyPackage metadata".
Those id-list tags duplicate metadata already inside the KeyPackage, and
we were writing them by hand — so adding one leaf capability (the legacy
0xF2EE, added so our KeyPackages stay addable to existing groups) silently
invalidated every KeyPackage we published. They are now derived from the
KeyPackage itself and cannot drift. `app_components` lists the Marmot
registry ids only; the upstream MLS-extensions component ids below 0x8000
are not app components being advertised.

The harness needed one more fix: MDK 0.9.x reports a found KeyPackage
under `result.key_package`, and the harness probed two older shapes, so a
successful check read as a failure.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016kCuA6tc4JQzHPCDd39GHq
2026-09-08 23:11:02 +00:00
..