Connector and hosting roadmap

This is the implementation contract behind the public connection catalog. The canonical machine-readable definitions live in packages/platform-catalog.

The catalog today#

WhatsAppAvailable
Scan a QR code or enter a pairing code from WhatsApp Linked Devices.
TelegramAvailable
Approve a QR login or enter the code sent to an existing Telegram client.
InstagramAvailable
Authorize Instagram in Claire Desktop so session material can pass directly to the bridge.
MessengerPlanned
Authorize Messenger in a contained Claire Desktop sign-in window.
SignalPlanned
Scan a linked-device QR code from the Signal mobile app.
DiscordPlanned
Use Discord mobile to scan and approve the bridge login.
iMessageBeta
Grant Claire Desktop access to Messages, Contacts, and the required macOS automation permissions.
Google MessagesPlanned
Sign in on Claire Desktop, then approve the connection from Google Messages on Android.
Google ChatPlanned
Authorize Google Chat through a contained desktop session.
Google VoicePlanned
Authorize Google Voice with a desktop browser session managed by Claire.
SlackPlanned
Choose a workspace and complete the secure desktop authorization flow.
LinkedInPlanned
Sign in through Claire Desktop using the browser identity expected by the bridge.
XPlanned
Authorize X in a contained desktop session and hand the resulting session directly to the bridge.
BlueskyPlanned
Enter your handle, PDS, and an app-specific password.
ZulipPlanned
Enter the workspace URL, account email, and a revocable Zulip API key.
IRCPlanned
Choose a configured IRC network and optionally provide SASL credentials.

Support classes#

Class	Meaning	Examples
Phone pairing	Setup is approved from the network’s mobile app; Claire Desktop is not required.	WhatsApp, Telegram, Signal, Discord
Desktop setup	Claire Desktop acquires a browser session and hands it to the bridge host; the desktop may close afterwards.	Instagram, Messenger, Google Chat, Google Voice, Slack, LinkedIn, X
Paired device	A user-owned device stays part of delivery after setup.	iMessage on a Mac, Google Messages on Android
Direct credential	A revocable password, app password, API token, or network credential — no browser session.	Bluesky, Zulip, IRC

Google Messages belongs to two classes at once: the desktop performs the Google sign-in, while the Android phone remains part of message delivery.

Delivery waves#

Current. Keep WhatsApp, Telegram, and Instagram reliable, and expose their real connection health through the shared registry.
Wave 1. Messenger, Signal, and Discord, once the generic BridgeV2 provisioning flow is stable.
Parallel Mac track. iMessage, only after signed helper distribution, permissions, sleep and restart recovery, and bridge-health diagnostics all pass.
Wave 2. Google Messages, Google Chat, Google Voice, Slack, LinkedIn, and X, using the desktop authentication broker.
Wave 3. Bluesky, Zulip, and IRC, using direct credential flows.

Each connector stays feature-flagged until authentication, initial sync, send and receive, supported media, reauthentication, disconnect, and outage recovery all pass in its production deployment.

Connection contract#

GET /platforms/definitions is public and returns the product catalog. Runtime connection records reference the catalog by platformId and add:

bridge instance and version;
workspace deployment mode;
execution location and host device, where applicable;
status, last successful sync, and last error category;
a secret-store reference — never raw credentials;
the capability snapshot used to gate UI actions.

BridgeV2 networks should use the common provisioning API. Network-specific drivers may translate authentication steps, ghost-user templates, bridge bot identities, and capability reports, but must return the same Claire connection state model. Instagram and Messenger run as separate mautrix-meta instances and must remain independently revocable.

Desktop authentication boundary#

The desktop authentication broker owns contained browser sessions and native secure storage. Browser-session material moves directly from native code to the selected bridge provisioning service.

Disconnecting a network revokes the credential where possible, removes the bridge login, and clears local secret material. Deleting message history stays a separate, explicit choice.

Hosting and privacy#

Deployment mode is account-wide for the first release.

Mode	What it means
Claire Cloud	Claire hosts the server, homeserver, bridges, database, search index, and configured AI. A desktop used only for authentication may close afterwards; device-dependent networks are the exception.
Self-hosted	The Docker stack runs on user-controlled infrastructure. Availability follows that host, and external AI providers still receive selected content when configured.
Private desktop-only	Unreleased until local storage, search, embeddings, media, export, deletion, and recovery all work without Claire cloud services.

A hosted connector is a trusted processing boundary. The separate end-to-end encryption research document explains why a local connector is required before Claire can make a zero-knowledge claim.

Verification matrix#

Catalog contract. Unique IDs, accurate availability, correct desktop and device classification, and an exact generated snapshot.
Connection experience. Keyboard-operable filters and details, visible focus, reduced motion, screen-reader labels, and responsive layouts.
Connector certification. Authentication, backfill, send and receive, media and interactions where supported, reauthentication, disconnect, and recovery.
Desktop security. Secret redaction, secure-store persistence, revocation, process supervision, and actionable offline states.
Hosting behaviour. Cloud operation with the desktop closed, iMessage with its Mac offline, Google Messages with its phone offline, and local-mode egress enforcement before any privacy guarantee.

Search the project, not the web.