Merge origin/main into the chat encryption work

Both sides landed a breaking MNP change and both called it 2.0, which is right:
the sealed upload, the removal of `stream_seg` and mandatory chat encryption
share one flag day. They are recorded as one version in `__init__.py` rather
than as a race between two.

The resolutions that were decisions rather than mechanics:

* **`MNP_MIN_SUPPORTED` moves to "2.0".** The sealed upload alone was a
  *confined* break — a 1.x peer could still connect, browse, download, stream
  and chat, with only its uploads refused by `upload_not_sealed` — so the floor
  deliberately stayed at "1.0". Mandatory chat encryption ends that
  confinement: a 1.x peer can neither produce a sealed chat message nor read
  one, so it would connect, look fine, and be unable to say anything. Refusing
  it at the handshake is the honest form. The per-message `upload_not_sealed`
  path is untouched and still right if the floor is ever lowered.
* **`sendChat` throws on an `error` reply**, from origin, applied to the sealed
  send. It matters more after this change, not less: the node now refuses a
  stale epoch, a malformed envelope and a device claim that is not the
  connection's own, so there are three new ways for a message to be rejected
  and none of them may look like a message that was sent.
* **`req_id` supersedes the per-type routing** this branch added for
  `chat_keys_resp` and `device_hello_ack`. Both blocks are kept beside the
  existing `chat_hist_resp` one, for the same stated reason — a node too old to
  stamp — and their comments no longer claim to be the mechanism that closes
  the class. `req_id` is.
* **`chat_send_probe.py` is rebuilt on origin's structure**, not beside it: two
  scenarios, a stub that stamps `req_id`, `music_meta_req` as the older pending
  request. The encrypted path is layered on — a real Ed25519 device key
  generated in the page, and a `chat_keys_resp` sealed by the shipped Python,
  because a payload the page built itself would prove only that the page agrees
  with the page.
* **`test_reply_correlation.py` now sends a sealed message.** Its subject is
  which of the two messages leaving that handler carries the id; plaintext chat
  was only the fixture, and the node refuses one now.
* `groupbox` keeps both new purposes (`upload`, `chat_keys`); `protocol.py`
  keeps origin's removal of `STREAM_SEGMENT` and this branch's correction of
  the "Double Ratchet message" comment on `CHAT_MESSAGE`, which was wrong when
  it was written and is wrong differently now.

Full suite on the merged tree: 1993 passed, 11 failed — the same 11 that fail
on a pristine checkout (2 Windows service tests, 1 apps-enabled policy, 7
transcode tests that pass in isolation, and the WebRTC invite test that hangs
on its own).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TZZxYjz8YeWRz13xDi8LJr

1 files changed, 17 insertions, 0 deletions

diff --git a/packages/meshbay-common/src/meshbay_common/groupbox.py b/packages/meshbay-common/src/meshbay_common/groupbox.py
index ff60bba..e020ed8 100644
--- a/packages/meshbay-common/src/meshbay_common/groupbox.py
+++ b/packages/meshbay-common/src/meshbay_common/groupbox.py
@@ -24,6 +24,14 @@ and group configuration. It buys nothing against a network observer (DTLS/TLS
 already covers that), nothing against the hub (it never sees channel traffic), and
 nothing against a member — who holds the GEK. That is the whole claim.
 
+**Both, for the upload (MNP 2.0).** `file_upload` carried the filename and the raw
+bytes in clear, and `file_upload_ack` carried the name it was stored under. The
+download path had been sealed end to end since the beginning — so the same file was
+ciphertext coming out of a node and plaintext going in, which is not a threat model,
+it is an oversight. The node holds the GEK for its own group, so unlike the index
+this direction seals *towards* the node: it opens the payload before it writes
+anything to disk, and refuses a chunk that does not open rather than guessing.
+
 Purpose separation is deliberate. `GroupIndex.serialize()` reuses
 `chunk_key_aes(gek, file_hash, chunk_index)` with a pseudo-file ("the index as chunk
 0 of a virtual index file"), which borrows a file's key space for something that is
@@ -41,6 +49,7 @@ from cryptography.hazmat.primitives.kdf.hkdf import HKDF
 
 PURPOSE_INDEX = "index"
 PURPOSE_ACK = "ack"
+PURPOSE_UPLOAD = "upload"
 # The chat epoch keys themselves, on their way to a member. The keys are what
 # the chat archive is encrypted under; this is only how they travel, which is
 # why rotating the group key costs a re-wrap and not a re-encryption.
@@ -52,9 +61,17 @@ PURPOSE_CHAT_KEYS = "chat_keys"
 _INFO = {
     PURPOSE_INDEX: b"meshbay:index:v1",
     PURPOSE_ACK: b"meshbay:ack:v1",
+    PURPOSE_UPLOAD: b"meshbay:upload:v1",
     PURPOSE_CHAT_KEYS: b"meshbay:chat_keys:v1",
 }
 
+# One subkey per purpose, and `seal` draws a fresh 96-bit nonce per message, so
+# the bound that matters is birthday collision under `PURPOSE_UPLOAD` — the only
+# purpose with real volume, one message per 48 KiB chunk. 2**32 chunks is 200 TB
+# uploaded under a single GEK before the collision probability reaches 2**-32,
+# and `gek_rotate` exists. Deriving the nonce from the payload instead would be
+# worse, not better: two chunks of identical bytes are ordinary in a file.
+
 NONCE_LEN = 12   # 96-bit, the WebCrypto AES-GCM standard