What is new in the DRM3 SDK

@drm3/sdk is one package for putting an app or an agent on DRM3: sign-in, a shared credit balance, agent payments, signed data in and out, and provenance receipts, each behind its own small import. It is public on npm and the source is open. August brought four releases. Here is what they add.

npm install @drm3/sdk

Search the record

`@drm3/sdk/search` is the record's own search client. Ask it a question in words and it returns the facts that match by meaning as well as by keyword, the same search the newsroom's writers use. A free freshness probe beside it tells you how current the record is before you spend a read on it.

Meter any usage to the ledger

`@drm3/sdk/meter` carries `LedgerMeterClient`: charge any kind of usage to a user's DRM3 credits with your service key, a story, a scan, a seat, a call. It also carries the ledger engine itself, authorize, capture, void, settle, and a multi-bucket wallet, for a ledger you run on your own.

Your key stays with you

A partner's signing key is generated on the partner's machine and never leaves it. The `drm3` CLI writes it to the partner's home, `@drm3/sdk/keys/home` reads it from your own service, and DRM3 holds only the public half. You send a signing request that proves you hold the key, and DRM3 issues a certificate binding it to your name under the DRM3 root, published in the public key registry. We can verify your signatures. We can never sign as you.

Register your own tenant in the lake

With a certificate, a partner registers its own tenant at the lake's door, signed with the same key. An operator approves it. Approval creates your dataset and tables first and admits you second, so you are never pointed at a table that does not exist. From then on your signed rows land in your own namespace, and you read them back through the same signed door everyone uses.

A passport your users grant you

A user grants your app a Data Passport at the hub's consent screen. Your app then writes into its own namespace under that user's record, one key per provider, one grant per app. The user can see what is set, revoke a grant, export everything, or delete everything, and those last two always work. That is the promise the passport makes.

Read signed data, write signed data

`@drm3/sdk/extract` pulls records through the Data Extract API and `@drm3/sdk/ingest` writes rows back through the Ingest door, with no service account on either side. Every page you read arrives with a receipt and the SDK checks it before your code sees a row. Every batch you write returns a receipt the SDK verifies too, and since 0.3.1 the door's exact answer rides along verbatim, so you can keep it as your own record of what the door said.

A receipt proves that a known key signed the record and that it has not changed since. It does not prove the record describes the world correctly. Signing adds accountability you can check for yourself.

Why a person reviews partner access

You do not need approval to build. You need it for the data key, the inference wallet, and the certificate. A person reviews each application, because a partner program is a promise about stability and the people who would pay for the parts we got wrong are the earliest partners. So our own products run on these rails first: the same keys, the same metered doors, the same billing, on nothing but the credentials any customer gets. If one of ours cannot run that way, something is still special-cased and the program is not ready.

Install @drm3/sdk, read drm3.io/sdk, and see the partner path at drm3.io/partners.