Transports, workers, and capability
Backends declare capability truthfully and Most routes only to what is executable. Each chat is pinned to one physical worker; an unavailable pinned worker fails explicitly with 503 rather than silently moving the conversation to a different identity.
Current capability#
The README's capability table is authoritative — planned and unavailable transports must not advertise executable send capability:
- HTTP control plane, auth, storage, webhooks — Linux container or native host — Implemented.
- mac-relay text and attachment send — native macOS with Messages.app — Implemented.
- mac-relay receive, reactions, edits, receipts, attachments — native macOS via `chat.db` — Implemented.
- Twilio SMS — Linux or macOS — Implemented when configured.
- Remote-worker control plane — Linux or macOS — Implemented.
- Private-API dylib operations — dedicated SIP-disabled Mac — code present; operator injection prerequisite.
- Direct-to-Apple outbound send — Linux after Apple-ID bootstrap — unavailable; outbound backend methods return `NotImplemented`.
- Twilio RCS — planned, not implemented.
- Jailbroken-iPhone worker — device code present; operated rollout not established.
mac-relay#
mac-relay runs only on a real Mac: it sends through Messages.app via AppleScript and receives through `~/Library/Messages/chat.db`. It is not a container feature.
- Messages.app signed in with an operator-owned Apple ID and functioning manually.
- Full Disk Access to `~/Library/Messages/chat.db` and Automation permission for Messages.app.
- Deliberate worker identity and capacity, plus a rollback and provider-account recovery owner.
- Start with `MOST_COMPOSITION=dev-mac` only in an operator-controlled environment; a live send is not an onboarding health check.
Remote workers#
Remote transport workers connect over an mTLS WebSocket with a dedicated bearer capability. A worker needs a stable `worker_id` and backend kind, an internal CA-issued client certificate matching that identity, a supported protocol version, a capacity declaration, heartbeat and reconnect behavior, and an explicit removal and certificate-revocation procedure.
Worker affinity#
A new chat is assigned to one physical worker and that assignment is persisted; every subsequent operation resolves the same worker. When that worker is unavailable, the request fails with an explicit 503 — Most never silently fails an existing chat over to a different Apple identity.