SLM Mesh v1.3.0 + SuperLocalMemory v3.4.48

When I built the first version of SLM Mesh, I made a deliberate choice: single-machine only. Every peer lived on the same host. Every message traveled over a Unix Domain Socket. That worked perfectly for coordinating Claude, Cursor, and Aider on the same Mac.

But the moment you open a second laptop, the coordination breaks. M4's Claude can't see M5's Claude. You're back to manual context copying, status Slacks, and hoping both agents don't touch the same file.

That ends today.

What Ships

SLM Mesh v1.3.0 (TypeScript, npm):

• WebSocket push server on the broker — remote peers get real-time notifications, same sub-100ms delivery as local UDS
• Peer-to-peer routing via hello registration — the broker tracks each remote peer's WebSocket connection and delivers messages directly
• mDNS auto-discovery via Bonjour — brokers find each other on the LAN without IP config
• Shared secret authentication — required when binding to non-localhost
• Environment variables: SLM_MESH_HOST, SLM_MESH_SHARED_SECRET, SLM_MESH_WS_PORT, SLM_MESH_DISCOVERY
• 490 tests, 100% line coverage

SuperLocalMemory v3.4.48 (Python, pip):

• RemoteSyncClient — background HTTP sync with remote SLM instances every 30 seconds
• mesh_peers returns local + remote peers merged
• mesh_send auto-proxies to remote SLM when the target peer lives on the other machine
• Optional mDNS discovery via zeroconf
• Shared secret auth guard on /mesh/peers
• Zero breaking changes — all 8 MCP tools unchanged

The Architecture in One Diagram

Mac M4 (hub)                          Mac M5 (client)
────────────────────────────────      ────────────────────────────────
SLM Mesh broker                       SLM Mesh MCP server
  HTTP :7899 (0.0.0.0)  ◄──────────    connects to M4:7899
  WS   :7900 (0.0.0.0)  ◄──────────    WsPushClient → hello(peerId)
  mDNS _slm-mesh._tcp   ◄─ discovers ─ mDNS browser
SuperLocalMemory :8765               SuperLocalMemory :8765
  /mesh/peers (auth'd)  ◄──30s poll─   RemoteSyncClient
  /mesh/send            ◄── proxy ──   broker.send_message(remote peer)

How Real-Time Push Works

This was the missing piece in the v1.3.0 commit. The WebSocket server existed. The client connected. But the broker never called wsServer.sendToPeer(). Messages were stored in SQLite and waited for polling.

The fix required three changes working together:

1. WS server tracks peer identity. When a remote MCP client connects and sends {"type":"hello","peerId":""}, the server maps that peerId to the WebSocket connection.

2. peer-listener sends hello on connect. The WsPushClient now sends the hello message immediately after establishing the WebSocket connection, using the actual peer UUID it registered with.

3. handleSend routes via WS as fallback. When push.send(toPeer, notification) returns false (no local UDS for remote peers), it tries wsServer.sendToPeer(toPeer, notification) as the fallback. If WS delivers, the message is marked delivered immediately.

const delivered = push.send(toPeer, notification)
  || (wsServer?.sendToPeer(toPeer, notification) ?? false);
if (delivered) {
  stmtMarkDelivered.run(messageId);
}

No polling needed for remote peers. The latency is the same as local.

Zero Regression

Both products maintain full backward compatibility:

• SLM_MESH_HOST defaults to 127.0.0.1 — single-machine mode unchanged
• All 8 MCP tools have identical signatures
• All 12 broker HTTP endpoints unchanged
• 490 TypeScript tests pass, 691 Python tests pass

If you don't set SLM_MESH_HOST, nothing changes.

Getting Started

Two commands. Two machines. One mesh.

M4:

SLM_MESH_HOST=0.0.0.0 SLM_MESH_SHARED_SECRET=your-secret npx slm-mesh

M5 (in your MCP config):

{
  "env": {
    "SLM_MESH_HOST": "192.168.1.100",
    "SLM_MESH_SHARED_SECRET": "your-secret",
    "SLM_MESH_PEER_URL": "http://192.168.1.100:8765"
  }
}

For the full setup guide including firewall ports, mDNS configuration, and troubleshooting: Multi-Machine Setup Guide.

---

Varun Pratap Bhardwaj — Solution Architect, Qualixar. Building AI Reliability Engineering tools.

Part of the Qualixar AI Reliability Engineering platform.