Skip to main content
Multi-chat unification is planned and remains in design.

​
Overview

The multi-chat design brings separate chats into a coordinated view while keeping their stream context intact. Each stream has its own configuration, lifecycle, entries, and activity statistics. This lets an operator follow several conversations without mixing their rules or records. A stream’s access policy determines any account or token requirements for a particular activity; chat participation and message moderation retain their own context.

​
Core Components

The documented component names describe these responsibilities:
  • MultiChatManager: coordinates chat connections and per-stream configuration.
  • MultiStreamTracker: tracks each stream’s lifecycle and health.
  • Per-stream configuration: describes the stream’s state and any activity-specific access conditions.
  • Policy checks: evaluate the conditions selected for that stream and retain the meaning of the result.
  • Stream tagging: associates each entry with its originating stream through stream_id.
The manager coordinates the streams; the tracker describes how each is running. Stream-level permissions govern who can configure a stream, control its connection, or inspect its records.

​
Data Model

These field names are part of the documented design, not a deployment-specific schema. An integration defines their types, required fields, and permitted use. The token reference fields need an explicit meaning in the chosen integration. A wallet reference is relevant where an activity uses a wallet-based policy; it is not a requirement for every chat participant. Define verified in terms of the check performed. Keep an unmet condition distinct from a check that was not required or could not be completed. The result describes that policy check, not the quality of a participant or the truth of a message. Preserve the association between an entry and its stream when filtering, displaying, or summarising records.

​
Configuration and Lifecycle Operations

The design includes operations to:
  • Create, update, and delete stream configurations.
  • Start and stop a stream connection.
  • Read stream status and activity statistics.
  • Query entries by stream_id and timeframe.
Configuration changes need the relevant operator permission. Starting or stopping a connection changes its lifecycle; deleting a configuration needs a defined policy for the records associated with it. An integration also needs to explain how reconnects and interrupted connections affect status, retained entries, and activity statistics. This section describes the intended operations without prescribing endpoint paths.

​
Frontend Display

Use per-stream panes to show connection status and the latest entries. Keep the source stream visible when presenting messages in a combined view. Filters can help an operator examine the outcome of a particular access-policy check. Label the check and its result clearly, including cases where it was not required or could not be completed. Apply the viewer’s permissions to both the visible panes and the records returned for filtering. Moderation actions remain scoped to the relevant stream and its rules.