Overview#
Tchap is the French government's secure messaging platform, built on the open Matrix protocol and operated by the Direction Interministerielle du Numerique (DINUM) for inter-agency communication across ministries, prefectures, and national services. This module connects Argus directly to any Tchap homeserver, ingesting room metadata and message events into a single operational picture so that analysts no longer copy and paste between a government chat client and their case files.
For security and intelligence teams that work alongside French counterparts such as the national police, ANSSI, and government ministries, Tchap conversations are a primary channel for coordination. Bringing that stream into Argus means inter-agency communications appear in the same investigations, timelines, and entity graphs as classified case material and alert data. The result is a unified workspace where a chat thread, a case file, and an alert can be correlated in seconds rather than reconciled by hand.
Every record stays inside its tenant boundary, and a clearance gate ensures that no message above a viewer's secrecy level is ever returned. The complete history of what was pulled in, by whom, and when is preserved to satisfy audit and disclosure obligations.
Key Features#
- Bi-Directional Matrix Connectivity: Connects to any Tchap homeserver over the Matrix Client-Server API version 3, reading room state and message history from the same standardised endpoints any compliant Matrix server exposes.
- Room and Message Ingestion: Pulls room names, member counts, and recent message events into durable storage, parsing the standard
m.room.message,m.room.member, andm.room.nameevent types into a normalised model. - Per-Tenant Data Isolation: Every room and message is scoped to a single organisation, so no tenant can ever read another tenant's ingested Tchap data.
- Clearance-Level Filtering: A secrecy gate compares each record's classification against the viewer's clearance and silently withholds anything above their level, enforced uniformly across rooms, messages, and statistics.
- Operational Statistics: Aggregate counts of total rooms, total messages, and rooms active in the last 24 hours give analysts an at-a-glance view of communication intensity.
- Cross-Domain Fusion: Each ingested room is emitted as an operational network-node entity into the coalition intelligence layer, allowing Tchap activity to be correlated against other sources in the wider entity graph.
- Full Audit Capture: Every ingestion records who performed it, which room was pulled, how many messages arrived, and the applicable secrecy level, building a tamper-evident interoperability history.
- Classification-Aware Persistence: Room classification and secrecy level travel with the data from the moment it is stored, so downstream filtering and disclosure decisions always have the original markings.
Use Cases#
National Police and Gendarmerie Liaison#
Joint operations with French national police often run on Tchap. Investigators can ingest the relevant operational rooms so that coordination messages sit beside case evidence, witness records, and alert data inside one investigation, with clearance filtering keeping sensitive threads visible only to cleared officers.
ANSSI and Cyber Defence Coordination#
Teams collaborating with the national cyber security agency on incident response can pull threat-coordination rooms into Argus, lining inter-agency chat up against indicators, network telemetry, and timelines so the full incident narrative is reconstructed in one place.
Prefectures and Ministerial Operations#
During major events or crises, prefectures and ministries coordinate on Tchap. Bringing those rooms into the operational picture lets command staff correlate field reporting, alerts, and government messaging without switching tools.
Audit, Oversight, and Disclosure#
Oversight bodies and legal teams require a defensible record of what inter-agency communication was accessed and when. The preserved ingestion history provides exactly that, supporting freedom-of-information responses, internal review, and judicial disclosure.
Integration#
The module is consumed through a typed GraphQL interface. Read fields return ingested rooms, the messages within a chosen room, and aggregate statistics, each automatically scoped to the caller's organisation and filtered by their clearance. A single ingestion operation accepts the Matrix homeserver address, an access token, the room identifier, and a classification, then pulls room metadata and recent messages in one call. Authentication uses OAuth 2.0 Bearer tokens, so the same JWT-based identity that protects the rest of the platform governs Tchap access with no separate credential store.
Connecting a Tchap source requires only a homeserver URL and a Matrix access token from the customer side. Because ingestion reads the standard Matrix Client-Server endpoints, the connector works against any compliant Tchap or Matrix homeserver without bespoke per-deployment wiring. Ingested rooms are also published into the cross-domain fusion layer as network-node entities, so the benefit reaches beyond a single view: Tchap activity becomes part of the broader correlation graph automatically, with no extra integration work for the customer.
Open Standards#
- Matrix Client-Server API v3: All room and message reads use the Matrix Client-Server API version 3 as published at
spec.matrix.org, calling the standard/_matrix/client/v3/rooms/{roomId}/stateand/_matrix/client/v3/rooms/{roomId}/messagesendpoints that any compliant homeserver exposes. - Matrix Transport (IETF draft-ralston-mimi-matrix-transport): Tchap interoperates through the Matrix transport described in the IETF MIMI working group draft, positioning the connector against the emerging open standard for federated, interoperable messaging transport.
- Matrix Event Types (m.room.message, m.room.member, m.room.name): Ingestion parses the canonical Matrix event types defined in the Matrix Specification, reading message bodies from
m.room.message, membership and member counts fromm.room.member, and human-readable titles fromm.room.name. - OAuth 2.0 Bearer Token (RFC 6749 / RFC 6750): Access to the platform interface is authorised with OAuth 2.0 Bearer tokens, aligning Tchap access with the same open authorisation framework used across the platform.
- JSON Web Token (RFC 7519): Caller identity, organisation scope, and clearance are carried in JWTs, with issuer, audience, expiry, and signature validated before any Tchap data is returned.
- ISO 8601 / RFC 3339: Room activity times and message event times are recorded as UTC-offset timestamps, giving unambiguous ordering when Tchap events are placed on a shared timeline with other sources.
Security & Compliance#
Access tokens for Tchap homeservers are used only to read the rooms a customer authorises and are never exposed through any read field. Data isolation is absolute: every stored room and message is bound to one organisation, and reads can never cross that boundary. The clearance gate is applied on the way out of the platform, so a viewer can never see a message classified above their secrecy level regardless of how the data was ingested. Each ingestion is written to an immutable interoperability audit record capturing the actor, the room, the message count, and the secrecy level, providing the evidence trail that government oversight, disclosure, and compliance regimes require.
Last Reviewed: 2026-05-26 Last Updated: 2026-05-26