extant2000/flamenet-e2e
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

The other side of a message the app sent #77

Merged
extant2000git merged 1 commits from bridge/the-apps-peer into main 2026-10-14 22:17:47 +00:00
Conversation 0 Commits 1 Files Changed 3
+279
extant2000git commented 2026-10-14 22:16:56 +00:00
Owner
Copy Link
Copy Source

bridge-message.mjs proves the bridge and the relay with this engine on both ends, which leaves the apps untested: their own socket factory, sign-up, device registration and send are a different code path. The Android suite BridgeMessageTest (extant2000/flamenet-messenger-android#192) drives that path over a live bridge and can only assert what the app's own screen says.

This is the independent half: it signs up a peer, publishes a device, and decrypts what the app sealed, holding nothing but the peer's keys.

Proven 2026-10-14, Android on an emulator through the live obfs4 bridge to relay1.flamenet.io:

3 envelopes, message numbers 0,1,2
  n=0 control: delivery_key
  n=1 control: kt_head
  n=2 MESSAGE from user 1613: through a bridge from the app at 88070

The caption is the exact text the app's own log says it sent, so both ends agree on the words. That closes the claim made to OTF on 2026-09-28: a message composed in the app, carried over obfs4, and read by somebody else.

Three things this cost, each one making the data look like a defect:

  • Nothing here acknowledges a message, so every poll returns the same envelopes. Counting them per poll turned three into sixty and sent me looking for a fan-out bug that does not exist. The earlier note on PR 192 about 60 envelopes was this, and it is withdrawn.
  • The ratchet opens in order. respond belongs to the envelope with header.n === 0 and the rest decrypt on that session. Responding afresh to each one fails with Cipher job failed, which says nothing about chain keys and reads like an interop bug.
  • kind: "text" IS the message, with the words in caption. Filtering out everything carrying fnc threw the message away along with the delivery key and the key-transparency head.

Not in npm test: it needs a live relay and an app to send something. bridge-peer.json holds a real credential and is ignored.

Secret sweep clean across 87 files.

🤖 Generated with Claude Code

`bridge-message.mjs` proves the bridge and the relay with this engine on both ends, which leaves the apps untested: their own socket factory, sign-up, device registration and send are a different code path. The Android suite `BridgeMessageTest` (extant2000/flamenet-messenger-android#192) drives that path over a live bridge and can only assert what the app's own screen says. This is the independent half: it signs up a peer, publishes a device, and decrypts what the app sealed, holding nothing but the peer's keys. **Proven 2026-10-14**, Android on an emulator through the live obfs4 bridge to relay1.flamenet.io: ``` 3 envelopes, message numbers 0,1,2 n=0 control: delivery_key n=1 control: kt_head n=2 MESSAGE from user 1613: through a bridge from the app at 88070 ``` The caption is the exact text the app's own log says it sent, so both ends agree on the words. That closes the claim made to OTF on 2026-09-28: a message composed in the app, carried over obfs4, and read by somebody else. **Three things this cost, each one making the data look like a defect:** - Nothing here acknowledges a message, so every poll returns the same envelopes. Counting them per poll turned three into sixty and sent me looking for a fan-out bug that does not exist. The earlier note on PR 192 about 60 envelopes was this, and it is withdrawn. - The ratchet opens in order. `respond` belongs to the envelope with `header.n === 0` and the rest decrypt on that session. Responding afresh to each one fails with `Cipher job failed`, which says nothing about chain keys and reads like an interop bug. - `kind: "text"` IS the message, with the words in `caption`. Filtering out everything carrying `fnc` threw the message away along with the delivery key and the key-transparency head. Not in `npm test`: it needs a live relay and an app to send something. `bridge-peer.json` holds a real credential and is ignored. Secret sweep clean across 87 files. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
extant2000git added 1 commit 2026-10-14 22:16:57 +00:00
The other side of a message the app sent
ci / vault (pull_request) Successful in 4s
Details
ci / conformance (pull_request) Successful in 10s
Details
ci / secret-sweep (pull_request) Successful in 6s
Details
ci / ratchet (pull_request) Successful in 6s
Details
ci / doc-references (pull_request) Successful in 4s
Details
ci / complete (pull_request) Successful in 4s
Details
ci / client (pull_request) Successful in 31s
Details
ci / spec-counts (pull_request) Successful in 29s
Details
776875d11b 
bridge-message.mjs proves the bridge and the relay with this engine on
both ends, which leaves the apps untested: their own socket factory,
sign-up, device registration and send are a different code path. The
Android suite BridgeMessageTest drives that path over a live bridge and
can only assert what the app's own screen says.

This is the independent half. It signs up a peer, publishes a device,
and decrypts what the app sealed, holding nothing but the peer's keys.

Proven 2026-10-14, Android on an emulator through the live obfs4 bridge
to relay1.flamenet.io:

  3 envelopes, message numbers 0,1,2
    n=0 control: delivery_key
    n=1 control: kt_head
    n=2 MESSAGE from user 1613: through a bridge from the app at 88070

The caption is the text the app's own log says it sent, so both ends
agree on the words.

Three things this cost, each one making the data look like a defect:

- Nothing here acknowledges a message, so every poll returns the same
  envelopes. Counting them per poll turned three into sixty and sent me
  looking for a fan-out bug that does not exist.
- The ratchet opens in order. `respond` belongs to the envelope with
  `header.n === 0` and the rest decrypt on that session; responding
  afresh to each one fails with `Cipher job failed`, which says nothing
  about chain keys.
- `kind: "text"` IS the message, with the words in `caption`. Filtering
  out everything carrying `fnc` threw the message away along with the
  delivery key and the key-transparency head.

Not in `npm test`: it needs a live relay and an app to send something.
`bridge-peer.json` holds a real credential and is ignored.

Secret sweep clean across 87 files.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
extant2000git merged commit dab98f2931 into main 2026-10-14 22:17:47 +00:00
extant2000git deleted branch bridge/the-apps-peer 2026-10-14 22:17:48 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
accuracy
A public page or doc claims something the code does not do
 blocked:apple
Waiting on App Store review
 docs
ops
Deploy, CI, infrastructure
 parity
One platform has it and the other does not
 privacy
Changes what is stored, or what we say is stored
 protocol
unwired
Built in the engine, not reachable from the UI
 verification
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
extant2000git
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: extant2000/flamenet-e2e#77