Repository navigation
Releases: baditaflorin/aivoicebus
Release list
aivoicebus 0.11.5
Mixed-version gate: passed (scripts/compat.sh, record compat-pass.txt).
0.11.5: tasks waiting for the person show at session start
A task meant for the person (a token hand-over, an approval, a question, or task HOST --person, including fleet update's request to update) went to the person's own queue, which only aivoicebus status, queue and standby read: in a normal session it sat unseen. Now:
- The session-start and prompt hooks say when a task waits for the person on this machine, in one line with the command to run in your own terminal, and tell the agent to relay it, not act on it. They never mark it read: it stays the person's.
fleet update --applyalso reaches machines too old to show that line, with an ordinary note their agents relay, and does not send a second request while one is still open. (#79)
Upgrade every machine (aivoicebus update); nodes need nothing new.
Checks: scripts/check.sh (race tests, smoke transcript, mesh lab 358/358) on the release commit; two builds byte-identical; mixed-version gate 1681/0 against every release since 0.1.0; the signed-update rehearsal from 0.11.4 passed twice in a row with all seven attacks refused.
aivoicebus 0.11.4
Mixed-version gate: passed (scripts/compat.sh, record compat-pass.txt).
0.11.4: aivoicebus fleet
aivoicebus fleetshows every machine heard from in the last 7 days: its role (client, node, deploy), when it was last heard, the client release it runs, and the token it uses, as the nodes saw them; machines that may be behind the nodes are marked.aivoicebus fleet updateis the plan for bringing them up to date;--applysends each machine that is behind (or whose release no node knows yet;--only-behindleaves those out) a task for the person there:aivoicebus update. No agent takes it: replacing the binary is the person's to approve.- Clients say their release with every request (
X-Aivoicebus-Client); nodes keep the last one per machine, across restarts, and keep only a release-shaped value. Machines on clients before 0.11.4 show as "unknown" until they update. (#77) - The test scripts no longer report a matched check as failed:
printf | grep -qunder pipefail failed when grep quit early (shown: 20 of 20 false failures on a large output). (#76)
Upgrade the nodes and every machine (aivoicebus update; aivoicebus fleet update --apply asks the person on each).
Checks: scripts/check.sh (race tests, smoke transcript, mesh lab 358/358) on the release commit; two builds byte-identical; mixed-version gate 1564/0 against every release since 0.1.0; the signed-update rehearsal from 0.11.3 passed twice in a row with all seven attacks refused.
aivoicebus 0.11.3
Mixed-version gate: passed (scripts/compat.sh, record compat-pass.txt).
0.11.3: status agrees with doctor on the deploy machine
0.11.2 made doctor say the deploy machine's shared token is right; status still warned, because it kept its own copy of the rule. Both now use the same check (machine tokens kept here): on the machine you deploy from, status shows "right here, this machine deploys" and lists no problem; elsewhere the fix names that exception. (#74)
Upgrade every machine (aivoicebus update); nodes need nothing new.
Checks: scripts/check.sh (race tests, smoke transcript, mesh lab 358/358) on the release commit; two builds byte-identical; mixed-version gate 1451/0 against every release since 0.1.0; the signed-update rehearsal from 0.11.2 passed twice in a row with all seven attacks refused.
aivoicebus 0.11.2
Mixed-version gate: passed (scripts/compat.sh, record compat-pass.txt).
0.11.2: nodes remember which token each machine used; the deploy machine's shared token is right
- Nodes remember token kinds across a restart. After the 0.11.0 rollout, the token report said "unknown" for a machine on its own token, because the nodes kept
/v1/token/seenin memory only. They now keep it intoken-seen.jsonin the data dir (mode 600, written atomically at most every 5 seconds, the last change always written) and read it back at start. It holds token kinds and names, never tokens. (#72) doctorandstatusno longer warn on the deploy machine. The machine you deploy from keeps the shared token and holdsmachine-tokens/; there the token line is now OK. Elsewhere the warning names that exception, so it never tells anyone to give the deploy machine its own token. (#71)- The signed-update rehearsal runs the session-start hook again when it gives up silently on a busy machine. (#70)
Upgrade the nodes (the record is theirs) and every machine (aivoicebus update).
Checks: scripts/check.sh (race tests, smoke transcript, mesh lab 358/358) on the release commit; two builds byte-identical; mixed-version gate 1342/0 against every release since 0.1.0; the signed-update rehearsal from 0.11.1 with all seven attacks refused.
aivoicebus 0.11.1
Mixed-version gate: passed (scripts/compat.sh, record compat-pass.txt).
0.11.1: ask works with a short --wait-reply
Found in the live test of 0.11.0: aivoicebus ask HOST "question" --wait-reply 2m stopped with a usage error, because the default --claim-within (2 minutes) was not shorter than the wait. Unless you set it, --claim-within now fits inside the wait (half of it, at least 5 seconds). (#68)
Also: the mixed-version gate's conversation-states scenario expects the task refusal in a mesh with a node from before 0.2.0. (#67)
Upgrade every machine (aivoicebus update); nodes need nothing new.
Checks: scripts/check.sh (race tests, smoke transcript, mesh lab 358/358) on the release commit; two builds byte-identical; mixed-version gate 1237/0 against every release since 0.1.0; the signed-update rehearsal from 0.11.0 passed twice in a row with all seven attacks refused.
aivoicebus 0.11.0
Mixed-version gate: passed (scripts/compat.sh, record compat-pass.txt).
0.11.0: agents that ask, say where they stand, and get unstuck
Fourteen improvements, built in parallel: five for security, four for how agents work together, five for new users.
Security
- Sealed file links. A file sent to one machine has its key sealed for that machine, so the board's log holds nothing anyone else can open;
token handseals by default. (#53) aivoicebus incident: one guided leak response. It plans by default; with--applyat a terminal it revokes or rotates first, then retracts, then writes the audit entry. Agents cannot run it. (#56)- Signed-message readiness: who still sends unsigned,
mesh --signed-check, and a durable switch for--require-signed. (#63) - Token report: which machines still use the shared token, and
deploy/rotate-token.sh --check, which refuses to recommend a rotation that would cut a client off. (#60) doctorwarns when nothing on a machine can be approved by a person (no approver key, no phone, no terminal). (#51)
Agents working together
aivoicebus ask TARGET "question"(andaivoicebus_ask): it finds the session listening there, asks with safe limits, prints the answer, and exits with distinct codes for answered, nobody took it, and timed out. (#54)- Conversation states: offered, taken, ready, doing, done, stuck, declined. They show in
thread, the viewer and--wait-reply --json, a sender can--wait-state ready, and the token handoff runs on them. (#65) stuck: a blocked agent says so to the other side and the person. A task taken and then left silent (--quiet-after, 10 minutes by default) is reported to its sender. (#62)- Tasks meant for the person are never claimed by an agent (refused in code);
token handgoes to HOST/human, standby skips such tasks and says so once, and wait/standby take--only. (#58, #59)
New users
aivoicebus start: one guided first run, from nothing to an answered hello (19 s in testing). (#55)aivoicebus status: one screen showing where this session stands, each problem with its fix; also--jsonand MCP. (#57)aivoicebus demo: the bus at work offline, with two throwaway nodes and two invented agents, narrated. (#61)- Every error says what to do next: 275 errors had no next step, now 0, and a test keeps it that way; node refusals carry a reason. (#64)
- Local times with the zone, sessions named with title and state, and a warning when you target a session while another one there is listening. (#52)
Also: open metadata sealed in the pipe payload (#47), Antigravity session detection (#50).
Upgrade the nodes and every machine (aivoicebus update).
Checks: scripts/check.sh (race tests, smoke transcript, mesh lab 358/358) on every PR and on the release commit; two builds byte-identical; mixed-version gate 1136/0 against every release since 0.1.0 (and 117/0 against 0.10.3 and 0.10.4, where the full states scenario runs); the signed-update rehearsal from 0.10.4 with all seven attacks refused. Live tests used the real CLI and the real MCP server against throwaway nodes, with a script making an agent's calls; a run with real Codex is pending (usage limit until 2026-11-16).
aivoicebus 0.10.4
Mixed-version gate: passed (scripts/compat.sh, record compat-pass.txt).
0.10.4: a stuck token handoff says why
Found live on 0.10.3: handing the M1 Pro its token stalled three times with nothing said, and token hand waited its full 45-60 minutes to report only "no session said ready". The causes were a machine with no way to ask its person (no approver key, no notify URL, no terminal), an agent's tool call that ended before install could answer, and a standby session that claimed a handoff meant for the person's own terminal.
token installrefuses at once, and tells the deploy side why, when it can ask nobody; it names the fix (run it in a terminal there, oraivoicebus approver initonce).- While it waits for an approval it can get, the deploy side sees that it is waiting and for what;
token hand's timeout says which step stalled. - Clearer messages for a withdrawn or expired handoff. (#48)
Upgrade the machines that hand or receive tokens; nodes need nothing new.
Checks: scripts/check.sh (race tests, smoke transcript, mesh lab 342/342) on the release commit; two builds byte-identical; mixed-version gate 1037/0 against every release since 0.1.0; the signed-update rehearsal from 0.10.3 with all seven attacks refused.
aivoicebus 0.10.3
Mixed-version gate: passed (scripts/compat.sh, record compat-pass.txt).
0.10.3: 60 messages an hour per sender
A session that converses (a handoff, a review going back and forth) used its 20 messages an hour within one afternoon's tests. The per-sender limit is now 60 an hour. Runaways stay stopped by the machine's 300 an hour, the loop detector, the pair brake (which 0.10.2 fixed to count each message once) and --max-turns. (#45)
Upgrade the nodes (the limit runs there); clients need nothing new.
Checks: scripts/check.sh (race tests, smoke transcript, mesh lab 342/342) on the release commit; two builds byte-identical; mixed-version gate 944/0 against every release since 0.1.0; the signed-update rehearsal from 0.10.2 with all seven attacks refused.
aivoicebus 0.10.2
Mixed-version gate: passed (scripts/compat.sh, record compat-pass.txt).
0.10.2: the brake counts each message once; a machine gets its own token in one exchange
- Fix: the fast-reply brake counted every message twice. A client writes each message to two nodes, and each node then got the other's copy by replication and counted it again. Found live on 0.10.1 with Codex (refused at 13 messages with a limit of 24); it is also why handoffs between two agents tripped the old limit after 4 or 5 messages. Now one message counts once. (#43)
aivoicebus token hand <host>andaivoicebus token install: the deploy machine hands a machine its own token over the bus, encrypted end to end (through your nodes or the fleet pipe), the receiver checks it with the node before switching and puts the old one back on any failure, and the deploy side sees proof (/v1/token/seen). (#38, #39, #40)- The compat gate's own lookup no longer confuses node o010 with o0100. (#42)
Upgrade the nodes (the brake runs there) and the machines that hand or receive tokens.
Checks: scripts/check.sh (race tests, smoke transcript, mesh lab 342/342); two builds byte-identical; mixed-version gate 855/0 against every release since 0.1.0; the signed-update rehearsal from 0.10.1 with all seven attacks refused.
aivoicebus 0.10.1
Mixed-version gate: passed (scripts/compat.sh, record compat-pass.txt).
0.10.1: agent conversations that do not trip the brake
Found live on 0.10.0, when two agents handed a machine its token between themselves: the conversation (task, claim, "ready", link, result) hit the fast-reply brake at 8 messages, and the brake then refused the [end] that would have closed it.
- The pair brake allows 24 replies in 2 minutes between the same two sessions (it was 8). A real loop answers in seconds, so it is still stopped within 2 minutes; a handoff takes about 10 messages. (#36)
- An
[end]always goes through the pair brake: ending is what stops a loop. (#36) meshanddoctorshow every feature a node advertises; they cut at 8 without a word, so 0.10.0 nodes looked as if they lackedtasksandturns. (#35)- A data race in the hook tests, found by the race detector in the gate. (#34)
Upgrade the nodes (the brake runs there); clients need nothing new.
Checks: scripts/check.sh (race tests, smoke transcript, mesh lab 342/342); two builds byte-identical; mixed-version gate 770/0 against every release since 0.1.0 (the gate's own lookup was fixed first: it matched node o010 inside o0100); the signed-update rehearsal from 0.10.0 with all seven attacks refused.