From 3d4080e9a1b79e99428a80391e224ea73cf4274d Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Wed, 16 Sep 2026 17:24:10 +0200 Subject: playlists: drive the blob ops over a real DataChannel MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The six MNP 3.1 ops were the only new ones never crossing a channel in a test. Two cases on the existing aiortc harness: a round trip read back on a second connection, and a 256 KB body. Found that the 1 MB body cap is unreachable from a browser — docs/playlists.md §15.3. Co-Authored-By: Claude Opus 5 --- docs/MESHBAY_NODE_PROTOCOL.md | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'docs/MESHBAY_NODE_PROTOCOL.md') diff --git a/docs/MESHBAY_NODE_PROTOCOL.md b/docs/MESHBAY_NODE_PROTOCOL.md index 47c3636..2682820 100644 --- a/docs/MESHBAY_NODE_PROTOCOL.md +++ b/docs/MESHBAY_NODE_PROTOCOL.md @@ -654,6 +654,12 @@ already holds a bundle for, so this adds **no new trust boundary**. * **Caps refuse, never truncate**: 64 KB for the manifest, 1 MB for one body, 8 MB per account per node, each with a stated reason. A truncating cap loses tracks silently, which is the failure the design exists to prevent. + * The 1 MB body cap is **not the binding one**. A browser cannot send a frame + above the negotiated `max-message-size`, which aiortc fixes at **65 536**, + so a client tops out near 64 KB per write however high this cap is set — + the same constraint that keeps uploads chunking at 48 KB. Reads are not + limited that way: the node answers with a whole body of up to 1 MB. See + `docs/playlists.md` §15.3. * A `fetch` for a kind never written answers `null`, not an error: that is the ordinary state of a node the reader has just joined. * The node keeps **no history**. The client is the authority on which revision -- cgit v1.2.3