This is a static guide, not a live service status. Public remote writes and execution remain disabled. No JavaScript is needed to read this page.

Mailboxes and traffic

Mailboxes are the addressed front door of the Cursors fabric. They hold deduplicated envelopes until an authorized receiver reads, acknowledges, relays, expires, or checkpoints them.

Chat is not a special subsystem. It is one message family beside cursor references, grants, assertions, interests, requests, replies, receipts, proposals, and signaling.

What you are looking at

A mailbox should feel like a queue component with visible message structure, not a speech-bubble widget bolted onto the side of the system:

sender / program / resolver
          │
          ▼
     envelope/v1
          │
          ▼
      [ MAILBOX ]
       │   │   │
       │   │   └── receipt / expiry
       │   └────── dedup / ordering
       └────────── addressed delivery

Inspect LOCAL MAILBOX

Select the wire connected to it as well. The wire should show the message family and representative fields rather than merely saying “traffic.”

A rich envelope

A generic envelope/v1 can expose:

id
subject
causal parents[]
author evidence
capability refs[]
payload ref/body
expiry
receipt policy

Different envelope families specialize the payload without throwing away this common machinery.

Envelope families

Family	Carries	Durable by default?
`chat/v1`	human or agent conversation with reply parents	local bounded log today
`cursor/v1`	cursor IDs, continuations, and checkpoint references	yes when accepted
`pointer/v1`	cryptopointers and resolver requests	policy-dependent
`dataspace/v1`	assertions, interests, facet and lease events	normally ephemeral
`capability/v1`	grant identifiers and presentations	records yes; secrets never
`receipt/v1`	delivery, resource, or external-effect evidence	yes
`signal/v1`	short-lived encrypted WebRTC candidates	no; short expiry

The family should be visible on the wire and inspectable independently from its carrier.

What delivery proves

Delivery and application effects have separate receipts.

accepted by mailbox ≠ executed by body
transported by peer ≠ authored by peer
address known ≠ write authority

A locally signed envelope can provide author-key provenance. Capability references can provide authority evidence after verification. Those are explicit message fields, not properties inferred from the socket or peer that carried the bytes.

What works now

Every inspectable cockpit level has a channel scoped to:

site mount + curve address + inspected subject

Messages are stored as bounded local envelopes and synchronized across same-origin tabs with BroadcastChannel. When the local Self is unlocked, new messages are signed with that mailbox key and labelled local-signed; otherwise they remain explicitly unsigned. Both remain device-local unless another fabric is explicitly used.

Reloading preserves the bounded local log. The public deployment does not join a shared mailbox network or silently send drafts to a remote service.

Message anatomy should stay visible

When inspecting a message, the UI should separate:

addressing: where the envelope is intended to go;
causality: reply/parent relationships;
author evidence: signature/key evidence, or explicitly unproven;
authority: capability references and decisions;
payload: inline typed body or immutable pointer;
transport: which wire/carrier moved it;
delivery: dedup/receipt/expiry state;
execution: if anything later consumed it and produced an effect receipt.

Those fields may be shown together because humans enjoy one screen, but they must not be semantically collapsed because computers enjoy incidents.

Durable message choice

The recommended durable form is one signed cursor per durable message or batch, with explicit reply parents and a mailbox receipt. A locally signed envelope establishes key provenance but still needs an accepted durable checkpoint and delivery receipt before the cockpit calls it replicated.

Cheap local drafts may remain unsigned until an operator unlocks a Self or chooses to checkpoint.

Storage tiers

ephemeral UI — unsaved typing and transient presence;
local mailbox — bounded reload-safe drafts on one origin/curve;
explicit shared fabric — a deliberately joined browser or other compatible fabric;
meeting mailbox — invitation-only shared curve;
archival checkpoint — signed cursor roots plus encrypted immutable bodies;
optional remote mailbox — separately deployed and explicitly admitted, never required by the browser-first core.

Moving outward is always explicit.

Continue with Cryptofabrics, Curve Spaces, and Capabilities.