mirror of
https://github.com/vitorpamplona/amethyst.git
synced 2026-10-06 11:48:24 +00:00
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