CHAT

CHAT is the most strategically loaded P0 module because it carries three obligations that no other module shares simultaneously. Reading it under any single lens misses two-thirds of the design. The three roles below MUST all be true at P0 exit (P0 · exit); otherwise the platform fails its dogfooding bet.

P0-exit gate dependency map

What this means in practice: CHAT is the LAST P0 module to ship (P0 · exit), but it is the GATE for P0 exit. If AI Gateway slips, CHAT slips, Slack survives, dogfooding fails. The 28-day window between AUTH stub (P0 · slice 2) and CHAT (P0 · exit) is the single most-watched milestone in the platform.

Building a chat server from scratch is months of work whose differentiator (CyberOS auth, AI features, Vietnamese search, BRAIN bridge) is at the edges, not the middle. Mattermost has solved channels, threads, attachments, presence, mobile push, federation, and admin tooling at production quality. Forking it lets the CyberOS team focus on the differentiators while keeping a vendor-independent path (no Mattermost SaaS dependency, no per-seat fee).

The bet: take the part Mattermost did well (the messaging substrate), wrap it in the parts CyberOS does well (auth, audit, AI, Vietnamese), and ship a chat product that feels like Slack-quality and is end-to-end ours.

Four real-time architectures were evaluated for CHAT. The decision (locked 2026-05-14) is fork Mattermost + layer CyberOS auth/UI/search/AI on top. The decision-record table below is the formal rationale.

What we own vs what Mattermost owns

Fork governance: Mattermost upstream tracking via quarterly rebase + security-patch cherry-pick (handled by CSEC). Fork pinned at cyberos/chat-server with explicit upstream commit hash in VERSION file. Per R-CHAT-013, license drift is monitored quarterly; if upstream re-licenses (e.g. to SSPL or AGPL), we have a documented downstream-only path.

Per BRAIN_AUTOSYNC_DESIGN.md §5, CHAT is one of three first-class capture surfaces (Cowork · Claude Code · CHAT). The capture rule is conservative-by-default: only @lumi-tagged messages auto-capture. Passive messages are NOT captured (privacy floor) unless the channel has explicit opt-in sampling for high-signal flows.

Capture rules

@lumi handling flow (message → CUO route → BRAIN memory row)

What the audit row captures: the original message body, the user_id, the channel id (subject to ACL), the thread id, the timestamp, the @lumi trigger flag, the resolved CUO skill, the persona-version stamp, the AI Gateway latency + token cost, the BRAIN chain hash, and the channel's sync_class default. Every @lumi response is fully replayable from BRAIN — "what did the CFO skill tell us about runway last Tuesday?" → grep audit chain.

CHAT does NOT use end-to-end encryption. Messages are server-visible to the tenant's CHAT service. Encryption-at-rest is provided at the Postgres column level (KMS-wrapped keys per tenant). This is a deliberate trade — not an accident — and documenting it here heads off the recurring debate.

The decision-record

Why per-tenant Postgres encryption wins

1. The platform's value proposition requires server-side message access — @lumi, search, BRAIN capture, daily digest. E2EE would break all four.
2. The rogue-server-admin threat is real but manageable: SOC 2 access controls + audit-chain on every admin operation + four-eyes principle for production database access. Risk is procedural, not cryptographic.
3. The other four common threat models (external attacker with DB dump, physical disk loss, backup compromise, snapshot theft) ARE mitigated by per-tenant Postgres encryption-at-rest — same security posture as E2EE for these.
4. Slack, Notion, Linear, Carta, every B2B platform with AI features makes the same call. The market expectation is "encrypted-at-rest, not E2EE."
5. Re-evaluating this decision is a P3+ exercise — only if a specific high-security tenant requests E2EE as a contract requirement. At which point a separate "E2EE-only channel" mode could be offered with explicit @lumi-disabled limitation.

What encryption-at-rest looks like concretely

Per-tenant KMS-wrapped column encryption on messages.body, messages.attachments_meta, direct_messages.body. Each tenant has a dedicated AWS KMS Customer Managed Key. CHAT service holds the data key in memory only (re-fetched on rotation). DB dump alone yields ciphertext. Backups use a separate KMS key with separate rotation cadence. Per-tenant KMS revocation is supported (within 15 minutes a tenant's data becomes unreadable system-wide).

Slack and Zalo migration is non-negotiable for the P0 · exit dogfood gate. If the team can't bring their 3-year Slack history with them, they won't move. The tooling spec below targets a one-day cutover for the 10-Member CyberSkill team and a one-week cutover for an external 100-Member tenant.

Slack import tool — cyberos-chat import slack

Zalo import — the harder problem

Zalo has NO official enterprise export API. Two pragmatic paths:

1. Manual per-conversation export via Zalo's "Save chat" feature. Each user runs the export against their conversations and uploads to a CHAT staging bucket. CHAT then imports via cyberos-chat import zalo --personal ./exports/. Awkward but works. ~1 hr per user.
2. Read-from-Zalo desktop client via OS-level integration (macOS Accessibility API) — captures the on-screen chat list in batches. Higher infrastructure cost; lower per-user time. Requires cyberos-zalo-bridge companion (~Q3 2026 if priority).

The 10-Member CyberSkill team can do Zalo migration manually in one afternoon. For external tenants at 50+ members, path 2 is required — adds 4 weeks to TEN module's onboarding spec.

P0 exit (P0 · exit) is gated on Slack + Zalo decommissioned. That is not a vibes assertion; it is a measurable KPI. The definition below is what gets evaluated at the P0 exit gate review.

Definition

decommission_signal := (
  messages_per_day_in_cyberos_chat
  /
  (messages_per_day_in_cyberos_chat + messages_per_day_in_slack + messages_per_day_in_zalo)
) ≥ 0.95

over a rolling 14-day window, sampled daily.

Plus:
- Slack workspace set to read-only (admin signoff)
- Zalo company group: announced sunset (manual confirmation)
- No team member has logged into Slack in the prior 7 days

Why 95%, not 100%

100% is unrealistic — the team will receive Slack DMs from external partners using old habits for months. The decommission gate is about where new conversation lands by default, not about achieving zero Slack presence ever again. The "no team member has logged into Slack in the prior 7 days" qualifier handles the case where the messages-per-day ratio passes but a few stragglers are still using Slack as their primary surface.

Tracking instrumentation

What happens if P0 · exit misses the gate

Per archive/2026-05-14/AUDIT_AND_PLAN.md (archived; see cyberos/CHANGELOG.md), if the P0 · exit dogfood gate misses, the P1 · start P1-scope-collapse fail-mode immediately activates: HR-full split + LEARN deferred. The platform doesn't fail; the timeline slips by 1 quarter while CHAT's missing features get prioritised. Concrete remediation triggers: if decommission_signal < 0.50 at P0 · exit → 90-day CHAT-only sprint, no P1 modules start. If 0.50 ≤ signal < 0.95 at P0 · exit → 30-day catch-up, P1 modules start at P1 · start with reduced scope.

Three layers stacked. Substrate: Mattermost-derived Go service (channels, threads, attachments, presence, push). Native CyberOS layer: auth bridge, UI shell (Tauri), PGroonga search adapter, BRAIN bridge, voice ASR. AI layer: Genie agent, summarisation, smart-reply, daily digest — all calling AI Gateway.

Internal components

Postgres-backed. Schema follows the Mattermost shape with CyberOS-specific extensions for audit linkage and BRAIN ingest watermarks. All tables RLS-scoped by tenant_id.

Channel kinds + ACL rules

GraphQL subgraph (federated)

extend schema
 @link(url: "https://specs.apollo.dev/federation/v2.5", import: ["@key", "@requiresScopes"])

type Channel @key(fields: "id") {
 id: ID!
 slug: String!
 kind: ChannelKind!
 displayName: String!
 purpose: String
 members: [Membership!]! @requiresScopes(scopes: [["chat.read"]])
 recentMessages(limit: Int = 50): [Message!]! @requiresScopes(scopes: [["chat.read"]])
}

type Message @key(fields: "id") {
 id: ID!
 channelId: ID!
 authorId: ID!
 body: String!
 blocks: JSON
 parentId: ID
 createdAt: DateTime!
 editedAt: DateTime
 reactions: [Reaction!]!
 attachments: [Attachment!]!
 brainChain: String # links to BRAIN audit row
}

type Reaction { emoji: String! userId: ID! ts: DateTime! }

type Attachment {
 id: ID!
 filename: String!
 contentType: String!
 sizeBytes: Int!
 url: String!
 transcript: String # voice notes only
}

type Membership {
 user: User!
 role: MembershipRole!
 notifyMode: NotifyMode!
 lastReadAt: DateTime
}

enum ChannelKind { PUBLIC PRIVATE DIRECT GROUP_DIRECT }
enum MembershipRole { OWNER ADMIN MEMBER GUEST }
enum NotifyMode { ALL MENTION QUIET DIGEST }

type Query {
 channel(id: ID!): Channel
 channels(kind: ChannelKind): [Channel!]!
 searchMessages(q: String!, channelId: ID, limit: Int = 50): [Message!]!
}

type Mutation {
 sendMessage(channelId: ID!, body: String!, blocks: JSON, parentId: ID): Message!
 editMessage(id: ID!, body: String!): Message!
 deleteMessage(id: ID!): Boolean!
 addReaction(messageId: ID!, emoji: String!): Reaction!
 createChannel(slug: String!, kind: ChannelKind!, displayName: String!): Channel!
 @requiresScopes(scopes: [["chat.channel_create"]])
 inviteToChannel(channelId: ID!, userIds: [ID!]!): Boolean!
 @requiresScopes(scopes: [["chat.channel_invite"]])
 summariseThread(threadId: ID!): String! # calls AI Gateway
}

type Subscription {
 channelMessages(channelId: ID!): Message!
 presenceChanges(userIds: [ID!]!): Presence!
}

WebSocket events

MCP tool catalogue

Flow 1 — Send message (mention fanout + BRAIN ingest)

Flow 2 — Thread reply

Flow 3 — Vietnamese search (PGroonga)

Flow 4 — Thread summarisation (/summarise)

Flow 5 — Slack import

A single message traverses up to seven states from draft to BRAIN ingest. Edits + deletes are soft; the BRAIN audit row remains.

Notify-mode behaviour

Operator CLI cyberos-chat for admin tasks. Members interact via the GUI shell.

1. List channels

$ cyberos-chat channels list --tenant acme

SLUG KIND MEMBERS MESSAGES LAST_ACTIVITY
general public 42 18,420 2026-05-14T07:21Z
engineering public 18 9,420 2026-05-14T07:19Z
hanoi-office public 12 3,210 2026-05-14T06:45Z
ceo-stephen-vy direct 2 412 2026-05-14T05:33Z
project-alpha private 8 2,847 2026-05-14T07:02Z

2. Send a message via CLI (for automation)

$ cyberos-chat send --channel engineering --body "Deploy v0.9.2 starting at 14:00 VN. Watch #cyberos-alerts."

[sent] message_id=msg_01HZJ…XK · channel=engineering · ts=2026-05-14T07:22:08Z
[brain] ingest queued · expected p95 ≤ 5 s

3. Search Vietnamese content

$ cyberos-chat search "hợp đồng Singapore HoldCo"

[search] channel=engineering 3 hits recall_est=87%
msg_01HZG… 2026-05-12 stephen@: "đang draft hợp đồng Singapore HoldCo, deadline T5"
msg_01HZH… 2026-05-13 bao@: "đã review hợp đồng, comment đã gửi"
msg_01HZI… 2026-05-14 stephen@: "Singapore HoldCo flip nếu ARR ≥ $1.5M"

4. Import Slack workspace

$ cyberos-chat import slack --bundle slack-export.zip --tenant acme

[parse] 142 channels · 8,420 users · 1.4M messages · 32k attachments
[map] user mapping: 8,420 → 8,420 (zero unmapped)
[backfill] 142 channels created
[ingest] 142,000 messages / hour (throttled to BRAIN ingest budget)
[done] elapsed 9h 47m · all messages backfilled to BRAIN
[verify] random sample: 100/100 round-trip ok

5. DSAR export

$ cyberos-chat export-dsar --subject acme-contact@acme.com --output dsar-chat.zip

[export] subject: acme-contact@acme.com
[export] channels: 14 (12 public, 2 DM)
[export] messages: 4,217
[export] attachments: 142 (1.4 GB total)
[export] reactions: 1,032
[export] brain_anchor: included (audit chain hashes per message)
[written] dsar-chat.zip · 1.5 GB

6. Summarise a thread (operator-side)

$ cyberos-chat summarise-thread --id thr_01HZJ…XK

TL;DR: The team is debating whether to ship feature-X with the experimental
 summariser or hold for v2 of the prompt. Stephen leans ship-it; Bao
 wants one more A/B test.
Action items:
 • Bao: prepare A/B comparison by Wed 2026-05-15
 • Stephen: review prompt v2 draft
 • Both: align on go/no-go at the Friday standup

7. Health + SLO

$ cyberos-chat health

availability_28d: 99.96% ✓ (target ≥ 99.9%)
send_p95_ms: 142 ✓ (target ≤ 200)
brain_ingest_p95_s: 3.2 ✓ (target ≤ 5)
vn_search_recall: 0.87 ✓ (target ≥ 0.80)
ws_connections_now: 1,124
messages_today: 18,420