group_chat.*

group_chat.* is the lower-level multi-agent group-chat session primitive that the durable teams.chat.* thread (and the Panel's three-panel group-chat window) build on. Six methods are registered in HandlerRegistry::new() as service_unavailable placeholders, then overlaid with the real handlers in register_group_chat_handlers once the GroupChatOrchestrator + GroupChatExecutor exist at server boot (src/bin/aleph-server/commands/start/builder/handlers/system.rs:95-150).

The placeholder is what gets called between registry construction and orchestrator install — calls during that window return INTERNAL_ERROR: group_chat.<method> requires GroupChatOrchestrator runtime - wire Gateway first. In normal operation the orchestrator is installed before the first RPC arrives.

For the durable per-team thread the Panel actually uses, see teams.* (teams.chat.send / teams.chat.history / teams.chat.thread).

Methods

group_chat.start

Start a new group-chat session over a set of personas. When initial_message is supplied, executes the first round immediately and returns the round's messages.

Parameter	Type	Required	Description
`personas`	object[]	yes	Each entry is a `PersonaSource` (e.g. `{ "kind": "Agent", "agent_id": "reviewer" }`)
`topic`	string	no	Session topic
`initial_message`	string	no	First user message — runs the first round
`source_channel`	string	no	Defaults to `"rpc"`
`source_session_key`	string	no	Defaults to `"rpc:direct"`

Response (no initial_message): { "session_id" }.

Response (with initial_message): { "session_id", "messages": [ ...{session_id, speaker, content, round, sequence, is_final}... ] }.

group_chat.continue

Advance the session with a new user message. The agents respond in turn up to max_rounds; once the limit is reached the session is force-ended and the call returns INTERNAL_ERROR: Round limit exceeded.

Parameter	Type	Required	Description
`session_id`	string	yes	The id from `group_chat.start`
`message`	string	yes	User message (non-empty)

Response: { "session_id", "messages": [ ...{session_id, speaker, content, round, sequence, is_final}... ] }.

group_chat.mention

Like group_chat.continue, but the targets array prioritises the mentioned personas in the round.

Parameter	Type	Required	Description
`session_id`	string	yes	The id from `group_chat.start`
`message`	string	yes	User message (non-empty)
`targets`	string[]	no	Persona ids to prioritise (e.g. `["@all"]` or a specific `agent_id`)

Response: same shape as group_chat.continue. The panel's @-mention auto-complete maps to targets; @all expands to every participant.

group_chat.history

Get the conversation history for a session.

Parameter	Type	Required	Description
`session_id`	string	yes	The id from `group_chat.start`

Response: { "session_id", "history": [ ...{round, speaker, content, timestamp}... ], "current_round" }. Read-only, safe to call at any time.

group_chat.list

List every active session. Sessions in any state other than Active are filtered out.

Request: no params.

Response: { "sessions": [ ...{id, topic, participants: [{id, name}], current_round, status, created_at}... ] }.

group_chat.end

End a group-chat session. The session Arc is dropped, the orchestrator forgets the session, and any in-flight executor round falls through.

Parameter	Type	Required	Description
`session_id`	string	yes	The id from `group_chat.start`

Response: { "ended": "<session_id>" }.

Runtime lifecycle

HandlerRegistry::new()       →  group_chat.* = service_unavailable placeholder
   ↓
register_group_chat_handlers →  group_chat.* = real handler (orchestrator-bound)
   ↓
session can be started

A minimal / simulated server that does not build a GroupChatOrchestrator keeps the placeholders forever. There is no runtime fallback that points group_chat.* at the teams.chat.* surface — the two namespaces share the same fan-out mechanics (the teams thread is built on top of the orchestrator's GroupChatBroadcaster), but the JSON-RPC contracts differ.

Concurrency

Each session takes its own per-session lock for the duration of a round; the orchestrator lock is only held briefly to obtain the session handle. Different sessions proceed concurrently, and the round itself uses the same parallel-fan-out guard as teams.chat.send (chain depth + fan-out width).