Jido SDK author mikehostetler claims A2A, ACP, and Microsoft's chat-centred AHP all leave durable non-chat actor sessions uncovered and his draft DASP protocol fills that gap; adoption beyond its experimental Elixir/TypeScript clients would establish durable actor sessions as a standard agent-communication layer, while stagnation would confine it to a Jido-ecosystem extension.

Open article · Retrieved 2026-09-28T13:35:18.704068+00:00

DASP is a draft. Help us improve it.[Share feedback on GitHub ↗](https://github.com/DASP-Protocol/dasp/issues)[Skip to content](https://dasp-protocol.github.io/dasp/#VPContent)

[DASPDASPDASP](https://dasp-protocol.github.io/dasp/)

Search`K`

Appearance

# Durable Actor Session Protocol

A server protocol for durable actors.

The connection can end. The work can continue. Send commands, read saved outcomes, and return to the same actor session.

[Follow a command](https://dasp-protocol.github.io/dasp/guide/walkthrough.html) [Compare protocols](https://dasp-protocol.github.io/dasp/guide/comparisons.html)

Clients connect through a DASP server.

Web appCLIServiceDASP serverSessions · commands · historyWorkflowactorDeviceactorAgentactor

## How DASP works

Five operations connect your client to the actor’s saved record.

[Inspect the messages](https://dasp-protocol.github.io/dasp/guide/walkthrough.html)

Five client operations · short message names

| Purpose | Request | Reply |
| --- | --- | --- |
| Open or return to a session | `session.open` | `session.opened` |
| Ask the actor to do work | `command` | `receipt` |
| Read current saved state | `view.read` | `view` |
| Read missed events | `updates.read` | `updates` |
| Check a command's result | `outcome.read` | `outcome` |

Command admission

## Know what the server saved.

The server saves acceptance before replying. It records the final outcome separately. If effects cannot be established, the outcome is uncertain.

[Understand the messages](https://dasp-protocol.github.io/dasp/specification/messages.html)

From client intent to a saved outcome.

Stable command ID`cmd-042`

1. Client**Submit a command**Keep its ID and data for retries.
2. Server**Save admission**Then return an accepted receipt.
3. Server**Save the outcome**Completed · failed · cancelled · uncertain

Progress is temporary. The outcome is saved.

Resume after the last applied update.

Before disconnectAfter reconnectCursor: 2Read after 2DASP server · saved session history12345Applied through 2Replay 3–5

Connection recovery

## Reconnect to the same record.

The server retains ordered updates when a connection ends. A returning client reads after the last update it applied.

[Read the recovery rules](https://dasp-protocol.github.io/dasp/specification/recovery.html)

Shared sessions

## Many clients. One shared session.

A web app, command-line tool, and service can use the same actor session. The server checks access and gives each client the same ordered history.

[Understand shared sessions](https://dasp-protocol.github.io/dasp/specification/profiles-and-bindings.html#dasp-profile-003)

One history. A position for each client.

DASP serverOne actor session · saved updates12345Same order for every clientWeb appCursor: 5CLICursor: 3ServiceCursor: 4

## Common rules. Native clients.

Choose Elixir or TypeScript. Both use the same messages and recovery rules. Your application supplies transport and storage.

[Read the specification](https://dasp-protocol.github.io/dasp/specification/index.html)

[**Elixir**Native API · shared wire contractExperimental](https://dasp-protocol.github.io/dasp/build/elixir.html)[**TypeScript**Independent client · shared wire contractExperimental](https://dasp-protocol.github.io/dasp/build/typescript.html)

Experimental clients. No production binding or host is released.