DASP is developed in the open, with its specification, guide, and reference available on GitHub, where the project also solicits feedback and contributions.

What languages are supported?

There are native Elixir and TypeScript clients. Both are experimental and share the same wire contract and recovery rules. No production binding or host is released yet.

Do I need to provide my own infrastructure?

Yes. DASP defines the protocol — messages and recovery rules — while your application supplies the transport and storage.

How mature is the protocol?

It is a working review draft. The project is actively seeking feedback on GitHub and lists release preparation as ongoing, with experimental (not production) clients.

DASP — A shared contract for commands, saved outcomes, and recovery

DASP (Durable Actor Session Protocol) is an open, working-draft server protocol for durable actors. Clients connect through a DASP server to send commands and read outcomes that are saved independently of any connection: the server records command admission before replying, stores the final outcome (completed, failed, cancelled, or uncertain) separately, and retains an ordered update history so a client can disconnect and later resume from the last update it applied. Multiple clients — a web app, CLI, and service — can share the same actor session, each keeping its own position in the same ordered history.

Key Features

Five-operation client surface

Clients interact with an actor's saved record using five operations: session.open (open or return to a session), command submission (with a receipt), view.read (current saved state), updates.read (missed events), and outcome.read (a command's result).

Saved command admission

The server saves acceptance of a command before replying, returns an accepted receipt, and records the final outcome separately — so if effects cannot be established, the outcome is marked uncertain rather than lost.

Connection recovery with cursors

The server retains ordered updates when a connection ends. A returning client reads after the last update it applied, replaying only the missed portion of the history.

Shared sessions with per-client positions

A web app, command-line tool, and service can use the same actor session. The server checks access and serves the same ordered history, with each client tracking its own cursor position.

Transport- and storage-agnostic

The protocol defines a shared wire contract and recovery rules; your application supplies the transport and storage layers.

Native client libraries

Elixir and TypeScript clients are provided, both experimental and built on the same messages and recovery rules.

Actor-agnostic design

Aimed at workflow actors, device actors, and agent actors — any long-lived actor whose work must outlive client connections.

How It Works

Submit a command

The client sends a command with a stable ID (e.g., cmd-042) and keeps the ID and data for retries. The server saves admission first, then returns an accepted receipt.

Read outcomes and state

The client uses view.read for the current saved state, updates.read for missed events, and outcome.read to check a command's result (completed, failed, cancelled, or uncertain).

Reconnect and resume

After a disconnect, the client reconnects to the same record and reads updates after its last applied cursor, replaying only what it missed from the server's saved session history.

Pros & Cons

Pros

Explicit, well-defined semantics for retries, saved admission, and uncertain outcomes — an area most ad hoc designs get wrong
Connection recovery is built into the protocol with per-client cursors rather than bolted on
Shared sessions with a single ordered history across web, CLI, and service clients
Transport- and storage-agnostic: you choose how messages move and where state is persisted
Developed in the open with a public specification, guide, and reference on GitHub
Both Elixir and TypeScript clients follow the same wire contract, avoiding client fragmentation

Who It's For

Best for

Teams building actor-based systems (workflow, device, or agent actors) that need commands and outcomes to survive client disconnects
Developers who want a shared contract for retries, saved outcomes, and session recovery instead of designing one ad hoc
Environments where multiple client types — web apps, CLIs, and backend services — must observe the same actor history

Not ideal for

Teams needing a production-ready, batteries-included server or hosted service today — no production binding or host is released
Projects that need stable, versioned protocol guarantees right now — the spec is a working review draft

Use Cases

Workflow actors whose long-running work must continue even when the triggering client disconnects

Device actors that need to report saved outcomes to reconnecting clients

Agent actors where multiple clients (web app, CLI, service) share one session with a consistent ordered history

Systems that require explicit handling of uncertain outcomes when command effects cannot be established

FAQ

What does DASP actually do?

DASP is a server protocol for durable actors. Clients send commands and read outcomes that the server saves independently of the connection: admission is saved before a reply, final outcomes are stored separately, and ordered updates are retained so clients can reconnect and resume.

What happens if a client disconnects mid-command?

The server saves the command's admission before replying and records the final outcome separately. If effects cannot be established, the outcome is marked uncertain. On reconnect, the client reads updates after the last one it applied, replaying only the missed events.

What are the five client operations?

session.open (open or return to a session), command submission (request with an accepted receipt), view.read (current saved state), updates.read (missed events), and outcome.read (a command's result).

Can multiple clients share the same actor session?

DASP