F4 — Orchestrator chat connector abstraction + Matrix (local homeserver) #616

Closed
opened 2026-06-22 08:08:24 +00:00 by jason.woltje · 0 comments
Owner

F4 — Orchestrator chat connector abstraction + Matrix (local homeserver)

From the north-star (#613) orchestrator-chat-connector decision: the orchestrator is reachable over a user-chosen connector (tmux now; Discord live; Matrix/Telegram/Slack configurable). Add Matrix as a peer connector targeting a local homeserver (Conduit default, Synapse alt), behind a small uniform connector interface so connectors are pluggable without touching fleet core.

Phase 1 (this PR) — design + scaffold

  • Design doc docs/fleet/f4-matrix-connector.md: interface, config model, Matrix client-server API mapping, local-homeserver infra note, secrets, phasing, back-compat.
  • src/fleet/connectors/types.ts: OrchestratorConnector interface (send, subscribe, health) + message types (thread-aware).
  • src/fleet/connectors/registry.ts: resolveConnector(kind) — tmux passthrough; discord/matrix stubs (not yet implemented).
  • Tests; roster connector schema block (optional, defaults tmux — back-compat).

Phase 2+ (follow-up, in the doc)

Matrix CS-API client (fetch-based send/sync/health); init/configure connector-selection UX; systemd launch wiring; Conduit deploy guide.

Constraints (Lead-confirmed)

Connectors are peers (tmux | discord | matrix | future first-party Mosaic Discord w/ threads); interface stays small + uniform (send / receive-subscribe / ack-health); secrets via env (gateway pattern), never in roster. Control plane = federation (W1).

## F4 — Orchestrator chat connector abstraction + Matrix (local homeserver) From the north-star (#613) orchestrator-chat-connector decision: the orchestrator is reachable over a **user-chosen connector** (tmux now; Discord live; Matrix/Telegram/Slack configurable). Add **Matrix** as a peer connector targeting a **local homeserver** (Conduit default, Synapse alt), behind a small uniform connector interface so connectors are pluggable without touching fleet core. ### Phase 1 (this PR) — design + scaffold - [ ] Design doc `docs/fleet/f4-matrix-connector.md`: interface, config model, Matrix client-server API mapping, local-homeserver infra note, secrets, phasing, back-compat. - [ ] `src/fleet/connectors/types.ts`: `OrchestratorConnector` interface (`send`, `subscribe`, `health`) + message types (thread-aware). - [ ] `src/fleet/connectors/registry.ts`: `resolveConnector(kind)` — tmux passthrough; discord/matrix stubs (`not yet implemented`). - [ ] Tests; roster `connector` schema block (optional, defaults tmux — back-compat). ### Phase 2+ (follow-up, in the doc) Matrix CS-API client (fetch-based send/sync/health); init/configure connector-selection UX; systemd launch wiring; Conduit deploy guide. ### Constraints (Lead-confirmed) Connectors are peers (tmux | discord | matrix | future first-party Mosaic Discord w/ threads); interface stays small + uniform (send / receive-subscribe / ack-health); secrets via env (gateway pattern), never in roster. Control plane = federation (W1).
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#616