meshbay.git/packages/meshbay-node/src, branch 0.21

chore: bump version to 0.21.0

2026-10-17T21:15:02Z

Co-Authored-By: Claude Opus 5.5

fix(node): the answer log names its host addresses

2026-10-17T16:19:15Z

aiortc ends a host candidate line at `typ host`, so the match on " typ host " found none and logged `host: none` for every answer. Co-Authored-By: Claude Opus 5.5

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

feat(node): connection processes on by default, one per core up to four

2026-10-16T08:41:17Z

At 1 no process starts and every lane of a download lands on the node's one core. The Node page also sent every setting on each Save, pinning untouched ones at the day's default; it sends only what changed. 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

chore: bump version to 0.20.0

2026-10-15T15:45:41Z

Co-Authored-By: Claude Opus 5.5

test(node): the event-loop disk guard watches os.stat again

2026-10-15T12:37:45Z

test_a_scan_asks_the_disk_nothing_from_the_event_loop patched Path.stat, and since the indexer learned Windows' long paths it calls os.stat(long_path(p)) and os.scandir instead: the guard saw no call at all, and asserting that the calls ran on the indexer's thread failed on an empty set. It watches os.stat and os.scandir now (Path.stat goes through os.stat too), counting what the root holds and not the root, whose availability check runs on the roots' I/O thread. Nothing runs on the loop; a stat added there makes it fail again. The node CLI's parser names itself: under `python -m pytest`, Python 3.14 named the program after the module, so test_cli_golden saw "python -m pytest" in the help. The installed meshbay-node was not affected. Co-Authored-By: Claude Opus 5.5

fix(node): a removal made at the machine is in audit.db

2026-10-15T12:24:44Z

The Node page and the CLI remove access through the loopback API, and revoke and unpin there wrote nothing to audit.db; only the signed MNP door did. A removed person's next connection then showed an auth_failed with nothing before it to explain it. Both routes now record member_revoke and member_unpin once the operation has succeeded, with the node's own account as the actor and 127.0.0.1 as the address, which tells the two doors apart. A refusal changes nothing and records nothing. 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