Protocols and backends – open and connectable
Sparks connects open standards with your existing systems. Between client and backends, Sparks middleware (server components) always runs. Here you can see the role of middleware, which backends exist, and what we host or you can connect.
How the Sparks architecture works
The Sparks client (web and desktop) talks to Sparks middleware, which connects Matrix, video, calendar, files, identity and AI to the right backends. Middleware is an essential part of running Sparks and must be operated – the client does not talk to every backend directly. Depending on the offering, we run backends and middleware for you, or you run your own backends and middleware in your environment.
Matrix (chat & channels)
Synapse or tuwunel. E2EE, federation, same base as BwMessenger, Tchap, gematik TI-Messenger.
Video conferencing
WebRTC-based, e.g. LiveKit. For meetings, breakout rooms, lobby.
Calendar & contacts
Exchange, Nextcloud, Open-Xchange – multi-backend calendar in one interface.
File storage
WebDAV (e.g. Nextcloud, Opencloud, Owncloud) or Microsoft SharePoint – files in one interface.
Identity / SSO
SAML/OIDC, e.g. Keycloak. For enterprise: tenant isolation, central login.
AI assistant
Your own API key or self-hosting. Context from calendar, contacts, chats.
Sparks middleware
Sparks server-side components: orchestration, connectivity and security between the client and your backends. Without this middleware, backends are not usable from the Sparks client.
Sparks client
Web & desktop – one interface for chat, video, calendar and AI. Communicates with Sparks middleware, not with each backend individually.
Backends at a glance
Which stacks we offer and which existing backends you can connect.
Sparks provides all backend components. The other product models (e.g. Sparks M365, Sparks Pure) are variations of that – same building blocks, adapted to your infrastructure.
All components from Matrix through video, calendar and files to identity management are optional: they can be operated by Sparks or by you elsewhere – depending on your stack. Connectivity always goes through Sparks middleware; which backends sit behind it is flexible.
| Backend | Protocol / technology | Operated by Sparks? (optional) | Can connect your own / existing? |
|---|---|---|---|
| Matrix (chat & channels) | Matrix (Synapse, tuwunel) | Optional | Yes |
| Video conferencing | WebRTC (e.g. LiveKit) | Optional | Yes |
| Calendar & contacts | CalDAV, Exchange, OX | Optional | Yes |
| File storage | WebDAV, Microsoft SharePoint | Optional | Yes |
| Identity / SSO | SAML, OIDC (e.g. Keycloak) | Optional | Yes |
| AI assistant | LLM API (OpenAI-compatible) | Optional | Yes |
Small hosting variant
Minimal effort: Run only the Matrix server (Synapse/tuwunel) yourself – connect all other services (video, calendar, files, identity) via Microsoft 365 including IAM.
Use existing infrastructure
Already running Matrix, LiveKit, and Keycloak? The Sparks client alone is not enough: Sparks middleware (server components) must run with you or with Sparks – it connects your backends and exposes them to the client.
Want to self-host Sparks or connect your own backends?
Request self-hosting or hosting→ Self-hosting & components in detail → Matrix protocol explained simply