meshbay.git/packages/meshbay-node/src/meshbay_node/transport/webrtc, branch 0.21

fix(node): datagrams straight through the socket on Windows' event loop

2026-10-16T10:28:25Z

The ProactorEventLoop's datagram transport keeps one overlapped operation per direction and starts the next from the previous one's completion, on a later turn of the loop: one datagram sent and one received per socket and per turn, however many wait. The busier the node, the slower every connection, with cores to spare. Measured on loopback with the loop busy 0.5 ms a turn: 1,928 datagrams sent a second and 1,954 received, 87 % of the rest dropped by the kernel. A browser's download from a node holding its connections ran at 9 MB/s, the node at 45 % of a core, SCTP round trip 745 ms. Now a datagram goes out with a non-blocking sendto when nothing is queued, and a completed read is followed by whatever the socket holds before the next one is posted. Two-core machine, 400 MB: CLI download 27 -> 33 MB/s, upload 18 -> 22, browser over eight connections 9-14 -> 17-19. Co-Authored-By: Claude Opus 5.5

perf: linear SCTP reassembly, one SACK every second packet, 4 MB buffer in the CLI

2026-10-16T08:41:17Z

aiortc walked a message's fragments after each one arrived (n^2/2 steps for a 1 MiB chunk) and acknowledged every packet. Measured on loopback, 400 MB to the CLI: 19 MB/s before, 39 after (49 by the node's count); uploads from the CLI 25 -> 29 MB/s. Co-Authored-By: Claude Opus 5.5

refactor(chat): no thread_id — chat has no threads

2026-10-15T10:57:51Z

Nothing ever set it (the page and the CLI sent null) and nothing read it (the node's get_thread had no caller). It is no longer sent by the page or the CLI, in clear or in the sealed payload, nor relayed or served by the node; get_thread and its index are gone, and the protocol and design docs no longer name it. The node still accepts a chat_msg carrying one, from the desktop apps and CLIs already installed, and drops it. The column stays, empty, in chat.db: a node downgraded to an older version names it in every query. Co-Authored-By: Claude Opus 5.5

fix(node): an operator who was a member first holds the authority at once

2026-10-15T10:32:24Z

A member pinned on the node who then redeems the operator pairing code was written down as the operator but the node kept its "nobody can authorize" flag until it restarted: every admin operation — removing a folder, inviting, the apps' settings — was refused meanwhile. Only a key paired fresh set it. The join result now names `operator` for an account holding the node-wide operator row, whatever its row in the group says. The page and the CLI read that role to know what to offer, and refused before asking deletions the node would have accepted. Nothing is granted by it: every admin operation is still checked against the operators' keys. Co-Authored-By: Claude Opus 5.5

fix(node): a chat-epoch notice answers no request, not even the asker's

2026-10-14T22:56:04Z

Revoking a device or removing a member opens a chat epoch, announced to everyone connected to the group, the asker included. Sent inside the handler, the asker's copy was stamped with its request's id and arrived as the answer to device_revoke, before the real one. It now leaves outside the reply context. Co-Authored-By: Claude Opus 5.5

feat(node): accept a device link request before the proof (MNP 6.3)

2026-10-14T20:20:15Z

A new device of a known account holds no identity the node pinned, so it cannot complete a handshake until a pinned device approves it: it now files device_add_request in the pre-proof window, as the desktop app's case already required. The request stays inert until countersigned; at most 10 are pending per account, the oldest dropped. A 6.2 node answers it "Handshake required", which a client reads as "cannot link here". Co-Authored-By: Claude Opus 5.5

fix(node): index, serve and write files past Windows' MAX_PATH

2026-10-14T09:17:38Z

With the system's default setting (LongPathsEnabled off) every call given a plain path of 260 characters or more refuses it, so a deep library was partly invisible: the walk could not list such a directory and its files never reached the members. The node now hands each call that touches a group's disk the extended form (paths.long_path), and keeps the plain path in the index, the hash cache and the log. A directory is listed under its long form and its entries named from the plain one (indexer.walk_files, wire._walk_dirs). Covered: the walk, stats and hashing, reconcile and the watcher, the folder list members see, serving over WebRTC and QUIC, deletion, uploads and their recovery, folder creation and removal, audio tags and the cover beside a track, photos, and a show's episode numbering. ffmpeg extends a long path itself and keeps the plain one. long_path now normalises before prefixing (the extended form skips the system's normalisation) and starts at 248 characters, where creating a directory is already refused. test_long_paths.py runs with the setting off: 15 of its 17 tests fail without the change. Checked by hand in the installed app with files at 312 to 380 characters. Co-Authored-By: Claude Opus 5.5

feat: let the operator pause and resume a root's indexing (MNP 6.2)

2026-10-11T22:17:32Z

A whole-root walk now checks its root before every file: removed or ejected, it stops instead of reading the drive to the end; paused, it finishes from the hash cache alone. A paused root is not watched, not swept by reconcile and survives a restart (roster), its indexed files stay served. Resume runs the reconcile sweep over the root, so entries and their enrichment are kept. Signed root_pause / root_resume over MNP, loopback routes, CLI `root pause|resume`, a pause button on the indexing dock and pause/resume in the roots table of Group settings. Co-Authored-By: Claude Opus 5.5

fix(node): a receive buffer that holds an upload's window

2026-10-11T18:47:42Z

Uploads ran at 6.5 MB/s because the kernel dropped datagrams at the node's 256 KB socket. Asking for 4 MB gave 19.5 MB/s, no drop. Co-Authored-By: Claude Opus 5.5

feat(node): carry connections on several cores

2026-10-11T17:09:04Z

connection_processes (default 1) starts that many processes for the WebRTC stack; sessions and keys stay in the node. Set from node.toml or the Node page, applied to new connections. Co-Authored-By: Claude Opus 5.5