@tokono.ma/resource-bearer #

Browser-first TypeScript SDK for the Resource Bearer API.

• keys.ts — ed25519 identities (@noble/ed25519); the seed is the account; DID derivation (did:key:z…).
• cid.ts — DASL/BDASL CID computation (SHA-256 or BLAKE3, canonical base32-lower).
• ucan.ts — UCAN 1.0 invocation + delegation minting as DAG-CBOR container tokens ([invocation, ...proofs]), byte-identical to the server's Rust implementation (rs-ucan).
• client.ts — ResourceBearer: upload/get/getRange/claim/delete/register/ dagPush/dagPull over plain fetch, CARv1 framing included.

Minting is a shim, on purpose #

ucan.ts implements only the wire assembly (~150 lines); all crypto and encoding is library code (@noble/ed25519, @ipld/dag-cbor). Correctness is pinned by golden tests (test/ucan.test.ts): fixture tokens from the Rust reference client decode + re-encode byte-identically, and live tokens are accepted by the real server (run inside the integration suite).

The iso-ucan question #

iso-ucan is the richer TS library (zod-typed capabilities, proof storage, replay + revocation, an RPC layer) implementing the same UCAN 1.0 spec family — but it mints final 1.0.0 wire format: it renames arg → args, omits aud/cause/iat/meta when implicit, and tags ucan/inv@1.0.0. The server (pinned rs-ucan, rc.1) rejects those today. When rs-ucan lands final 1.0.0 support, swap ucan.ts's three mint functions for iso-ucan behind the SDK's existing TokenSource interface — no other layer changes.

Also worth adopting from iso-ucan later: its replay key (CID of the signed payload, not the whole envelope) matters if ECDSA DIDs are ever supported — ed25519 signatures are deterministic, so our token-hash key is equivalent today.