Skip to content

memrust v0.6.0 — namespaces and API keys

Choose a tag to compare

@AIAnytime AIAnytime released this 28 Jul 07:49

The two things that stood between "interesting project" and "something I can deploy".

Namespaces

Every request selects a store with the X-Memrust-Namespace header. A namespace is a separate engine — its own indexes, WAL, checkpoint, embedding dimension and directory — not a filter over a shared index. So one tenant's ingest can't slow another's recall, two tenants can use different embedding models, and dropping a namespace deletes a directory instead of scanning a shared index.

Namespaces are created on first use and reopened from disk at startup. GET /v1/namespaces and POST /v1/namespaces/drop administer them.

API keys

# unauthenticated — fine on loopback, and the server says so at startup
memrust serve

# require keys, and scope them
memrust serve --api-key "$ADMIN_KEY" --api-key "$TENANT_KEY:acme,acme-staging"

Keys arrive as Authorization: Bearer <key> or X-API-Key. An unscoped key gets everything including admin routes; a scoped key is confined to its namespaces. Comparison is constant-time. When the server is unauthenticated and bound to a non-loopback address, it warns — the failure mode worth preventing is binding 0.0.0.0 without realizing every memory is public.

Verified over real HTTP: 401 without a key, 401 with a wrong one, 200 for a scoped key on its own namespace, 403 on another's, 403 on admin routes with a scoped key.

Upgrading is safe

A data directory written before namespaces existed is adopted as the default namespace in place. Tested by writing memories with the published v0.5.4 binary, reopening the directory with this build, and recalling them — plus a regression test. Namespace names are validated before they become path segments, so .. and / are rejected.

cargo install memrust
pip install --upgrade memrust
npm install memrust-client