First Chat Demo

The First Chat demo is the smallest runnable multi-process service demo in capOS. It boots a resident chat-server, a bounded chat-bot actor, and a native shell that can launch chat-client with explicit StdIO plus the broker-issued operator Chat and ChatModerator endpoint facets.

The chat service is not a shell builtin. The shell only launches a client process and services that client’s StdIO endpoint while the client talks to the resident Chat endpoint. The focused manifest routes the kernel singleton chat_endpoint through init to chat-server, which is the same endpoint the broker facets into operator shell bundles. The facet interface distinguishes ordinary participant calls from typed moderator calls before the server decodes their parameters.

Run It

Use the focused QEMU proof:

make run-chat

The scripted proof creates a volatile shell credential, rejects an attempted client badge relabel, launches chat-client under the authenticated shell session, proves that /admin clear-history sent through ordinary Chat.send remains message data, leaves and rejoins without stale inbox delivery, applies typed clear-history through ChatModerator, sends one lobby message, checks membership with /who, observes the resident bot reply, launches a second client in the same live session, and checks redacted audit counters. The terminal transcript should include:

[chat] ordinary admin-looking text and leave/rejoin inbox proof passed
[chat] /join <channel>, /leave, /who, /admin <verb>, /exit, or plain text
[chat:#lobby]> /admin clear-history
[chat] admin clear-history applied
[chat:#lobby]> hello from shell
[chat] #lobby <member-2> hello from shell
[chat] #lobby <member-1> [chat-bot] echo-bot heard you.

For default manual use, boot the ordinary playground:

make run

After login:

run "chat-client" with { stdio: client @stdio, chat: client @chat, chat_moderator: client @chat_moderator }

The default playground starts the resident chat-server and includes chat-client, but it does not start the bounded chat-bot proof actor. Use make run-chat when you need the one-shot echo-bot transcript.

For lower-level manual proof work, let make run-chat build the focused ISO, then boot capos-chat.iso yourself with the terminal UART attached to stdio and the console UART written to a log.

Useful client commands:

/join #other
/who
/admin clear-history
/admin lock-channel
/admin unlock-channel
/leave
/exit
plain chat text

The resident bot is a bounded proof actor. If the operator waits too long before joining and sending the first lobby message, the bot can time out and exit; the chat client and server remain usable, but the bot reply will no longer appear.

What It Demonstrates

make run-chat and the manual terminal path described above currently show:

• chat-server runs as a resident service on one shared endpoint;
• chat-server keys membership by the opaque caller-session reference in the endpoint metadata, not by a caller-selected endpoint badge;
• chat-bot is a separate participant with a delegated chat client endpoint and its own session-bound membership record; its proof-only ChatModerator facet lacks operator disclosure and receives the typed denied result;
• capos-shell launches chat-client as an ordinary userspace process;
• the foreground client receives only explicit StdIO, Chat, and ChatModerator grants;
• caller-selected endpoint relabeling is rejected for delegated chat clients;
• ordinary Chat.send text never selects moderation behavior, while the distinct ChatModerator schema carries typed verbs and results;
• leaving purges queued events for that channel, while bounded counters and explicitly disclosed coarse principal classifications remain associated with the live caller session across child processes;
• join, leave, send, and moderator audit rows contain static result labels, byte counts, and counters rather than channel text, message text, session or principal identifiers, or capability handles;
• the handle supplied to join is request data only; the service assigns visible member-N labels and the handle does not select membership authority or sender identity;
• lobby messages and bot replies are visible through the terminal transcript;
• /who lists current channel members from the resident service;
• client exit returns to the shell prompt, and the manifest child wait path observes clean shell and bot exits during normal completion.

Current Limits

This is not yet a distinct-local-user chat surface over Telnet or multiple terminals.

system.cue and system-chat.cue each boot one terminal-backed shell on the QEMU terminal UART, and the shell’s run command waits on the foreground client’s StdIO endpoint. Multiple chat-client runs can reuse the resident service, but the current manual flow is one foreground client at a time. The demo client still sends the hard-coded join handle shell for compatibility; the server ignores it for visible sender labels and does not request disclosed display/profile metadata from the session broker yet.

The default make run foreground shell now receives its shell bundle from AuthorityBroker, including a profile-scoped chat endpoint for operator shells and a distinct chat_moderator facet. Guest and anonymous shells do not receive either facet by default. An operator shell can therefore run the same chat-client command after login. This is still not a distinct durable user chat surface: the demo client joins with the hard-coded handle shell, the server assigns its own visible member label, and the service sees only a live service-scoped session key plus the explicitly requested principal-kind/auth-strength/profile tuple. Multiple terminal sessions still need a multi-session terminal host or network gateway before they are a real multi-user chat model.

To make distinct local users chat through Telnet or terminals, capOS still needs a multi-session terminal host or Telnet gateway that can keep multiple shell sessions alive, grant each session a broker-authorized chat root/facet, and disclose only the bounded display/profile metadata the user or broker explicitly permits.