Coming soon · Private pilot

Chat technical preview

The target product contract for Launch Rail Chat: domain concepts, client integration, realtime recovery, service architecture, and the operational boundaries we plan to validate with private-pilot teams.

Preview notice: this page documents a proposed private-pilot contract, not a generally available release. Package names, commands, endpoints, schemas, and infrastructure choices may change through pilot validation. Do not build a production dependency against this preview.

Status and scope

A complete product domain, entering focused validation.

Chat is registered as a private-pilot module. The first pilot is intended to validate the conversation model, React and Flutter integration, customer-cloud operations, security boundaries, and workload behavior before a stable release contract is published.

Product workflows

Direct and group conversations, channels, threads, mentions, reactions, attachments, unread state, and moderation.

Client surfaces

Proposed React components, Flutter widgets, REST and Connect APIs, and a recoverable WebSocket stream.

Deployment boundary

Customer-owned AWS is the first target. Launch Rail does not need to retain the customer’s cloud credentials.

Security boundary

Tenant scope, Authz decisions, expiring sessions, revocation, and governed agent operations are first-class design inputs.

Proposed quickstart

Configure the module, then compose the product UI.

The intended workflow starts from a versioned project manifest, deploys into the customer environment, and issues scoped chat sessions to the application. The commands and package interfaces below are illustrative pilot targets.

1
Define
Select Chat and its required Identity and Authz integrations.
2
Deploy
Generate and apply customer-cloud artifacts from the customer environment.
3
Compose
Connect the proposed React or Flutter kit to a scoped session.

launchrail.yaml previewYAML · proposed private-pilot contract

project: atlas-product
environment: pilot
modules:
  chat:
    channel: private-pilot
    integrations:
      identity: required
      authz: required
      media: optional
      notifications: optional
      audit-log: optional
deployment:
  target: aws
  credentials: ambient

React kit previewTSX · proposed private-pilot contract

// Proposed private-pilot package and API
import {
  ChatProvider,
  ConversationList,
  MessageThread,
  MessageComposer,
} from "@launchrail/chat-react";

export function TeamChat({ session }) {
  return (
    <ChatProvider session={session}>
      <ConversationList />
      <MessageThread conversationId="team-room" />
      <MessageComposer conversationId="team-room" />
    </ChatProvider>
  );
}

Flutter kit previewDart · proposed private-pilot contract

// Proposed private-pilot package and API
LaunchRailChat(
  session: chatSession,
  child: ChatShell(
    conversations: ConversationList(),
    thread: MessageThread(conversationId: "team-room"),
    composer: MessageComposer(conversationId: "team-room"),
  ),
)

Domain model

Stable concepts before transport details.

The proposed model keeps product-facing concepts explicit so clients do not have to infer permissions, unread state, or delivery behavior from raw event streams.

Conversation: A tenant-scoped container for participants, membership policy, kind, metadata, and the durable message sequence.
Membership: The participant’s role, join state, mute state, notification preference, and last-read sequence for a conversation.
Message: An immutable identity plus editable content state, sender, sequence, reply relationship, attachment references, and timestamps.
Reaction: A user-scoped reaction linked to a message with idempotent add/remove semantics.
Receipt: Delivery or read progress represented independently from the message body and aggregated for suitable product views.
Moderation action: A policy-checked action such as report, hide, remove, mute, block, or membership restriction with an audit boundary.

Tenant and authorization

Identity starts the session; policy still guards every action.

The proposed flow separates application authentication from a short-lived chat session. A trusted application boundary supplies tenant and user context, while Chat consults membership and Authz policy before reads or writes.

Application session

Identity establishes the signed-in user and tenant context.

Scoped chat session

A trusted boundary requests limited chat scopes for that user.

Per-action decision

Membership and Authz are evaluated for conversation operations.

Scoped session request previewHTTP · proposed private-pilot contract

POST /v1/chat/sessions
Authorization: Bearer <trusted-application-session>
Content-Type: application/json

{
  "tenant_id": "tenant_acme",
  "user_id": "user_42",
  "environment": "pilot",
  "requested_scopes": ["chat:read", "chat:write"]
}

Tenant and environment scope are mandatory, not caller-selected defaults.
A conversation identifier never substitutes for an authorization decision.
Sessions are designed to expire and remain revocable.
Service and agent credentials use separate policies and audit paths.

Realtime recovery

Treat the socket as fast delivery—not permanent truth.

The planned client model combines a durable history API with a scoped WebSocket stream. Clients track per-conversation sequence and recover gaps from history after reconnect, sleep, network switching, or delayed delivery.

Connect

Exchange a valid chat session for a scoped realtime ticket and subscribe only to permitted conversation streams.

Receive

Apply events in sequence, deduplicate by event identity, and update local projections.

Detect a gap

If the next sequence is missing, stop assuming continuity and request durable history after the last known cursor.

Reconcile

Merge durable records, advance the cursor, and resume realtime consumption without duplicating user-visible messages.

Event envelope previewJSON · proposed private-pilot contract

{
  "event_id": "evt_01J...",
  "type": "chat.message.created.v1",
  "tenant_id": "tenant_acme",
  "conversation_id": "conv_product",
  "sequence": 1842,
  "occurred_at": "2026-07-16T10:24:00Z",
  "payload": {
    "message_id": "msg_01J...",
    "sender_id": "user_42",
    "text": "Release checklist is ready"
  }
}

Target architecture

Durable commands, asynchronous work, replaceable edges.

The pilot target uses a stateless Go API, PostgreSQL for durable domain state, a transactional outbox, NATS JetStream for distributed work, Redis for ephemeral presence, and adapters for search, media, and notifications.

Clients

React · Flutter · backend

Chat API

REST · Connect · WebSocket

Durable core

PostgreSQL · outbox

NATS JetStream

Events and worker coordination

Redis

Presence and connection state

Search adapter

Replaceable indexing boundary

Ecosystem adapters

Media, Notifications, Audit Log

Pilot topology: the first deployment target is customer-owned AWS in a single region with multi-availability-zone infrastructure where supported by the selected providers. Active-active multi-region operation is outside the first pilot.

Operational semantics

Failure behavior is part of the product contract.

These are target semantics for pilot validation. They will only become stable guarantees after implementation, workload testing, recovery exercises, and compatibility review.

Write acknowledgement

A message is acknowledged after its durable state and outbox record commit together.

Conversation ordering

A monotonic sequence orders durable changes inside a conversation; no global ordering is promised.

Idempotency

client_message_id and the Idempotency-Key header make caller retries visible and deduplicable.

Event delivery

Downstream events use at-least-once delivery; consumers deduplicate by event identity.

Realtime recovery

Sequence gaps trigger durable history reconciliation rather than silent best-effort continuation.

Ephemeral signals

Typing and presence may expire or be dropped; they never replace durable membership or message state.

Retry-safe publish previewHTTP · proposed private-pilot contract

POST /v1/conversations/conv_product/messages
Authorization: Bearer <scoped-chat-session>
Idempotency-Key: client_message_9c12
Content-Type: application/json

{
  "client_message_id": "client_message_9c12",
  "text": "Release checklist is ready",
  "reply_to_message_id": null,
  "attachment_ids": []
}

Ecosystem integrations

Shared contracts, independently deployable modules.

Identity and Authz are planned dependencies for the pilot. Media, Notifications, Audit Log, and Entitlements are optional connections selected by the product workflow and deployment blueprint.

IdentityRequiredUser, session, and tenant contextService details AuthzRequiredMembership and action policyService details MediaOptionalAttachment references and policyService details NotificationsOptionalOffline delivery and preferencesService details Audit LogOptionalModeration and privileged operationsService details EntitlementsOptionalPlan-aware feature accessService details

Governed agent access

No unrestricted agent endpoint.

Proposed Chat tools are exposed only through the Launch Rail Agent Gateway. The gateway applies tenant and environment scope, tool allowlists, read or write scope, budgets, Authz policy, expiration, revocation, approval, and audit controls.

Pilot read tools

List permitted conversations, retrieve message history, and search within the agent’s explicit scope.

Approval-gated write

The first proposed mutation is sending a message only after an approval decision, with the resulting action recorded in Audit Log.

Review Agent Gateway controls

Release gates

What must be true before the pilot becomes a release.

Availability will change only after the product and operational contract have evidence behind them. A roadmap label is not treated as a readiness claim.

Isolation and policy

Cross-tenant denial, session expiry, revocation, membership policy, and privileged-operation review.

Recovery

Reconnect, history reconciliation, worker retry, outbox replay, backup, and restore exercises.

Client compatibility

React and Flutter contract tests, upgrade guidance, error behavior, and reference workflows.

Operations

Workload validation, observability, runbooks, incident boundaries, and support lifecycle.

Supply chain

Versioned artifacts, signed release metadata, dependency inventory, and compatibility records.

Deployment

Repeatable customer-cloud planning and deployment without Launch Rail retaining cloud credentials.

Have a real chat workflow to validate?

We’ll map the product requirements and pilot boundaries before implementation.

Request pilot access

Related services

Identity Authz Notifications Media

Related use cases

Consumer applications AI platforms Enterprise deployment

A complete product domain, entering focused validation.

Product workflows

Client surfaces

Deployment boundary

Security boundary

Configure the module, then compose the product UI.

Define

Deploy

Compose

Stable concepts before transport details.

Identity starts the session; policy still guards every action.

Application session

Scoped chat session

Per-action decision

Treat the socket as fast delivery—not permanent truth.

Connect

Receive

Detect a gap

Reconcile

Durable commands, asynchronous work, replaceable edges.

Clients

Chat API

Durable core

Failure behavior is part of the product contract.

Write acknowledgement

Conversation ordering

Idempotency

Event delivery

Realtime recovery

Ephemeral signals

Shared contracts, independently deployable modules.

No unrestricted agent endpoint.

Pilot read tools

Approval-gated write

What must be true before the pilot becomes a release.

Isolation and policy

Recovery

Client compatibility

Operations

Supply chain

Deployment

Have a real chat workflow to validate?

Related services

Related use cases