Every messaging operator is untrusted.

The verdict everything follows from

SHARING-SPEC-v0.1's I7 already says a transport-sealed envelope must refuse an untrusted transport. The new decision for text-message transport is who counts as untrusted. The rule is uniform:

There is no per-channel matrix here, because a matrix rots the moment a platform changes its backup design. Every messaging channel gets the same verdict, and the code forces it: configure_text_courier() hardcodes trusted: false in Together/courier.yaml, and _require_text_courier() re-asserts the refusal even if that file is hand-edited to say otherwise. Consequence: every envelope sent by text-message transport must already carry sealing: "e2e". Nothing less is ever handed to Messages.

What the module does, and where it stops

pna_text_courier.py imports pna_share.py wholesale and reuses its reducer, its compose functions, its HMAC verification, and, critically, its entire receive-side gate stack (pairing, authenticity, authority, idempotency, hostile-input bounds) unmodified. This module adds exactly three things shared-folder transport doesn't need:

• Framing — a sealed envelope becomes text lines and back.
• Pairing by phone — public keys over text, a spoken ceremony as the MITM defense.
• The spoken rung — a record for a contact with no PNA at all.

It does not talk to Messages, iMessage, or any carrier API. The bridge is a human: compose → frame → copy into Messages → send, and the reverse on receipt. That is a design decision (spec §7 — "the person is the last hop"). Any later automation of that hop will be said out loud here.

The wire frame

A typical PROPOSE is one iMessage message or ~1 KB of chunked SMS. frame_for_text() refuses at the first line of code if env["sealing"] != "e2e" — there is no path from a transport-sealed envelope into a text frame.

Reassembly under a hostile channel

ReassemblyBuffer keys chunks by index. Arrival order is ignored, so loss, duplication, and reordering all resolve correctly without special-casing:

• Reordered chunks reassemble identically to in-order ones, because the buffer is keyed by index.
• Duplicated chunks are last-write-wins on their index: a resent chunk overwrites what was there. The buffer never grows from a duplicate.
• Lost chunks simply never complete the set. pending_count() stays > 0, so nothing ever reports a false complete.
• Malformed lines fail the frame grammar and are dropped with {"status": "ignored"}. No exception ever reaches the caller.
• Corrupted payloads that pass the grammar but fail to decode once the set completes surface as {"status": "corrupt"}.
• Bounded. A total above MAX_CHUNKS_PER_ENVELOPE (64) is refused before it can consume memory; partial buffers older than REASSEMBLY_TTL_SECONDS (15 min) are purged on the next add_line() call.

This extends pna_share's own hostile-input discipline (I10) one layer earlier, to the channel that hands bytes to the parser in the first place. None of that handling is duplicated here.

Pairing over text, with nothing secret on the wire

The card exchanged by text (KSPCARD {...}) carries only a contact id and the existing age_recipient public key — the same X25519 recipient string pna_share's optional e2e sealing already uses. Public keys are public; the carrier may read the card freely.

The two people speak the six words to each other — by voice call, video, or in person. complete_text_pairing() takes an explicit spoken_fingerprint_matched boolean and raises if it isn't True. No roster card is saved in that case. There is no code path to a paired contact that skips the human attestation.

If a carrier substitutes a public key toward one side, the two participants receive different six-word fingerprints because each fingerprint derives from the keys that side received. The spoken comparison detects that mismatch.

The pairwise HMAC secret pna_share needs for envelope authenticity is then derived (sha256("pair-secret-v1:" + sorted(key_a, key_b))) from the two public keys, computed identically on both sides. No elliptic-curve math is implemented here (stdlib has none); this is the v0.1 star-topology-appropriate authenticity root, arrived at over text with a spoken check standing in for meeting in person. It carries none of the Ed25519 non-repudiation the spec schedules for v0.2 introductions.

The spoken rung

A neighbor with no PNA still gets an invitation. It goes by ordinary text, with no envelope and no seal. record_spoken() writes Together/events/<evt>/spoken.yaml and nothing else. It never touches exchange/, and it never calls the reducer. So it can never produce an agreed state, and it never acquires CONFIRM/CANCEL authority. Recording a spoken note against a real sealed thread's event id changes nothing about that thread's actual, reducer-derived state, verified directly (test B6).

Enforced versus recorded

Run it yourself

Every archive in the test suite is a throwaway under tempfile; ~/PNA was never touched by this build.

Attack here

Good-faith security research is welcome through the main site's Write to us → security door — a safe harbor written into our Terms, §15.

• The fingerprint ceremony's UX — does a real human actually compare six words carefully, or thumb past them? (A protocol problem no code fixes.)
• The derived pair-secret's key-derivation function — sha256(sorted-keys) is a placeholder; it should be reviewed against HKDF before this ships live.
• Correspondence metadata — sealing hides content. The fact of texting stays visible; a carrier still sees who-texts-whom-when regardless of anything in this module.
• The reassembly TTL and chunk cap under a adversarial sender, flooding many partial env8 buffers on purpose.
• The share-sheet bridge itself, once built — an unbuilt attack surface named above.

Where this stands