Skip to content
CCS Chat Docs

Architecture at a glance

Chat is a messaging service for products that need conversations between their users: direct messages, groups and channels, with live updates and push. This page shows the three parties in every setup, what each owns, and the two ways to use Chat.

The model

Section titled “The model”

Chat is business-agnostic. It knows tenants, applications, users, conversations and Chat permissions such as messages.send. It knows nothing about coaches, clients, patients or teams.

Three parties take part:

Party Owns
The Identity Server Users, tenants, memberships, roles, applications, clients, scopes and tokens. It also stores the Chat permission catalog and which roles hold which permissions.
Chat Conversations, members, messages, reactions, read state, presence, push devices and live updates. It also holds Chat Administration, per-tenant settings and the audit log.
Your app Your business rules (who may talk to whom, and when), your own users’ experience, and the route that hands your users a Chat token.

Chat trusts Identity Server tokens and checks every call against them. It never stores a password and never runs a sign-in for your users.

How a call reaches Chat

Section titled “How a call reaches Chat”

In an integrated setup, your backend decides and your app participates:

 Your web or mobile app                    Your backend
 (the signed-in user)                      (your rules, your database)
        |                                         |
        | user token (chat:access)                | machine token (chat:sync)
        | read, send, react, live updates         | create and archive conversations,
        |                                         | members, on-behalf-of, SYSTEM
        v                                         v
 +--------------------------------------------------------------+
 |                          Chat API                            |
 +--------------------------------------------------------------+
        ^                                         ^
        |   both tokens are issued by the Identity Server
        |   (the user token through token exchange in your backend)
  • Your backend is the only place conversations start. It checks its own rules, then calls Chat with a backend client bound to your tenant and application.
  • Your app acts as the signed-in user. Chat checks every call against the user’s Chat permissions and conversation membership.
  • A user does not need permission to create conversations to take part in one your backend created.

The two product modes

Section titled “The two product modes”
Standalone Integrated
Who uses Chat People of a tenant, at chat.centralcodestation.com The users of your application, inside your own UI
Sign-in Identity Server account, handled by Chat Your users sign in to your app once; your backend hands them a Chat token
Who may talk to whom Set by the Chat permissions the tenant gives to roles Decided by your backend, which creates the conversations
Integration work None. An administrator switches Chat on and maps permissions. Register a backend client, add one token route, call the SDKs

Both modes run on the same API and the same data. See Choose how to use Chat.

What Chat deliberately does not do

Section titled “What Chat deliberately does not do”
  • It does not decide who may talk to whom. A permission says which kind of operation a user may perform, never with whom. “Coach Ana may message John but not Sarah” is your rule, enforced where you create the conversation. See Chat permissions.
  • It does not know your domain. There are no coach, client or patient concepts in the API.
  • It does not sign users in for your application, and it does not own roles. Both stay in the Identity Server.
  • It does not store files. Messages carry a reference to a file kept elsewhere. See Messages.

For what is not built yet, see Roadmap and limitations.

Where to go next

Section titled “Where to go next”