Crate recall_wire 

The contract between Recall’s client and server: request and response shapes, and the validation rules that apply to both.

Keeping this in one crate is the point of a workspace rather than two programs. Before the implementations were unified, file_path validation and the tombstone/empty-file distinction existed twice — in JavaScript on the server and in bash on the client — with nothing keeping them in agreement, so a drift between them would only surface in production.

Layout

One module per endpoint, since that is the unit that has to stay compatible. Every type is also re-exported at the crate root, so callers can write recall_wire::PushRequest and never think about which endpoint a type belongs to.

Module	Endpoint
sync	POST /sync, GET /sync — memory files in both directions
health	GET /health — unauthenticated liveness and merge status
admin	GET /admin/stats — what is stored, per project
discovery	GET /.well-known/recall — what the server is and speaks
devices	/v1/devices, /v1/authkeys — enrolling and managing devices
jobs	/v1/jobs — the merge queue a worker drains
evaluations	/v1/evaluations — reports the worker makes on what memory holds
audit	/v1/audit/*: the log’s checkpoint, leaves and proofs, the tree they hash to, and checking an export offline
signature	not an endpoint: how a device signs every request
validate	the rules both halves enforce

Frozen surface

These JSON shapes are frozen. The deployed Node server speaks them, its SQLite rows were written against them, and during any migration a machine on the old client and one on the new binary talk to the same deployment. Field names and ordering here are compatibility surface, not style.

That includes timestamps, which every updated_at, checked_at and last_*_at field carries as JavaScript’s Date.toISOString() — millisecond precision with a Z suffix, e.g. 2026-09-03T21:49:55.191Z. Rows already in the database are in that shape. recall_server::now produces it.

The full reference, including status codes and worked curl examples, is in docs/reference/api.md.

Re-exports

pub use admin::AdminStats;

pub use admin::AdminTotals;

pub use admin::ProjectStats;

pub use audit::AuditCapability;

pub use audit::AuditCheckpoint;

pub use audit::AuditConsistencyResponse;

pub use audit::AuditEntriesResponse;

pub use devices::ApproveRequest;

pub use devices::Authkey;

pub use devices::AuthkeyCreated;

pub use devices::AuthkeyList;

pub use devices::AuthkeyRequest;

pub use devices::AuthkeyRevokeRequest;

pub use devices::DenyRequest;

pub use devices::DenyResponse;

pub use devices::Device;

pub use devices::DeviceIdentity;

pub use devices::DeviceList;

pub use devices::DevicesCapability;

pub use devices::EnrollApproved;

pub use devices::EnrollPending;

pub use devices::EnrollPollRequest;

pub use devices::EnrollPollResponse;

pub use devices::EnrollRequest;

pub use devices::PendingEnrollment;

pub use discovery::Discovery;

pub use discovery::DISCOVERY_PATH;

pub use discovery::PROTOCOL;

pub use discovery::PROTOCOL_HEADER;

pub use evaluations::Details;

pub use evaluations::Evaluation;

pub use evaluations::EvaluationCreated;

pub use evaluations::EvaluationList;

pub use evaluations::EvaluationRequest;

pub use evaluations::EvaluationSummary;

pub use evaluations::FileRef;

pub use evaluations::Finding;

pub use evaluations::FindingDetail;

pub use evaluations::Skipped;

pub use evaluations::SuggestedEdit;

pub use health::ClaudeCliStatus;

pub use health::Health;

pub use health::MergeError;

pub use health::MergeStatus;

pub use health::QueueStatus;

pub use health::WorkerStatus;

pub use jobs::ClaimRequest;

pub use jobs::ClaimResponse;

pub use jobs::ClaudeCliReport;

pub use jobs::EvaluateFile;

pub use jobs::EvaluateInput;

pub use jobs::EvaluateResult;

pub use jobs::Job;

pub use jobs::JobList;

pub use jobs::JobSummary;

pub use jobs::MergeInput;

pub use jobs::MergeResult;

pub use jobs::MergeSide;

pub use jobs::ResultRequest;

pub use jobs::ResultResponse;

pub use sync::File;

pub use sync::PushRequest;

pub use sync::PushResponse;

pub use sync::SyncResponse;

pub use validate::validate_base_sha256;

pub use validate::validate_file_path;

pub use validate::validate_project_key;

pub use validate::ValidationError;

pub use validate::MAX_FILE_PATH_BYTES;

pub use validate::MAX_PROJECT_KEY_BYTES;

Modules

admin

GET /admin/stats — what the owner is storing, per project.

audit

GET /v1/audit/checkpoint, GET /v1/audit/entries and GET /v1/audit/consistency — the Merkle tree over every authenticated action. See docs/design/part5-plan.md’s “PR 1: audit” for the design, and docs/reference/api.md for the authoritative shape of what shipped.

devices

Devices: how a machine enrols, and how the owner approves, lists and revokes machines and the keys cloud sessions enrol with.

discovery

What a server says about itself, and what a client says about itself.

evaluations

/v1/evaluations: reports on what memory holds, made by the worker.

health

GET /health — deliberately unauthenticated, so uptime tooling can poll it without holding the token.

jobs

/v1/jobs: the merge queue, and the worker that drains it.

signature

Signing a request, and checking one: RFC 9421 HTTP Message Signatures with Ed25519, over an RFC 9530 Content-Digest of the body.

sync

POST /sync and GET /sync — the endpoints that carry memory files.

validate

The rules both halves apply to a request, so neither can drift from the other.

Structs

ErrorResponse

Body returned for any non-2xx, on every endpoint.

Functions

content_sha256

The hash a push names its base by: SHA-256 of the file’s exact bytes, as lowercase hex.