Kotlin content interop commands (e2e#4) #93

2026-09-05T10:07:10Z

paulhitt commented

2026-09-05 10:07:10 +00:00

(Migrated from gitlab.com)

The interop driver dispatched 19 commands — device, initiate, encrypt, seal,
log_leaf — and not one touched a content envelope. Swift has had
content_encode/content_parse for a while; Android has never been checked
against any other implementation at this layer.

This is the half that most needed it. SPEC.md §6.10 says so in as many
words, after the ctl:true bug: "no vector covers this envelope. It is the
standing argument for the interop harness." That bug was Android writing
"ctl":true where iOS decoded a number — and the cost was not a missed flag
but a failed decode that dropped the whole message onto the plaintext path,
while each engine's own tests passed on both sides.

The two parsers fail DIFFERENTLY, which is why a round-trip on either
proves so little. This engine reads field by field through org.json, whose
bundled Android build coerces a JSON null to the string "null" where Maven's
returns "". iOS decodes all-or-nothing through Codable, so one bad field
downgrades the entire envelope to a raw-JSON bubble. The same additive change
degrades differently on each platform.

content_parse also reports isControl, so the harness can check §6.10's
rule across engines instead of each engine checking itself.

The matching harness stage is flamenet-e2e!27. Proven by breaking it: making
this engine read the SPEC's ment instead of the shipped men turned
"iPhone mentions parse on Android" red — the exact drift that has been
invisible since the key was chosen.

1190 tests still pass.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

The interop driver dispatched 19 commands — device, initiate, encrypt, seal, log_leaf — and not one touched a content envelope. Swift has had `content_encode`/`content_parse` for a while; Android has never been checked against any other implementation at this layer. **This is the half that most needed it.** SPEC.md §6.10 says so in as many words, after the `ctl:true` bug: "no vector covers this envelope. It is the standing argument for the interop harness." That bug was Android writing `"ctl":true` where iOS decoded a number — and the cost was not a missed flag but a failed decode that dropped the whole message onto the plaintext path, while each engine's own tests passed on both sides. The two parsers fail DIFFERENTLY, which is why a round-trip on either proves so little. This engine reads field by field through `org.json`, whose bundled Android build coerces a JSON null to the string "null" where Maven's returns "". iOS decodes all-or-nothing through `Codable`, so one bad field downgrades the entire envelope to a raw-JSON bubble. The same additive change degrades differently on each platform. `content_parse` also reports `isControl`, so the harness can check §6.10's rule across engines instead of each engine checking itself. The matching harness stage is flamenet-e2e!27. Proven by breaking it: making this engine read the SPEC's `ment` instead of the shipped `men` turned "iPhone mentions parse on Android" red — the exact drift that has been invisible since the key was chosen. 1190 tests still pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

paulhitt commented

2026-09-05 10:07:10 +00:00

(Migrated from gitlab.com)

assigned to @paulhitt

paulhitt (Migrated from gitlab.com) scheduled this pull request to auto merge when all checks succeed 2026-09-05 10:07:47 +00:00

paulhitt commented

2026-09-05 10:08:13 +00:00

(Migrated from gitlab.com)

mentioned in commit 7d343c5222

mentioned in commit 7d343c5222b5c5df6213941a3abda7eee2954c2a

paulhitt (Migrated from gitlab.com) merged commit 7d343c5222 into main

2026-09-05 10:08:13 +00:00

paulhitt commented

2026-09-09 19:01:18 +00:00

(Migrated from gitlab.com)

changed the description

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: extant2000/flamenet-messenger-android#93