Whatsup

Whatsup is a CLI-led local-first public-room chat application built on Lace. Its Deno CLI and plain TypeScript browser share the same records, authority checks, actions, projections, and interlace policy.

Implemented behavior includes:

• resumable community creation and invite-based join setup;
• local Lace-key import/export and profiles marked by that key;
• steward selection, rooms, writer grants/revocations, messages, replies, threads, edits, retractions, and reactions;
• small sealed-record attachments;
• local-only read markers and notification dismissals;
• saved peer endpoints plus bounded and open interlace sync; and
• static single-community endpoint artifacts for laced.

Current rooms are public. Bounded and open sync expose the supported whole-record public surface, and attachments store small file bodies directly in records. Whatsup has no server accounts, calls, private-room guarantee, large-file chunking, or application-specific HTTP API. See docs/authority.md for authority truth and PLAN.md for current workflow status.

Install and validate

From incubator/whatsup:

deno install
deno task check

build:gui, included by check, copies the Lace browser bundles built from this checkout into ignored public/assets/ output.

Local CLI setup

deno task whatsup --home /tmp/whatsup setup create \
  --display-name Alice --title "Example Community"

The CLI creates one local identity, community root, profile, general room, and writer grant. whatsup help lists the remaining record actions and sync commands.

Prepare a persistent endpoint

Whatsup does not run an application host. It writes ordinary deployment artifacts for laced and leaves static files and HTTPS to ordinary infrastructure:

deno task whatsup --home /tmp/whatsup endpoint prepare \
  --origin https://chat.example \
  --endpoint wss:chat.example/interlace \
  --output /tmp/whatsup-endpoint

laced check-config /tmp/whatsup-endpoint/laced.conf
laced --foreground --config /tmp/whatsup-endpoint/laced.conf

The output directory contains:

• endpoint-policy.datalog, bound to the exact community root and steward;
• whatsup-runtime-config.json, for the separately served browser bundle;
• laced.conf, with a loopback WebSocket listener and durable data directory.

After laced starts, seed it through ordinary interlace:

deno task whatsup --home /tmp/whatsup sync once \
  wss:chat.example/interlace

The prepare command also prints an origin-bound browser setup URL. Its fragment contains the community steward By-secret value. Keep it private. The fragment is not sent to the HTTP server; the browser strips it before fetching application metadata, verifies the origin and key, requires durable storage, and then uses the existing invite flow to fetch the exact root from the endpoint. The link is a reusable key copy, not a one-use session. If seeding or the first browser fetch fails, fix the endpoint and reopen the original setup URL.

Serve public/ and the generated whatsup-runtime-config.json with ordinary static infrastructure. Publish the base frontend at //u//whatsup//index.html; an HTTP-compatible deployment uses //u//whatsup/http//index.html. Public WSS normally terminates at a reverse proxy and forwards to the loopback ws: listener in laced.conf.

One endpoint policy hosts one community. Run a separate laced process and DataDir when independent community isolation is required.

Development fixture

deno task demo:fixture generates ignored demo-fixture.json throwaway identities for development. Never use those identities as deployment authority; browser bundles do not include their secrets.