DEV Community: Shawn Bure

Single-use invite links are capabilities, not permanent room URLs

Shawn Bure — Wed, 05 Aug 2026 20:19:06 +0000

I created and maintain elm.chat, the open-source project used as the implementation example below. I developed this article with substantial AI assistance, then reviewed the code paths, tested the claims, and take responsibility for the final text.

A permanent room URL is easy to share and impossible to unshare. A safer invitation separates the authority to locate a room, enter it once, decrypt its content, reconnect, and administer it.

This is the design behind elm.chat's current single-use invite flow. The reusable lesson applies to any capability-link system.

Do not make one URL carry every kind of authority

A reusable secret link often answers several questions at once: which room, who may enter, and which key decrypts the conversation. Forwarding that link forwards every capability it contains.

elm.chat gives each concern a different value:

Room ID: a path segment used to route the request.
Invite token: a query value the room validates for one admission.
Room secret: a URL fragment used by browsers to derive the encryption key.
Creator token: a separate capability for issuing invites, revoking them, removing participants, and destroying the room.

/c/{roomId}?invite={inviteToken}#{roomSecret}

Browsers do not send the fragment in a normal HTTP request. The relay receives the room ID and invite token but not the room secret through ordinary navigation. This narrows the relay's authority; it does not make the connection anonymous.

Represent an invite as a state machine

An invite is not a Boolean named valid. It has time and ownership semantics.

type Invite = {
  token: string;
  createdAt: number;
  expiresAt: number;
  consumedAt?: number;
  consumedBySessionId?: string;
  revokedAt?: number;
};

Creation requires the creator capability. The room generates the token, applies a ten-minute default lifetime with a one-minute floor, persists the record, and returns it only after storage succeeds.

Consume before admitting

The join transition rejects a missing, revoked, consumed, or expired invite. For the winning session, it writes consumedAt and consumedBySessionId before the first storage await.

if (!invite || invite.revokedAt || invite.consumedAt || invite.expiresAt <= now) {
  rejectJoin();
}

invite.consumedAt = now;
invite.consumedBySessionId = sessionId;
invites.set(invite.token, invite);
await persistInvites();
admitSocket();

That ordering matters. Another join handled by the same room sees the in-memory consumed state immediately, even while persistence is in progress.

Keeping this transition inside one room-scoped Durable Object avoids a separate read-then-write race across stateless workers or database replicas. If your platform does not provide single-owner coordination, use a conditional write or transaction that changes exactly one unconsumed record.

Cloudflare's current Durable Objects rules describe each object as a globally unique, single-threaded coordination point and explain the input and output gates around storage.

The practical guarantee is at most one new session admitted, not magical exactly-once delivery. A failure after persistence can burn an invite without completing the join.

Reconnect is not a second redemption

At-most-once admission without reconnect semantics creates a brittle product: a page reload consumes a second invite or locks out the intended participant.

elm.chat stores a random, room-scoped session ID in browser session storage. The session that consumed the invite may reconnect with the same ID while the invite remains unrevoked; a new session is rejected.

This is continuity, not identity verification. Anyone who obtains the invite before redemption can still win the race, and browser state can be copied or compromised.

Revocation should end current authority too

Revoking an unused invite prevents a future join. Revoking a consumed invite also disconnects its currently connected consuming session.

Otherwise a creator-facing “revoke” button changes a database flag while leaving the admitted participant online.

Room destruction is broader: it closes every socket and ends the room lifecycle. Neither action can erase plaintext a participant already saved, copied, photographed, forwarded, or backed up.

Test the negative paths

Redeem the same invite concurrently from two new sessions; only one may join.
Reload the winning browser; the same session should reconnect without a new redemption.
Open the consumed link in a different session; it must fail.
Revoke an unused invite; later redemption must fail.
Revoke a consumed invite; its connected session must be removed.
Advance beyond expiry; redemption must fail even if the token was never used.
Restart or hibernate the room owner; consumed and revoked state must survive.

If you need funnel evidence, count creation and redemption only in aggregate. Do not put room IDs, invite tokens, participant IDs, or message data into growth analytics.

Inspect the working implementation

The complete TypeScript path is public:

elm.chat has not had an independent security audit. Message authentication and replay/duplicate protection are unfinished, the Cloudflare relay sees ordinary connection metadata, and endpoints can retain copies. It is not an anonymity, high-risk, regulated-data, or production-finance system.

The project is AGPL-3.0-or-later. If you want to test the coordination model, deploy it to your own Cloudflare account and inspect every claim.

Fixing Deploy to Cloudflare in a monorepo: expose the root contract

Shawn Bure — Wed, 05 Aug 2026 19:27:29 +0000

Disclosure: I created elm.chat. AI tools substantially assisted drafting and implementation under my direction; I reviewed the code, tests, sources, and claims and remain responsible for the result. The project is early-stage and has not had an independent security audit.

A deploy badge can look correct while every new user reaches No Wrangler
configuration detected. In a workspace repository, the fix is to make the
target root a complete deployment contract.

The failure appears after the badge works

elm.chat already had a working production deployment and a valid Deploy to
Cloudflare link. Its Wrangler configuration lived under workers/api, where
local and production commands could find it. A new visitor followed the badge,
however, and Cloudflare reported No Wrangler configuration detected before
falling back to automatic project configuration.

That is the dangerous version of a deployment bug: maintainers can keep
shipping while the public self-host path is broken. The badge tests only
navigation. It does not prove that the target directory exposes everything the
setup flow needs.

The target directory is the contract boundary

Cloudflare analyzes the directory named by the deploy URL. If the URL targets
the repository root, nested workspace configuration is not a substitute for a
root deploy contract. The root needs a Wrangler configuration plus build and
deploy scripts that work from that directory.

{
  "scripts": {
    "build": "npm run build --workspace @example/web && npm run build --workspace @example/api",
    "deploy": "npm run build && wrangler deploy -c wrangler.jsonc"
  }
}

The root scripts can delegate to workspaces. What matters is that a stranger—and
Cloudflare's project analysis—can start at the target root without knowing the
repository's internal layout.

Keep the public template smaller than production when necessary

elm.chat's production Worker uses an optional Analytics Engine binding for its
own aggregate growth measurement. Cloudflare does not list Analytics Engine
among the resources its deploy button automatically provisions, so the public
root template omits that binding. Independent instances work without sending
elm.chat measurement events.

Do not copy every production binding into a one-click template by reflex.
Include only resources the platform can provision or the deployer can supply
during setup. Otherwise the button turns an optional integration into a
first-run failure.

Two configurations require a drift test

A root template and a workspace production configuration can quietly diverge.
elm.chat runs a repository check that compares the Worker entry point, Durable
Object binding, migration tag, assets directory, compatibility date, and
resolved paths. The build fails if the shared runtime contract drifts.

This keeps intentional differences explicit: production can retain an optional
binding, while the independently deployable root template stays minimal and
reproducible.

Test the public journey, not the maintainer journey

Open the public repository as a visitor would.
Follow the published deploy button rather than a private dashboard shortcut.
Select an account and wait for repository analysis.
Confirm the detected build command, deploy command, and root path.
Stop and investigate if the fallback warning appears.
Run both root and workspace Wrangler dry runs in continuous integration.

Cloudflare documents the supported button format, scripts, and provisioned
resources in its Deploy to Cloudflare
guide.
The elm.chat repair is public in pull request
89, including its root
configuration and parity check.

The reusable lesson

A one-click deploy feature is an external API. Its callers do not share the
maintainer's working directory, cached settings, or mental model. Treat the
target root as a stable interface, make every dependency visible there, and
test it from the outside.

elm.chat is an open-source disposable messenger and an inspectable case study,
not an independently audited security product. Message authentication and
replay/duplicate protection remain unfinished. The hosted Cloudflare relay can
observe ordinary connection metadata, and participant devices can retain
anything they receive. It is not positioned for anonymous, high-risk, or
regulated communication.

Originally published at https://elm.chat/cloudflare-deploy-button-monorepo on August 5, 2026.

Deletion is a distributed-systems contract, not a UI animation

Shawn Bure — Tue, 04 Aug 2026 22:07:12 +0000

AI-assistance disclosure: I used AI for source discovery, structure, and editing. I manually reviewed the technical claims against the public code and primary platform documentation, and I stand behind the analysis.

A disappearing row proves only that one interface stopped rendering it. Engineers who promise deletion have to define what happens across clients, relays, databases, caches, logs, queues, replicas, backups, and recovery paths.

Deletion is an end-to-end property

In a distributed system, data rarely has one address. A user action can produce an application record, search index entry, cache value, analytics event, retry payload, queue message, log line, database replica, backup block, notification preview, and one or more client-side copies. Hiding the application record does not resolve the rest.

A credible deletion promise therefore needs a scope, an authority, a deadline, and a failure model. Scope identifies the copies the service controls. Authority identifies who may trigger destruction. The deadline says when controlled copies become inaccessible and when they are physically reclaimed. The failure model explains what happens when a component is offline, a retry arrives late, or recovery restores older state.

Start with a state inventory, not a delete endpoint

Before designing an API, list every place the data can exist and why it exists there. Classify each location as authoritative storage, derived storage, transit, operational telemetry, backup, or participant-controlled state. Give every class an owner and a retention rule. If a team cannot enumerate a copy, it cannot make a defensible claim about deleting that copy.

State class	Typical examples	Deletion question
Authoritative	Primary database, object storage	What event makes the record unreachable?
Derived	Indexes, caches, thumbnails	How are stale derivatives invalidated?
Transit	Queues, retries, relay buffers	Can an old payload recreate deleted state?
Operational	Logs, traces, analytics	Was sensitive content excluded before collection?
Recovery	Replicas, snapshots, backups	How is destruction preserved after restore?
Participant	Downloads, screenshots, exports	Which copies are outside service control?

Inventory every controlled copy before defining a deletion promise.

Model destruction as an irreversible state transition

A boolean such as deleted=true is usually too weak. Systems often need a lifecycle that distinguishes an active object from one that is closed to new writes, destroyed for normal access, and eventually reclaimed from recovery media. The transition into the destroyed state should be monotonic: delayed requests, retries, and replayed events must not reopen it.

ACTIVE -> SEALED -> DESTROYED -> RECLAIMED
      |          |
      +--expire--+

Invariant: no transition leaves DESTROYED or RECLAIMED.

Store the destruction marker wherever the system stores the object's identity, and make every write path check it. If a backup restore can resurrect an older active record, the recovery procedure must replay later destruction markers before the object becomes reachable.

Retries and restores may move forward, never out of destruction.

Separate the control plane from the data plane

The control plane answers whether an object exists, who may use it, when it expires, and whether destruction has occurred. The data plane carries the content. Keeping these responsibilities separate makes it possible to retain the minimum state needed to enforce an irreversible tombstone without retaining the content that the tombstone is meant to retire.

This separation also sharpens review. A reviewer can ask whether the control plane authorizes destruction correctly, whether the data plane writes content anywhere durable, and whether either plane leaks content into logs or metrics. Encryption helps with content confidentiality, but it does not answer lifecycle, metadata, or endpoint questions by itself.

Design for the failures that make data return

Most deletion bugs are resurrection bugs. A mobile client reconnects with an old offline mutation. A queue retries a create event after a tombstone. A cache repopulates from a lagging replica. A restore process brings back a record but not the later delete. A search index remains queryable after the primary row is gone. These are ordinary distributed-systems behaviors, so deletion tests must exercise them deliberately.

Make write operations conditional on the current lifecycle state.
Give destructive transitions stable, idempotent identifiers.
Expire queued and offline mutations before they can outlive their purpose.
Propagate invalidation to indexes and caches through observable workflows.
Keep content out of logs, traces, error reports, and analytics by construction.
Document backup retention separately from interactive deletion latency.

Verification needs negative evidence

A successful API response proves that one component accepted a request. It does not prove that the system can no longer serve, search, replay, restore, or infer the data. Verification should test absence across every controlled state class and should repeat those checks after component restarts, delayed delivery, cache refresh, replica catchup, and recovery exercises.

Create uniquely identifiable test content without using real sensitive data.
Confirm each intended state class receives—or deliberately never receives—it.
Trigger expiry and explicit destruction through every authorized path.
Attempt reads, writes, searches, reconnects, retries, exports, and sync operations.
Restart components and replay delayed messages that predate destruction.
Restore a pre-destruction snapshot, then apply the documented recovery procedure.
Check logs, traces, metrics, crash reports, indexes, and caches for the marker.
Record which participant-controlled copies remain outside the service boundary.

Verification seeks negative evidence across restart and recovery paths.

User language should match the system boundary

"Gone forever" is almost never an engineering statement. A service can promise that it no longer serves content, that controlled content stores were purged, or that backups age out within a documented window. It cannot promise that a recipient forgot, that a screenshot vanished, that a compromised endpoint was cleaned, or that network metadata was never observed unless the architecture actually provides those properties.

Product copy should name the actor and the scope: "the relay no longer retains the room" is testable; "this conversation leaves no trace" is not. Honest language is not a conversion penalty. It is part of the interface contract, especially when users are choosing a tool because they want less durable data.

elm.chat as an inspectable, imperfect case study

elm.chat applies a narrow version of this model. A Durable Object stores room policy, status, creator capability, and invite state. Connected browsers hold the current conversation history. The relay forwards encrypted messages and file chunks without persisting a server-side transcript. Destroying the room changes its control-plane state so later joins and writes are rejected.

The tradeoffs are explicit. Cloudflare can observe IP addresses, connection timing, sizes, and presence. Participants can retain plaintext. Peer-supplied history is not a trustworthy archive, and message authentication plus replay and duplicate protection remain unfinished. The project has not had an independent security audit and is not an anonymity, compliance, whistleblowing, or high-risk communications system.

The design review question

Do not ask only, "Where is the delete button?" Ask, "Which controlled copies can still influence behavior after destruction, and what evidence proves they cannot bring the object back?" That question turns deletion from a user-interface gesture into a system property engineers can model, test, monitor, and explain.

The complete source, architecture, threat model, and deployment path are public under AGPL-3.0 for anyone who wants to challenge the example or adapt the design to a different infrastructure.

Originally published at elm.chat. Cross-posted here with the original URL set as canonical.

Building ephemeral encrypted chat with Cloudflare Durable Objects

Shawn Bure — Mon, 03 Aug 2026 20:22:24 +0000

Disclosure: I created elm.chat and used AI tools for drafting and implementation support under my direction. I reviewed the architecture, code, tests, and claims and remain responsible for the result.

I built elm.chat around a narrow idea: a conversation should not automatically become a permanent server-side asset.

It is not a replacement for a contact network or a claim that metadata can disappear. It is a disposable room for one live conversation. The interesting engineering question was how to make that room reliable without giving the server a readable or persistent transcript.

The current answer is:

React and Web Crypto in the browser
one Cloudflare Worker for the app and API
one Durable Object per room
one WebSocket per participant
encrypted content relayed, but not persisted, by the Durable Object

The complete project is AGPL-3.0 source.

One coordination boundary per room

A room is a natural Durable Object boundary. One object owns:

room policy and lifecycle
participant presence
creator capabilities
single-use invite state
WebSocket relay
expiry and destruction

The Worker creates room metadata, addresses the object by room ID, and routes subsequent API and WebSocket traffic to it.

The object stores the room policy, status, creator token, and invite records. It does not store message envelopes, encrypted file chunks, or a transcript.

That distinction matters. “Encrypted at rest” would still make the server a durable archive. elm.chat instead asks currently connected clients to hold the conversation in memory.

The room secret stays in the fragment

Room creation starts in the browser:

Generate a random 256-bit room secret.
Create room metadata through the Worker.
Navigate to /c/:roomId#<room_secret>.
Derive the room key locally with HKDF-SHA-256.

The fragment is not included in normal HTTP requests, so the Worker receives the room ID but not the room secret. A strict Referrer-Policy: no-referrer reduces accidental capability leakage to other origins.

The browser uses the derived AES-GCM-256 key for message and file content:

each message gets a fresh random 96-bit nonce
files are divided into 64 KiB chunks
each file chunk is encrypted independently

The relay receives ciphertext envelopes and routing information, not plaintext.

One WebSocket carries the live room

After joining, a client uses one WebSocket for:

presence
encrypted messages
encrypted file chunks
transcript-sync requests and responses
participant removal
destruction events
keepalive traffic

WebSocket attachments are the source of truth for live membership. They survive Durable Object hibernation, so the object can wake and continue targeted routing without relying on a process-local participant map.

When a new participant joins, the server does not load a transcript. The client requests one from peers that are already connected. A peer sends its current encrypted history through the relay, with a hard cap on the number of synced messages.

If nobody connected still has an item, it is gone. That is intentional.

Why I did not use direct WebRTC

Peer-to-peer sounds like the obvious privacy choice, but the transport tradeoff is more complicated.

Direct WebRTC ICE negotiation can reveal participant IP addresses to other people in the room. Connectivity can also fail on mobile carriers, symmetric NAT, and restrictive networks unless the application adds a TURN relay.

I chose a Durable Object relay because:

room members never connect directly
participants do not learn one another’s IP addresses
the same transport works across restrictive networks
there is no separate STUN/TURN service to operate

This does not eliminate metadata.

Cloudflare still sees each connection’s IP address, timing, sizes, and presence. An observer can infer activity bursts even without decrypting content. The architecture moves content trust away from the server while accepting that the relay remains a metadata observer.

That is the actual claim—not “no trace.”

One-time membership

The room creator holds a creator capability in local browser storage and can:

issue single-use invites
revoke invites
remove participants
destroy the room

A non-creator needs a valid invite to join. The invite is consumed by the first new session that uses it. That same session can reconnect after a reload, but another session cannot reuse the link.

This makes an elm.chat URL a handoff for one participant, not a permanent public room address.

What the current design does not solve

End-to-end encryption and ephemerality do not make a system invulnerable.

The current build does not solve:

screenshots or copied plaintext
compromised devices or browser extensions
malicious recipients
traffic analysis
denial of service
strong anonymous routing
verified human identity
forward secrecy beyond the shared room key

The clients generate ephemeral identity keys, but those keys are not yet used to authenticate messages. Replay and duplicate protection are also unfinished. The project has also not had an independent security audit.

Those are not footnotes. They define where the current system should and should not be trusted.

Run it or review it

The repository includes:

the architecture
the threat model
a one-click Cloudflare deployment path
manual Wrangler deployment instructions
contributor guidance and scoped issues

You can try the live room, inspect the source, deploy it to your own Cloudflare account, or review the current security status and limitations.

The feedback I am most interested in is on:

the encrypted-relay versus WebRTC tradeoff
one Durable Object per room as the coordination boundary
client-supplied transcript sync after object hibernation
the message-authentication path that should come next

If you find a security issue, please use the repository’s private reporting instructions rather than publishing an exploitable detail.

AI Does Not Need Another Demo. It Needs an Operating Boundary.

Shawn Bure — Tue, 28 Jul 2026 17:57:47 +0000

The model is important. The system around the model determines whether a company can trust it with real work.

Most AI projects begin with a model demonstration. Someone uploads a document, asks a difficult question, and gets an answer quickly enough to change the room.

That moment is useful. It proves capability. It does not prove that the company has a production system.

A production system has to answer a different set of questions. What information can the model receive? Which tools can it use? What happens when it is uncertain? Who approves a consequential action? What is logged? What can be retained? What happens when a provider is unavailable?

The model is only one participant

At Workrr.ai, we primarily build with OpenAI. The reasoning, multimodal, tool-use, and engineering capabilities make it possible to address work that traditional automation could not handle well.

But a model should not quietly become the application, the security policy, the database, and the audit trail. Those are separate responsibilities.

We use Cloudflare as the production control plane around the AI capability. Depending on the project, that can include application compute, identity and access controls, AI Gateway, state, storage, queues, retrieval, rate limits, observability, and provider routing.

OpenAI supplies the capability. Cloudflare helps define and enforce the operating boundary. The business still owns the decision about what the system is allowed to do.

Privacy is not a yes-or-no feature

"Is this private?" sounds like a simple question. In practice, privacy is a chain of architectural decisions.

What data enters the workflow?
Where is it stored, and for how long?
Which provider is permitted to process it?
Can high-risk information be removed or transformed first?
Which actions require a person?
Can part of the work use private inference while deeper reasoning uses OpenAI only when approved?

That last question is why hybrid AI matters. A company does not have to choose one model and force every task through it. The system can route work according to capability, risk, latency, cost, and policy.

Start with one workflow that already hurts

The strongest starting point is rarely "we need an AI strategy." It is usually a workflow that repeats, crosses several systems, consumes meaningful labor, and still produces defects or delays.

We saw that while building Reclaira.ai for Paramount Billing Solutions, where collections and accounts-receivable work depends on context, prioritization, consistent communication, and human judgment. We saw it again with GlassMaster for 2U Glass & Tint, where operational knowledge, communications, business data, and execution had to become one usable system.

The industries were different. The architectural lesson was the same: useful AI has to operate inside the company's real constraints.

What a credible first deployment should prove

A first production deployment does not need to transform the entire company. It should prove a few things clearly:

The system reduces measurable friction.
Its outputs can be evaluated against real examples.
Its permissions and data path are understandable.
A person remains accountable where consequences require it.
The system creates evidence that improves the next version.

Once those foundations exist, expansion becomes an operating decision rather than a leap of faith.

The opportunity is larger than chat

Chat interfaces are useful, but the more important opportunity is operational memory: a system that can understand requests, retrieve context, use tools, coordinate actions, preserve evidence, and help the company learn from the history of its own work.

That is what we are building toward at Workrr.ai as an OpenAI Partner: OpenAI-led systems with a Cloudflare-native control plane and private or hybrid paths when the work requires a tighter boundary.

Originally published at workrr.ai.