ZeroClaw proposes a polling-first iMessage route for non-Apple hosts

ZeroClaw's new Sendblue proposal would give non-Apple hosts an iMessage and SMS route through a hosted relay. It is not a replacement for the existing macOS AppleScript channel. The feature is separately compiled and configured, and defaults to polling rather than requiring an internet-facing webhook endpoint. The contributor reports using a real Sendblue account on Linux to verify authenticated health checks and an outbound iMessage to a handset. The proposal remained open at capture.

The branch documentation makes the hosting trade-off visible: this route removes the need for a local Apple bridge but introduces a third-party message service, credentials and a provisioned number. The contributor's account also separates the live polling checks from untested paths. Real webhook delivery, group messaging and outbound media were not verified, and the upload-file API is not wired for outgoing attachments.

The facts

- PR #10768 adds an opt-in channel-sendblue feature and an additive channels.sendblue configuration table. - Polling defaults to 15 seconds with a five-second floor, avoiding a required public webhook endpoint. - Polling and webhook records share a parser and the existing peer-group allowlist decision. - Records marked is_outbound are dropped before dispatch so the agent does not answer its own sends. - Listener health describes polling freshness and returns no such claim in webhook mode. - The contributor reports Linux outbound handset delivery and a fresh listener starting from now rather than replaying the account backlog.

Why it matters

Channel portability is an operating-model decision, not just another protocol checkbox. A hosted bridge may be attractive for a Linux deployment, but it moves message handling into a provider relationship and changes the failure modes that need monitoring. Choosing polling by default is also a conscious exposure trade-off. The proposal says the vendor's webhook secret is not bound to the request body; this brief reports that design rationale without claiming an independently audited vulnerability.

Current

Inspected on 2026-09-11. The ZeroClaw release baseline is v0.8.5 published 2026-09-05T07:31:19Z. The main source was open (not merged) when captured. Release metadata bounds availability; proposals, merged mainline changes and packaged releases are not interchangeable.

Evidence

Primary evidence: zeroclaw-labs/zeroclaw PR #10768 (https://github.com/zeroclaw-labs/zeroclaw/pull/10768). Supporting context: ZeroClaw proposal branch — Sendblue channel contract (https://raw.githubusercontent.com/zeroclaw-labs/zeroclaw/5eed0ad377ed54ec45f17f87a791dfaaa6f68cf4/docs/book/src/channels/chat-others.md); ZeroClaw — current official README (https://raw.githubusercontent.com/zeroclaw-labs/zeroclaw/master/README.md). These pages were inspected directly. Linked documentation establishes the product contract; it does not independently reproduce contributor or author experiments.

Operator take

Keep the first evaluation on an approved test number and verify inbound and outbound behavior separately. Check allowlist rejection, self-message suppression, restart behavior and freshness reporting before treating the channel as unattended infrastructure. Do not infer group or media support from a successful text send. The feature should remain a watch-for-merge capability until its code and dependencies are available in the operator's actual build.

Caveat

This is an open contributor proposal, not a released ZeroClaw capability. Live test claims were not independently repeated. The vendor documentation URL tried during research returned 404, so webhook-security characterization remains attributed to the proposal and its inspected branch documentation.