WisentMost
Most/Docs

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:

most-bootstrap and --dry-run inspect configuration only: they never contact Apple or the database, load anisette, or persist identity material. Exit 0 is not activation or credential verification. --i-understand-im-talking-to-apple refuses with exit 3 before login because FairPlay activation signing is unavailable; --dry-run takes precedence. --no-persist omits the plan's database-setting requirement. The obsolete --two-factor-code option and placeholder-persistence paths were removed.

  • 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 — unavailable; outbound methods return `NotImplemented`, and live bootstrap refuses before Apple login.
  • Twilio RCS — outbound text code is present, but provider delivery is not qualified. The explicit per-conversation choice uses an RCS Messaging Service sender and disables automatic SMS/MMS fallback.
  • Jailbroken-iPhone worker — device code present; operated rollout not established.

Twilio SMS#

Set STADO_INTEGRATION_API_URL to the deployed wisent-integrations HTTPS origin, without credentials or a path, and MOST_STADO_INTEGRATION_TOKEN to the product-specific bearer authorized for most/send-sms. STADO_API_URL is not this endpoint. Twilio account, auth and sender fields stay in the provider-side most-twilio item.

A 401 in an SMS receipt can mean an undeclared action, not just a wrong token. Matching local and host token fingerprints do not authorize most/send-sms. INTEGRATION_CLIENTS must allow that action for the intended token item, and the consumer named by INTEGRATION_SKARBIEC_CONSUMER must have read access to that item's token.

Use stado service env-show wisent-integrations --host HOST --env-file FILE --json to inspect the launcher's environment file; service env only reports the unit file. Inspect the named verifier with stado credentials grant show CONSUMER --host HOST --json. These reads show declarations, not proof that the running service uses that grant or can authorize Most.

An existing most-twilio item with empty account or sender fields is not a configured provider. Access and provider configuration belong to the deployment owner; do not borrow another product's token, expand grants or restart a service to hide an authorization refusal. After the approved configuration is available, qualification still requires an actual send to an approved test recipient, retained receive state and delivery receipts.

With that origin set, make test-messaging-refusal runs the actual server's SMS/RCS requests and the SMS shell example against real wisent-integrations using an intentionally invalid bearer. It checks both response formats, retained conversations, unknown-chat refusal, stored-channel continuation, channel-change refusals and nonzero SMS command failure. An RCS 404 not_found is a missing deployed action, not successful authorization or delivery. Commands, exit statuses, responses and server logs remain under .wisent-output/messaging-evidence (or WISENT_OUTPUT_DIR/messaging-evidence). These refusal tests do not qualify provider delivery.

For a new conversation, set message.preferred_service to SMS or RCS; omitting it selects iMessage. SMS and RCS each require one recipient. Most Desktop's Send screen offers the same channel choice and includes it in confirmation. Subsequent operations resolve the conversation's saved transport; a conflicting SMS/RCS preference returns HTTP 400. A missing or ambiguous registered owner returns HTTP 503 rather than selecting another channel.

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.