Two-machine x0x propagation fails for direct, pubsub, groups, stores, and tasks

[dirvine]

Summary

During local/studio stress testing with the released x0x 0.21.2 daemon, the core read-only surfaces passed, but stateful cross-node delivery did not propagate reliably between the MacBook Swift instance and the studio Dioxus instance.

Targets:

• MacBook/local: b3ce9af3bbed63cabfb0d36ac2436dae3a1a4fcce45f82119db0b31b76d1d69e, x0x 0.21.2, connected, ~4 peers
• Studio: 1675f91fd4c59095646db9c7603cc68811f7bbe898afe5f746653875973cea4c, x0x 0.21.2, connected, ~10 peers

What passed

cargo test -p communitas-x0x-client --test live_matrix_contract -- --ignored --nocapture with a two-target matrix passed:

• health/status/agent
• identity cards
• discovery/presence/find/reachability
• network status and bootstrap cache
• websocket connect/ping
• SSE connect
• constitution and GUI HTML surfaces

Contacts/trust also passed in the mutation harness:

• mutual agent-card import
• block/unblock/trust
• machine add/pin/unpin
• remove/re-add
• synthetic revocation lifecycle

Failures observed

Direct messaging and file transfer

POST /direct/send local -> studio failed:

HTTP 504 {"detail":"timed out after 1 retries over 12.004431084s","error":"timeout","ok":false}

File transfer then failed with the same underlying condition:

HTTP 500 {"error":"send offer failed: peer disconnected: agent not connected: [22, 117, 249, ...]","ok":false}

Pubsub / events

Studio subscribed to a unique topic via POST /subscribe, local published via POST /publish, and studio /events did not receive the message within 120 seconds.

FAIL gossip pubsub local->studio: timeout waiting for SSE studio/events

Public group messages

A public_open group could be created locally and joined by studio, but public group messages did not converge both ways via GET /groups/:id/messages.

Request-access groups

After importing the group card on studio, POST /groups/:id/requests returned ok: true on studio. The owner/local daemon still reported zero pending requests and approving the returned request id failed with 404.

studio request: {"ok":true,"group_id":"...","request_id":"eb8edad904b646a59895a764a534fe65"}
local GET /groups/:id/requests -> []
local approve -> HTTP 404

Stores and tasks

A store created locally and joined by studio allowed local CRUD, but cross-node replication/update/delete did not appear:

store create/join/put/update/delete: replicated=False updated=False deleted=False

A task list created with the same topic on both nodes returned the same id, but tasks did not cross-appear:

task/kanban create/add/claim/complete: done=False cross_visible=False local_id=codex.ta studio_id=codex.ta

The done=False portion is partly a GUI/client interpretation bug because the daemon returns states such as done:<agent_id>; that is being patched separately. The cross visibility remained false.

Mutation timeout after applying state

One PATCH /groups/:id request timed out in the client, but the local group description later showed the mutation had applied. That suggests at least one mutation route can apply state but fail to return in time under load.

Expected

For two connected healthy daemons with mutual trusted contacts:

• direct messages should deliver to /direct/events or fail with actionable connection diagnostics before app-level send
• pubsub messages should reach subscribed peers
• group messages, join requests, stores, and task CRDT state should converge across joined members
• mutation endpoints should not leave clients in an ambiguous timed-out-but-applied state

Notes

This likely overlaps with #11 but is broader than the initial-message-drop case: the two-machine run showed no cross-node delivery for several stateful surfaces despite read-only discovery and WebSocket/SSE connection tests passing.

[dirvine]

Additional live UI evidence from the Swift + Dioxus two-machine stress test:

• Both daemons were healthy at test time:
  • local http://127.0.0.1:12700/health -> ok=true, x0x 0.21.2, peers 5
  • studio forwarded http://127.0.0.1:12799/health -> ok=true, x0x 0.21.2, peers 8
• Swift local app was moved to the main display and successfully sent a private-space channel message via normal mouse click:
  • space: codex-private-space-1780701227-37
  • channel: #general
  • message: codex-ui-swift-private-keysend-20260606-0117
  • Swift displayed it locally as b3ce9af3 AI (you) at 01:18.
• Patched Dioxus on studio was visible, connected, and selected the matching private space/channel:
  • left space: codex-private-space-1780701227-37
  • middle channel: #general
• The Swift-origin message was not visible in the Dioxus private #general view after switching to the matching space/channel.

This confirms the earlier API-level propagation failure from a user-visible app flow as well: local Swift can create/display a channel message, but studio Dioxus does not receive/render it on the same group/channel.

Related UI/desktop issues found while reproducing:

• Swift AX send crash: Swift Send button crashes when invoked through accessibility action #24
• Dioxus desktop window/AX automation issue: Dioxus macOS desktop launch can run headless or without AX windows outside GUI launch path #25

[dirvine]

Additional two-machine x0x smoke evidence from 2026-06-06 using the running Swift MacBook daemon (127.0.0.1:12700) and studio daemon through the existing tunnel (127.0.0.1:12799). Test suffix: codex-smoke-20260606-042428.

Passed locally / per-daemon:

• Live matrix core contract passed on both daemons: health, status, agent/card, discovery surfaces, presence surfaces, WebSocket/SSE connect, constitution.
• Multi-target discovery contract passed with X0X_TEST_ENABLE_MULTI_TARGET=1: local discovered studio, presence/find/reachability decoded, WebSocket ping/pong worked.
• Contacts/trust on local passed: add contact, update trusted, set blocked, set known again, add machine, pin machine, unpin machine, evaluate trust, remove machine, remove contact.
• Studio contact add/remove for local also passed.
• Local task list lifecycle passed: create list, add task, claim task, complete task. Final task state was done:b3ce9af3....
• Local store key lifecycle passed: create store, put key, get key, delete key.

Failed or inconsistent cross-node behavior:

• Local direct send to studio failed after /agents/connect: /direct/send returned peer_disconnected with detail agent not connected for the studio agent. Studio /direct/events did not receive the payload.
• Local created group and invite; studio /groups/join returned ok, but local /groups/:id/members still showed only the local owner (member_count: 1). Local DELETE /groups/:id/members/:studio_agent then failed with member not found.
• Group ban before join failed with member is missing TreeKEM KeyPackage; unban then failed with member is not banned. This may be a separate API semantics issue, but the add/remove/block/unblock group path is not usable in the current two-node flow.
• Local created store and wrote codex-key; studio /stores/:id/join returned ok, but studio /stores/:id/keys returned an empty keys: [] list.

This reinforces the existing blocker: per-node APIs are mostly healthy, but direct messaging plus group/store cross-node materialization are not propagating sufficiently for the apps to show send/receive behavior across machines.