@interop/did-cli 0.7.1 → 0.9.0

package/CHANGELOG.md

@@ -1,5 +1,135 @@
 # History
 
+## 0.9.0 - 2026-06-14
+
+### Added
+
+- Implement `did get <did>` (alias: `resolve`), which resolves a DID to its DID
+  document through `@interop/security-document-loader`'s document loader
+  (did:key offline, did:web fetched). A DID URL (a `did#fragment` key id)
+  dereferences straight to its verification method. Unlike `did show`, which
+  reads local storage, `did get` resolves live.
+- Add an `edv` command group with `encrypt` and `decrypt` subcommands
+  (Layer 1: raw JWE). `edv encrypt [file]` encrypts stdin or a file to one or
+  more X25519 recipients and emits a single flattened JWE (the `jwe` field of
+  an EDV Document) to stdout or an `-o` file (convention `*.jwe.json`);
+  `edv decrypt [file]` reverses it. Encryption is public-key (key-agreement)
+  only, via `@interop/minimal-cipher` with its default algorithm
+  (`ECDH-ES+A256KW` key wrap, `XC20P` content encryption). A recipient
+  (`-r/--recipient`, repeatable) is a raw X25519 `publicKeyMultibase`, a wallet
+  key fingerprint/handle, or a DID / DID URL (its `keyAgreement` key, typed
+  either `X25519KeyAgreementKey2020` or `Multikey`); `--recipient-file` reads a
+  key-document JSON. `--json` switches both commands
+  to object semantics. On decrypt, the secret key is given with `-k/--key` or
+  auto-selected from the wallet by matching a recipient `kid`; a non-recipient
+  key exits non-zero with a clear error. The full EDV Document envelope,
+  chunked streams, and HMAC-blinded indexing are deferred to Layer 2.
+- Add EDV Document support to `edv` (Layer 2, Phase 1). `edv encrypt --document`
+  wraps the JWE in a full EDV Document envelope `{ id, sequence, indexed, jwe }`
+  (convention `*.edvdoc.json`), encrypting the input as the document `content`
+  with an optional `--meta <json>` object alongside it (both encrypted inside the
+  `jwe`); `id` is a fresh identity-multihash multibase value and `sequence`
+  starts at `0`, byte-faithful to `@interop/edv-client`'s `EdvClientCore` without
+  taking that dependency. `--update <file>` versions an existing document
+  (reusing its `id`, incrementing `sequence`, and merging its recipients).
+  `edv decrypt` detects an envelope automatically and emits its decrypted
+  `content` (reporting `meta`/`stream` on stderr); `--document` requires one.
+  Chunked streams and HMAC-blinded indexing remain deferred to later phases.
+- Add chunked-stream support to `edv` (Layer 2, Phase 2). `edv encrypt --stream`
+  encrypts the input as a sequence of fixed-size chunks (`--chunk-size <bytes>`,
+  default 1 MiB) and writes a bundle directory (convention `*.edvdoc/`, so `-o`
+  is required): a `document.json` EDV Document carrying a cleartext
+  `stream: { sequence, chunks }` descriptor, plus one `chunks/<index>.jwe.json`
+  per chunk (`{ sequence, index, offset, jwe }`), mirroring how an EDV / WAS
+  server stores stream bytes separately from the document. `--meta` and
+  `--update` (a file or bundle) work as for `--document`. `edv decrypt`
+  recognizes a bundle directory, reassembles the chunks in order, and writes the
+  original bytes to `-o`/stdout (reporting `content`/`meta`/`stream` on stderr).
+  HMAC-blinded indexing remains deferred to Layer 2, Phase 3.
+- Add HMAC-blinded indexing to `edv` (Layer 2, Phase 3). In
+  `--document`/`--stream` mode, `--index <attribute>` (repeatable; a dotted path
+  into `content`/`meta`) populates the envelope's `indexed` array with entries
+  whose attribute names and values are HMAC-blinded, so a document is searchable
+  the way an EDV / WAS server indexes it without the server learning the
+  cleartext. `--unique` marks every `--index` attribute unique; `--hmac <ref>`
+  selects the blinding key (auto-selected when the wallet holds exactly one). The
+  same key over the same value yields a stable blinded entry, matchable across
+  documents. The EDV Document envelope and its blinded `indexed` array are now
+  assembled and unwrapped by `@interop/edv-client`'s `EdvClientCore` (a new
+  dependency), converging on the reference implementation rather than the
+  hand-rolled envelope used in Phases 1-2.
+- Add `key create --type hmac`, generating a `Sha256HmacKey2019` HMAC key (a
+  32-byte symmetric secret used to blind EDV index attributes) via
+  `@interop/data-integrity-core`'s `SHA256HMACKey`. The key has no public half;
+  it is serialized with its secret as an `oct` JWK and identified by a random
+  `urn:uuid:` id. HMAC keys list with an `hmac` type label, and `key show`
+  prints only their `id`/`type` (never the secret). Like ecdsa/x25519, HMAC
+  generation is non-deterministic, so `--with-seed` / `SECRET_KEY_SEED` are not
+  supported.
+
+## 0.8.0 - 2026-06-13
+
+### Added
+
+- Add `key create --type x25519` support, generating an
+  `X25519KeyAgreementKey2020` (Curve25519 Diffie-Hellman) key pair via
+  `@interop/x25519-key-agreement-key`. Saved x25519 keys list with an `x25519`
+  type label and `key show` re-exports the public key only. Like ecdsa, x25519
+  generation is non-deterministic, so `--with-seed` / `SECRET_KEY_SEED` are not
+  supported.
+- Add `did add-key --type x25519` support for `did:web`, adding an
+  `X25519KeyAgreementKey2020` to the DID document. Because x25519 keys are key
+  agreement (encryption) keys, they are wired into the `keyAgreement`
+  verification relationship only; a `--purpose` other than `keyAgreement` is
+  rejected, and (as with ecdsa) `--with-seed` is not supported.
+- Add `was resource-meta get` and `was resource-meta put` (group alias
+  `meta`), surfacing the Resource Metadata endpoint (`GET`/`PUT .../meta`).
+  `get` prints the whole metadata object (server-managed `contentType`,
+  `size`, and timestamps plus the user-writable `custom` name/tags); a
+  missing/not-visible resource is reported as not-found. `put` updates
+  `custom`: `--name` and `--tag key=value` (repeatable) are non-destructive on
+  their own (they preserve the other field via the client's `setName` /
+  `setTags`), while passing both, or the `--json` escape hatch (inline JSON or
+  a file path), is a full `custom` replacement. Both verbs also accept
+  `--capability` targeting the resource.
+- Add `was collection backend` and `was collection quota`, surfacing the
+  `GET /space/:spaceId/:collectionId/backend` and
+  `GET /space/:spaceId/:collectionId/quota` endpoints (the storage backend a
+  collection is stored on, and the collection's storage usage scoped to that
+  backend). Both render a table by default and take `--json` for the raw
+  response; a missing/not-visible collection is reported as not-found, and a
+  server (or backend) that does not implement the endpoint (a 501) as an error.
+- Add `was space backends` and `was space quotas`, surfacing the
+  `GET /space/:spaceId/backends` and `GET /space/:spaceId/quotas` endpoints
+  (the storage backends available within a space, and the space's storage
+  report grouped by backend). Both render a table by default and take `--json`
+  for the raw response; a server that does not implement the endpoint (a 501)
+  is reported as an error.
+- Add `ARCHITECTURE.md`, a codebase map (entry point, command-factory pattern,
+  module layout, and the command surface) for contributors, linked from
+  `CLAUDE.md` and the README.
+- Add `CONTRIBUTING.md` as the canonical home for code-style and contribution
+  conventions (moved out of `CLAUDE.md`, which now imports it).
+- Add `AGENTS.md` (an inline copy of `CONTRIBUTING.md`) so non-Claude coding
+  agents pick up the same project guidance.
+- Add an Environment Variables table to the README consolidating `WALLET_DIR`,
+  `DIDS_DIR`, `SECRET_KEY_SEED`, `WAS_DID`, `WAS_SERVER_URL`, and
+  `ZCAP_CONTROLLER_KEY_SEED`.
+
+### Changed
+
+- `zcap delegate --capability` now also accepts the id or metadata handle of
+  a zcap saved in local wallet storage, in addition to a multibase string or
+  a JSON file path (the same resolution the `was` commands' `--capability`
+  flag uses; the shared resolver lives in `src/zcap/resolve.ts`).
+- Split the `was` command module into `src/commands/was/` submodules (by noun:
+  `space`, `collection`, `resource`, `tree`, `policy`, `publish`, plus shared
+  helpers); `src/commands/was.ts` now holds only `makeWasCommand()`. Internal
+  refactor with no behavior change.
+- Rename the `was resource list` positional from `<path>` to `<collection>`,
+  matching the sibling `was collection list <space>` and clarifying that the
+  argument is the parent collection being enumerated.
+
 ## 0.7.0-0.7.1 - 2026-06-11
 
 ### Changed

package/README.md

@@ -26,6 +26,21 @@ Help is available with the `--help/-h` command line option:
 ./di COMMAND -h
 ```
 
+### Environment Variables
+
+These environment variables configure storage locations and provide defaults
+or secret-key seeds for individual commands. Each is also documented inline in
+the relevant command section below.
+
+| Variable | Used by | Purpose |
+| --- | --- | --- |
+| `WALLET_DIR` | all | Wallet collections directory (`keys/`, `zcaps/`, `credentials/`, `was-spaces/`). Defaults to `~/.config/did-cli-wallet/` (honors `XDG_CONFIG_HOME`). |
+| `DIDS_DIR` | `did` | DID-documents directory. Defaults to `<WALLET_DIR>/dids/`. |
+| `SECRET_KEY_SEED` | `key create`, `did create` | Multibase-encoded seed for deterministic key/DID generation. Not supported with `--type ecdsa` or `--type x25519`. |
+| `WAS_DID` | `was` | Default signing DID (or stored-DID handle) when `--did` is omitted. |
+| `WAS_SERVER_URL` | `was` | Default WAS server base URL when `--server` is omitted. |
+| `ZCAP_CONTROLLER_KEY_SEED` | `zcap` | Controller signing-key seed for delegating capabilities. |
+
 ### Key Management
 
 #### Create a key pair
@@ -66,7 +81,7 @@ SECRET_KEY_SEED=z1AXVyT6G1Qk3E9cMPkDYY6wVRpZjVGWAZ3TfrAgFZkX6bv ./di key create
 ```
 
 Specify an explicit key type with `--type` (defaults to `ed25519`; supported:
-`ed25519`, `ecdsa`):
+`ed25519`, `ecdsa`, `x25519`, `hmac`):
 
 ```
 SECRET_KEY_SEED=z1Aaj5A4UCsd... ./di key create --type ed25519
@@ -96,6 +111,49 @@ ECDSA keys are serialized as Multikey, the same as Ed25519. Note that ECDSA key
 generation is non-deterministic (it cannot be derived from a seed), so
 `--with-seed` and `SECRET_KEY_SEED` are not supported with `--type ecdsa`.
 
+Generate an X25519 (Curve25519) key agreement key -- for Diffie-Hellman key
+exchange / encryption, not signing -- with `--type x25519`:
+
+```
+./di key create --type x25519
+```
+
+It is serialized as an `X25519KeyAgreementKey2020` document with the public and
+private key in multibase encoding:
+
+```json
+{
+  "type": "X25519KeyAgreementKey2020",
+  "publicKeyMultibase": "z6LS...",
+  "privateKeyMultibase": "z3we..."
+}
+```
+
+Like ECDSA, X25519 key generation is non-deterministic, so `--with-seed` and
+`SECRET_KEY_SEED` are not supported with `--type x25519`.
+
+Generate a `Sha256HmacKey2019` HMAC key -- a 32-byte symmetric secret used to
+HMAC-blind EDV index attributes (see [Blinded indexing](#blinded-indexing---index))
+-- with `--type hmac`:
+
+```
+./di key create --type hmac
+```
+
+It is serialized with the secret carried as an `oct` JWK (it has no public
+half), identified by a random `urn:uuid:` id:
+
+```json
+{
+  "id": "urn:uuid:...",
+  "type": "Sha256HmacKey2019",
+  "secretKeyJwk": { "kty": "oct", "alg": "HS256", "k": "..." }
+}
+```
+
+HMAC key generation is non-deterministic, so `--with-seed` and `SECRET_KEY_SEED`
+are not supported with `--type hmac`.
+
 Save the key to local wallet storage (`~/.config/did-cli-wallet/keys/` by default, or
 `$WALLET_DIR/keys/` if set) with `--save`. A `.meta.json` metadata sidecar is
 written next to the key, recording the creation timestamp; `--handle` (a short
@@ -376,10 +434,20 @@ By default the new key is Ed25519; pass `--type ecdsa` (with an optional
 ./di did add-key did:web:example.com --type ecdsa --curve p384
 ```
 
+Pass `--type x25519` to add an X25519 (Curve25519) key agreement key. X25519
+keys are encryption/key-exchange keys, not signing keys, so they are wired into
+the `keyAgreement` relationship only -- a `--purpose` other than `keyAgreement`
+is rejected:
+
+```
+./di did add-key did:web:example.com --type x25519
+```
+
 For Ed25519 keys, the new key is derived from a seed (as with `did create`):
 pass `--with-seed` to generate (and print) a fresh seed, or set `SECRET_KEY_SEED`
-to derive the key deterministically. ECDSA keys are not seed-derivable, so
-`--with-seed` is not supported with `--type ecdsa`:
+to derive the key deterministically. ECDSA and X25519 keys are not
+seed-derivable, so `--with-seed` is not supported with `--type ecdsa` or
+`--type x25519`:
 
 ```
 ./di did add-key did:web:example.com --with-seed
@@ -420,6 +488,33 @@ did:key:z6Mkr...
 did:key:z6Mks...
 ```
 
+#### Resolve a DID
+
+Resolve a DID to its DID document through the security document loader. Unlike
+`did show` (which reads local storage), `did get` resolves live: did:key is
+resolved offline, did:web is fetched over HTTPS. Pass a DID URL (a
+`did#fragment` key id) to dereference straight to its verification method:
+
+```
+./di did get did:key:z6Mkr...
+{
+  "@context": [ ... ],
+  "id": "did:key:z6Mkr...",
+  "verificationMethod": [ ... ],
+  ...
+}
+
+./di did get did:key:z6Mkr...#z6Mkr...
+{
+  "id": "did:key:z6Mkr...#z6Mkr...",
+  "type": "Ed25519VerificationKey2020",
+  "controller": "did:key:z6Mkr...",
+  "publicKeyMultibase": "z6Mkr..."
+}
+```
+
+Alias: `resolve`.
+
 #### Show a DID
 
 Display the DID document saved in local storage (via `did create --save`),
@@ -834,8 +929,9 @@ ZCAP_CONTROLLER_KEY_SEED=z1AZK4h5w5YZkKYEgqtcFfvSbWQ3tZ3ZFgmLsXMZsTVoeK7 \
 ```
 
 To delegate an _existing_ capability further down the chain, pass it as
-`--capability` instead of `--url` -- either the `encoded` string from a previous
-delegation or a path to a JSON file containing the capability. Use
+`--capability` instead of `--url` -- the `encoded` string from a previous
+delegation, a path to a JSON file containing the capability, or the id or
+metadata handle of a zcap saved in local wallet storage. Use
 `--invocation-target` to attenuate (narrow) the parent's target to a sub-path:
 
 ```
@@ -1057,6 +1153,24 @@ delete pair:
   server** (idempotent) and removes the registry entry;
 - `was space forget <space>` removes only the local registry entry.
 
+`was space backends` lists the storage backends available within a space, and
+`was space quotas` shows the space's storage report grouped by backend (usage,
+limit, and any restricted actions). Both render a table by default and take
+`--json` for the raw response:
+
+```
+./di was space backends home
+ID       NAME        MANAGED BY  STORAGE MODE     PERSISTENCE
+default  Filesystem  server      document, blob   durable
+
+./di was space quotas home
+BACKEND             STATE  USAGE (B)  LIMIT (B)  RESTRICTED
+default (Filesystem) ok    2048       1048576
+```
+
+A server that does not implement these endpoints (a 501) is reported as an
+error.
+
 #### Manage collections
 
 The `collection` group (alias: `coll`) manages collections within a space.
@@ -1081,6 +1195,37 @@ credentials  Credentials  http://localhost:3002/space/8124...cf2e/credentials
 Deleted http://localhost:3002/space/8124...cf2e/credentials on the server.
 ```
 
+`was collection backend` shows the storage backend a collection is stored on,
+and `was collection quota` shows the collection's storage usage scoped to that
+backend (state, usage, limit, and any restricted actions). Both render a table
+by default and take `--json` for the raw response:
+
+```
+./di was collection backend home/credentials
+FIELD         VALUE
+------------  --------------
+ID            default
+Name          Filesystem
+Managed By    server
+Storage Mode  document, blob
+Persistence   durable
+
+./di was collection quota home/credentials
+FIELD        VALUE
+-----------  --------------------
+Backend      default (Filesystem)
+Managed By   server
+State        ok
+Usage (B)    2048
+Limit (B)    1048576
+Restricted
+Measured At  2026-06-13T00:00:00Z
+```
+
+A missing or not-visible collection is reported as not-found; a server (or
+backend) that does not implement these endpoints (a 501) is reported as an
+error.
+
 #### Add and read resources
 
 The `resource` group (alias: `res`) manages the content itself. Payloads come
@@ -1121,6 +1266,40 @@ files); a missing or not-visible resource prints
 `list` renders the resources of a collection (`ID | CONTENT TYPE | URL`), and
 `delete` (alias: `rm`) removes one (idempotent).
 
+#### Resource metadata (name and tags)
+
+The `resource-meta` group (alias: `meta`) reads and updates a resource's
+metadata. `get` prints the whole metadata object -- the server-managed
+`contentType`, `size`, and timestamps plus the user-writable `custom` (its
+`name` and `tags`):
+
+```
+./di was resource-meta get home/credentials/vc-1
+```
+
+`put` updates the user-writable `custom`. `--name` sets the display name shown
+in collection listings and `--tag key=value` (repeatable) sets annotations;
+used on their own each is non-destructive -- `--name` preserves existing tags
+and `--tag` preserves the existing name:
+
+```
+./di was resource-meta put home/credentials/vc-1 --name 'Diploma'
+./di was resource-meta put home/credentials/vc-1 --tag year=2026 --tag status=verified
+```
+
+Giving both `--name` and `--tag` together replaces `custom` wholesale (any
+field you do not pass is cleared). The `--json` escape hatch takes the full
+`custom` object as inline JSON or a JSON file path, for the same full
+replacement (pass `--json '{}'` to clear everything):
+
+```
+./di was resource-meta put home/credentials/vc-1 \
+  --json '{"name":"Diploma","tags":{"year":"2026"}}'
+./di was resource-meta put home/credentials/vc-1 --json custom.json
+```
+
+After a successful update the command prints the resulting metadata.
+
 #### Shorthand verbs
 
 For day-to-day use, the top-level verbs dispatch on the path depth:
@@ -1298,9 +1477,159 @@ unless `WAS_TEST_SERVER_URL` points at a running server:
 WAS_TEST_SERVER_URL=http://localhost:3002 npm run test:node
 ```
 
+### Encrypted Data (EDV)
+
+The `edv` commands encrypt an object or file to one or more X25519 recipients
+and decrypt the result, using the EDV / [minimal-cipher](https://www.npmjs.com/package/@interop/minimal-cipher)
+serialization. The output is a single raw **JWE** (the `jwe` field of an EDV
+Document), written to stdout or an `-o` file -- by convention `*.jwe.json`.
+Encryption is public-key (key-agreement) only: there is no password mode. The
+algorithm is the library default, `ECDH-ES+A256KW` key wrap with `XC20P`
+(XChaCha20Poly1305) content encryption.
+
+#### Encrypt
+
+A recipient (`-r/--recipient`, repeatable, at least one required) is an X25519
+public key given as a raw `publicKeyMultibase` (starts `z6LS`), a wallet key
+fingerprint or handle, or a DID / DID URL (the DID's `keyAgreement` key; a DID
+with several keyAgreement keys needs the `did#fragment` form). A
+`--recipient-file <path>` is a key-document JSON file holding an X25519 public
+key.
+
+Encrypt a JSON object (with `--json`, the input is parsed and encrypted as an
+object) to a stored x25519 key:
+
+```
+./di key create --type x25519 --save --handle alice-kak
+echo '{"hello": "world"}' | ./di edv encrypt --json -r alice-kak -o secret.jwe.json
+```
+
+Without `--json` the raw input bytes are encrypted. Encrypt to several
+recipients by repeating `-r`:
+
+```
+./di edv encrypt photo.png -r alice-kak -r z6LSr... -o photo.jwe.json
+```
+
+#### Decrypt
+
+`-k/--key` is the X25519 secret key (fingerprint or handle) to decrypt with;
+when omitted, the matching stored key is auto-selected from the wallet. Use
+`--json` to pretty-print the decrypted object, and `-o` to write to a file.
+Only plaintext is ever written; secret key material stays in the key store.
+
+```
+./di edv decrypt secret.jwe.json --json
+{
+  "hello": "world"
+}
+
+./di edv decrypt photo.jwe.json -k alice-kak -o photo.png
+```
+
+Decryption with a key that is not a recipient exits non-zero with a clear
+error rather than emitting garbage.
+
+#### EDV Documents (`--document`)
+
+By default `edv encrypt` emits a bare JWE. With `-d/--document` it wraps that JWE
+in a full **EDV Document** envelope -- `{ id, sequence, indexed, jwe }`, the
+shape an EDV / WAS server stores -- written by convention to `*.edvdoc.json`. The
+input is encrypted as the document's `content`; an optional `--meta <json>`
+object is encrypted alongside it (both live inside the `jwe`, so only `id`,
+`sequence`, and `indexed` stay in cleartext). The `id` is a fresh
+identity-multihash multibase value and `sequence` starts at `0`. Index entries
+(`indexed`) are always `[]` for now; HMAC-blinded indexing and chunked streams
+are later phases.
+
+```
+echo '{"name": "alice"}' | \
+  ./di edv encrypt --document -r alice-kak --meta '{"tag":"demo"}' -o doc.edvdoc.json
+```
+
+`--update <file>` versions an existing document: it reuses that document's `id`,
+increments its `sequence`, and merges its recipients (so you can add a recipient
+without re-listing the existing ones) before re-encrypting the new content.
+
+```
+echo '{"name": "alice", "v": 2}' | \
+  ./di edv encrypt --document -r bob-kak --update doc.edvdoc.json -o doc.v2.edvdoc.json
+```
+
+`edv decrypt` detects an EDV Document automatically and prints its decrypted
+`content` (any `meta`/`stream` is reported on stderr); pass `-d/--document` to
+require an envelope and reject a bare JWE.
+
+```
+./di edv decrypt doc.edvdoc.json
+{
+  "name": "alice"
+}
+```
+
+#### Chunked streams (`--stream`)
+
+For large inputs, `-s/--stream` encrypts the bytes as a sequence of fixed-size
+chunks rather than one JWE. The output is a **bundle directory** (convention
+`*.edvdoc/`, so `-o` is required) holding `document.json` -- an EDV Document whose
+cleartext `stream: { sequence, chunks }` descriptor records the chunk count -- and
+one `chunks/<index>.jwe.json` per chunk. This mirrors how an EDV / WAS server
+stores stream bytes as resources separate from the document. `--chunk-size
+<bytes>` sets the chunk size (default 1 MiB); `--meta` and `--update` work as for
+`--document`.
+
+```
+./di edv encrypt photo.png --stream -r alice-kak --chunk-size 1048576 -o photo.edvdoc/
+```
+
+`edv decrypt` recognizes a bundle directory, reassembles the chunks in order, and
+writes the original bytes to `-o`/stdout (the document's `content`/`meta`/`stream`
+are reported on stderr).
+
+```
+./di edv decrypt photo.edvdoc/ -o photo.png
+```
+
+#### Blinded indexing (`--index`)
+
+In `--document`/`--stream` mode, `--index <attribute>` populates the envelope's
+`indexed` array so a document is searchable the way an EDV / WAS server indexes
+it -- without the server learning the cleartext. The attribute name and value
+are **HMAC-blinded**: a `Sha256HmacKey2019` key signs them, so the same key over
+the same value always yields the same opaque entry (matchable across documents),
+but the cleartext never leaves the client.
+
+First create an HMAC key in the wallet (a 32-byte secret, no public half):
+
+```
+./di key create --type hmac --save --handle vault-index
+```
+
+Then declare one or more indexable attribute paths (dotted paths into `content`
+or `meta`). The HMAC key is auto-selected when the wallet holds exactly one;
+otherwise pass `--hmac <id|handle>`. `--unique` marks every `--index` attribute
+as unique.
+
+```
+echo '{"type":"Person","name":"alice"}' | \
+  ./di edv encrypt --document --json -r alice-kak \
+    --index content.type --index content.name --hmac vault-index -o doc.edvdoc.json
+```
+
+The resulting envelope carries `indexed: [{ hmac: { id, type }, sequence,
+attributes: [{ name, value, unique? }] }]`, where each `name`/`value` is the
+blinded (opaque) form. The envelope and its blinded entries are assembled by
+[`@interop/edv-client`](https://www.npmjs.com/package/@interop/edv-client)'s
+`EdvClientCore`, so they match what an EDV server expects byte-for-byte.
+
 ## Contribute
 
-PRs accepted.
+PRs accepted. Please follow the code-style and contribution conventions in
+[CONTRIBUTING.md](CONTRIBUTING.md).
+
+For a map of the codebase -- the module layout, the command-factory pattern,
+and the build/test commands -- see [ARCHITECTURE.md](ARCHITECTURE.md). Storage
+layout is documented in [STORAGE.md](STORAGE.md).
 
 If editing the Readme, please conform to the
 [standard-readme](https://github.com/RichardLitt/standard-readme) specification.

package/dist/commands/did.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"did.d.ts","sourceRoot":"","sources":["../../src/commands/did.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAA;AA+EnC,wBAAgB,cAAc,IAAI,OAAO,CAurBxC"}
+{"version":3,"file":"did.d.ts","sourceRoot":"","sources":["../../src/commands/did.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAA;AA0FnC,wBAAgB,cAAc,IAAI,OAAO,CA0uBxC"}