@noy-db/hub 0.6.0-pre.20 → 0.6.0-pre.22

package/dist/with-party/team/keyring.d.ts

@@ -1,5 +1,6 @@
 import type { NoydbStore, KeyringFile, KeyringAuthenticator, Role, Permissions, GrantOptions, RevokeOptions, UpdateUserOptions, UserInfo, EncryptedEnvelope, ExportCapability, ExportFormat, ImportCapability, VaultPolicyOnDisk, UserEnvelope } from '../../kernel/types.js';
 import { type EnclaveKey, type EchoSecretParts } from '../../kernel/enclave/index.js';
+import type { KeyringTamperedReason } from '../../kernel/errors.js';
 import { type SecretPolicy, type EchoSecretPolicy } from '../../kernel/validation.js';
 import type { DeviceSealProvider } from './device-seal.js';
 /** In-memory representation of an unlocked keyring. */
@@ -77,6 +78,23 @@ export interface UnlockedKeyring {
 }
 /** Mint a fresh wrapped-canary string. Deterministic for a given KEK. */
 export declare function mintKeyringCanary(kek: EnclaveKey): Promise<string>;
+/**
+ * The vault roster key held by this keyring, or `null` when the keyring
+ * carries none.
+ *
+ * Null is expected on the resume-style paths (`kek: null` sessions, tier-3
+ * PIN resume, plaintext mode) — none of which may write a keyring file.
+ * Every stamping site null-guards this exactly as it guards `kek`: minting a
+ * file without a verifiable `roster_tag` would be worse than refusing, since
+ * it is indistinguishable on the next load from a store having stripped it.
+ */
+export declare function rosterKeyOf(keyring: UnlockedKeyring): EnclaveKey | null;
+/**
+ * Shared wording for the stamping-site guards — mirrors the `kek` guard's shape.
+ * Exported so every roster-stamping site in the hub raises ONE error with one
+ * wording, rather than each hand-copying it (`peer-recover`, `liberate`).
+ */
+export declare function requireRosterKey(keyring: UnlockedKeyring, fn: string): EnclaveKey;
 /** Options for {@link loadKeyring} (#846b). */
 export interface LoadKeyringOptions {
     /** The user whose keyring to unlock. */
@@ -173,6 +191,100 @@ export declare function createOwnerKeyring(store: NoydbStore, vault: string, opt
 export declare function grant(store: NoydbStore, vault: string, callerKeyring: UnlockedKeyring, options: GrantOptions): Promise<void>;
 /** Revoke a user's access. Optionally rotate keys for affected collections. */
 export declare function revoke(store: NoydbStore, vault: string, callerKeyring: UnlockedKeyring, options: RevokeOptions): Promise<void>;
+/** What {@link verifyRoster} found. */
+export interface RosterVerifyResult {
+    /**
+     * How many `_keyring` files were examined.
+     *
+     * Reported first, and deliberately: "nothing unverified" is equally true of a
+     * sweep that examined nothing, and a roster check that silently covered zero
+     * members would look identical to a healthy vault. Same lesson as the vault
+     * head's `no-expectations` verdict (#1101).
+     */
+    readonly checked: number;
+    /** The files that failed authentication, and why. */
+    readonly unverified: ReadonlyArray<{
+        readonly userId: string;
+        readonly reason: KeyringTamperedReason;
+    }>;
+}
+export declare function verifyRoster(store: NoydbStore, vault: string, callerKeyring: UnlockedKeyring): Promise<RosterVerifyResult>;
+/** What {@link quarantineKeyring} did. */
+export interface QuarantineResult {
+    readonly userId: string;
+    /** Why the file could not be authenticated — the justification for removing it. */
+    readonly reason: KeyringTamperedReason;
+    /** Collections re-keyed as part of the removal. */
+    readonly rotated: readonly string[];
+    /**
+     * (member, collection) pairs whose access the rotation dropped — the OTHER
+     * members, who must be re-granted.
+     *
+     * Passed through from `rotateKeys` rather than discarded, because a
+     * quarantine rotates broadly (see the scope note on the function) and so
+     * de-provisions more people than the one being removed. An operator who is
+     * not told this discovers it as unrelated `NoAccessError`s later.
+     */
+    readonly needsRegrant: RotateResult['needsRegrant'];
+    /**
+     * OTHER members whose own files also failed authentication, found while
+     * rotating. One forged file is rarely the only one, and the operator is
+     * already holding the tool for them.
+     */
+    readonly alsoUnverified: RotateResult['unverified'];
+}
+/**
+ * Remove a `_keyring` file that cannot be authenticated, and re-key behind it
+ * (#1121).
+ *
+ * ## Why this is not a flag on `revoke`
+ *
+ * `revoke` reads the target's own `role` to decide whether the caller may
+ * revoke them, so it cannot act on a file it will not trust — which left a
+ * forged file removable only by editing the store by hand. Relaxing `revoke`
+ * conditionally would grow the safe path a parameter that turns it into the
+ * dangerous one; ADR 0003's standing rule is that if the implementation needs
+ * to weaken a guard, the design is wrong. This is a separate operation with its
+ * own contract, so `revoke`'s invariant stays absolute and the dangerous act is
+ * named at the call site rather than hidden in an option bag.
+ *
+ * ## The two properties that keep it from being a backdoor
+ *
+ * 1. **It refuses a file that verifies.** Otherwise it would delete any keyring
+ *    while ignoring `canRevoke` — including an owner's, which `revoke` protects
+ *    unconditionally.
+ * 2. **Because of (1) it can safely ignore the claimed `role` — and it must.**
+ *    `canRevoke` refuses any target whose role reads `owner`, so a store that
+ *    forged `"role":"owner"` onto its victim would otherwise make them
+ *    permanently unremovable. Consulting the forged field is exactly the
+ *    mistake this operation exists to avoid.
+ *
+ * Owner-only: the narrowest role that can always act, and quarantine
+ * deliberately consumes NO field of the file it is removing.
+ *
+ * ## Why it rotates, and why the scope comes from the CALLER
+ *
+ * Deleting the file is not a revocation — the store may decline the delete, and
+ * the member may already hold unwrapped DEKs. So this rotates, exactly as
+ * `revoke` does. The scope is every collection the CALLER holds, not the
+ * target's DEK map: that map is unauthenticated (#1115), so deriving the scope
+ * from it would let the store choose which collections survive a quarantine.
+ *
+ * ⚠️ **That is the security-correct scope, and it is NOT free.** An earlier
+ * draft of this comment called over-rotating "the safe direction"; a review
+ * probe disproved it. Rotation re-keys `store.list(vault, <name>)` plus the
+ * derived refs `rotateKeys` knows about, so a DEK slot whose ciphertext lives
+ * under a *different* collection name — `_blob`, whose data sits in
+ * `_blob_index`/`_blob_chunks`, and the `collection#tier` slots — is re-keyed
+ * without its data being re-encrypted, and that data then fails to open. That
+ * gap belongs to `rotateKeys` (it is reachable through an ordinary `revoke` of
+ * a whole-vault grantee, with no quarantine involved) and is filed as #1122,
+ * but a quarantine takes the maximal scope *unconditionally*, so it meets the
+ * gap every time rather than occasionally. Until that is fixed, treat a
+ * quarantine as an emergency operation with a real blast radius, and read
+ * `needsRegrant` afterwards.
+ */
+export declare function quarantineKeyring(store: NoydbStore, vault: string, callerKeyring: UnlockedKeyring, userId: string): Promise<QuarantineResult>;
 /**
  * Mutate `role`, `displayName`, and/or `permissions` on an existing
  * keyring. Pure plaintext-header rewrite — no DEK rewrap, no KEK
@@ -222,6 +334,26 @@ export interface RotateResult {
         readonly userId: string;
         readonly collection: string;
     }>;
+    /**
+     * Members skipped because their `_keyring` file failed roster verification
+     * (#1114).
+     *
+     * Rotation hands a member re-wrapped DEKs, so skipping one gives them
+     * **less**, never more: the file is left untouched and its wrappings for the
+     * rotated collections go stale. That is the same fail-closed end state as
+     * `needsRegrant`, but it needs a different remedy and so gets a different
+     * field — a `needsRegrant` entry is fixed by `grant()`, whereas one of these
+     * is a file that no longer authenticates and cannot be repaired by granting
+     * over it.
+     *
+     * Before this existed, one such file threw and took `revoke` and
+     * `rotateKeys` down vault-wide — the two operations most needed when a
+     * roster is suspect.
+     */
+    readonly unverified: ReadonlyArray<{
+        readonly userId: string;
+        readonly reason: KeyringTamperedReason;
+    }>;
 }
 /** Options for {@link rotateKeys} (#846b — was a bare `string[]`). */
 export interface RotateKeysOptions {

package/dist/with-party/team/noydb-facade.d.ts

@@ -19,7 +19,7 @@
  * Internal service — reached through `noydb.team.rotateSecret(...)` etc.
  */
 import type { NoydbOptions, NoydbStore, KeyringAuthenticator } from '../../kernel/types.js';
-import type { RotateResult, RotateKeysOptions } from './keyring.js';
+import type { RotateResult, RotateKeysOptions, RosterVerifyResult, QuarantineResult } from './keyring.js';
 import { type RotateSecretInput, type RecoverSecretInput, type RecoverSecretResult, type RotateRecoveryOptions, type RotateRecoveryResult, type EnrollRecoveryResult, type RecoveryEnrollmentInput, type RecoveryProof } from './rotate-recover.js';
 import { type RecoverUserOptions } from './peer-recover.js';
 import { type PaperRecoveryEntry, type ShamirRecoveryEntry } from './recovery.js';
@@ -74,6 +74,10 @@ export declare class TeamFacade {
     runRevoke(engine: (adapter: NoydbStore, vault: string, callerKeyring: UnlockedKeyring, options: RevokeOptions) => Promise<void>, vault: string, options: RevokeOptions, factors?: FactorProofBundle): Promise<void>;
     /** Gate + run a `rotateKeys` engine. See `Noydb.rotate` for the public contract. */
     runRotate(engine: (store: NoydbStore, vault: string, callerKeyring: UnlockedKeyring, opts: RotateKeysOptions) => Promise<RotateResult>, vault: string, collections: string[]): Promise<RotateResult>;
+    /** Gate + run the `verifyRoster` engine (#1121). See `Noydb.verifyRoster`. */
+    runVerifyRoster(engine: (store: NoydbStore, vault: string, callerKeyring: UnlockedKeyring) => Promise<RosterVerifyResult>, vault: string): Promise<RosterVerifyResult>;
+    /** Gate + run the `quarantineKeyring` engine (#1121). See `Noydb.quarantineKeyring`. */
+    runQuarantine(engine: (store: NoydbStore, vault: string, callerKeyring: UnlockedKeyring, userId: string) => Promise<QuarantineResult>, vault: string, userId: string, factors?: FactorProofBundle): Promise<QuarantineResult>;
     /**
      * Add a tier-2 authenticator slot to the calling user's keyring.
      * Each slot independently wraps the SAME KEK under a method-specific

package/dist/with-party/team/roster-tag.d.ts

@@ -0,0 +1,101 @@
+/**
+ * #1096 — the authenticated half of a `_keyring` file's AUTHORITY.
+ *
+ * A `_keyring` file is stored plaintext (`_iv: ''`) so admins can edit a
+ * member's authority without holding that member's credential. That means
+ * `role`/`permissions` were authenticated by NOTHING — a hostile store could
+ * promote a viewer to admin by editing one word (proven in
+ * `__tests__/keyring-replay-escalation.test.ts`).
+ *
+ * The fix is a vault-wide ROSTER KEY, carried as a reserved DEK-map entry
+ * (`deks['_roster']`, see `ROSTER_KEY_ID`) so it reaches every member through
+ * the channels a DEK already travels — grant's `_`-prefix propagation,
+ * `persistKeyring`, the wrapped-DEKs recovery blob, `peer-recover`, pod
+ * recipient slots — and a `roster_tag`: AES-GCM of the canonical authority
+ * fields under that key. Every roster EDITOR holds the key (constraint:
+ * admins edit authority they don't hold the target's credential for) — which
+ * is what sets the bound below.
+ *
+ * `user_id` is inside the canonical string so a genuine tag cannot be
+ * transplanted onto another member's file.
+ *
+ * ## What "authority half" does NOT cover
+ *
+ * The canonical string is exactly {@link RosterAuthorityFields} — the fields a
+ * privilege decision reads. Other plaintext fields are deliberately excluded
+ * and REMAIN FORGEABLE by the store: `display_name` (cosmetic), `policy`
+ * (round-tripped, never enforced at v1.0), `echo` and `authenticators` (each
+ * authenticated by its own wrapped key material — a forged one fails to
+ * unlock rather than granting anything), plus `created_at` / `salt` /
+ * `_noydb_keyring`. Adding a field to the tag means adding it to
+ * `rosterCanonical`; nothing else here is a claim about it.
+ *
+ * ## The bound
+ *
+ * This stops the STORE, which holds no keys. It deliberately does NOT stop a
+ * malicious MEMBER: every roster editor must hold the roster key, so anyone
+ * who legitimately holds it can forge any authority field for any member.
+ * That bound must be stated in `SECURITY.md` (tracked as part of the #1096
+ * PR) — it is not written there yet.
+ */
+import type { KeyringFile } from '../../kernel/types.js';
+import type { EnclaveKey } from '../../kernel/enclave/index.js';
+export interface RosterTag {
+    readonly iv: string;
+    readonly data: string;
+}
+export type RosterAuthorityFields = Pick<KeyringFile, 'user_id' | 'role' | 'permissions' | 'granted_by' | 'expires_at' | 'export_capability' | 'import_capability'>;
+export declare function rosterCanonical(file: RosterAuthorityFields): string;
+export declare function mintRosterTag(file: RosterAuthorityFields, rosterKey: EnclaveKey): Promise<RosterTag>;
+/**
+ * false on decrypt failure OR canonical mismatch — never throws.
+ *
+ * `null` is accepted alongside `undefined` because the tag arrives from
+ * JSON a store controls: `"roster_tag": null` is a shape the type system
+ * says is impossible and the wire permits.
+ */
+export declare function verifyRosterTag(file: RosterAuthorityFields, tag: RosterTag | undefined | null, rosterKey: EnclaveKey): Promise<boolean>;
+/**
+ * #1096 — THE CHOKEPOINT. Verify a keyring file's plaintext AUTHORITY half
+ * against the roster key carried in its own, already-unwrapped, DEK set.
+ * Throws {@link KeyringTamperedError}; returns silently when the roster is
+ * authentic.
+ *
+ * **Every path that builds an `UnlockedKeyring` from a `KeyringFile` must call
+ * this — not just `loadKeyring`.** A tier-2 unlock that reconstructs
+ * `role`/`permissions` from the plaintext header without it accepts exactly
+ * the forgery tier-1 refuses, and the vault is only as strong as its weakest
+ * unlock path. That is not hypothetical: the wrap-DEKs password path shipped
+ * in this state until it was caught in review.
+ *
+ * Deliberately says nothing about the canary. The canary proves the KEK, and
+ * tier-2 paths have no KEK to prove — the roster key they hold comes from the
+ * slot's own wrapped-DEK blob, which is authenticated by its own AES-GCM tag.
+ * Callers that DO hold a KEK check the canary separately, before this.
+ *
+ * @param deks the caller's UNWRAPPED DEK set — a roster key here is proof of
+ *   possession, so this must never be handed a map built from unverified input.
+ */
+export declare function assertRosterAuthenticated(file: KeyringFile, deks: ReadonlyMap<string, EnclaveKey>, userId: string): Promise<void>;
+/**
+ * #1096 — VERIFY BEFORE YOU TRUST, and especially before you RESTAMP.
+ *
+ * The sibling of {@link assertRosterAuthenticated} for the other half of the
+ * problem. That one guards paths that *unlock* a keyring; this one guards paths
+ * that **read another member's file** — because the roster key is vault-wide, a
+ * caller holding it can verify any member's tag, not just their own.
+ *
+ * Every read-modify-write on a member's roster must call this **before** the
+ * modify. A flow that reads a forged file, edits one field and restamps does
+ * not merely tolerate the forgery — it **launders** it, converting a file
+ * `loadKeyring` refuses into one it accepts, under a genuine tag. `revoke`
+ * calls into such a flow unconditionally, so without this a single forged
+ * member plus any later revocation anywhere in the vault is a complete bypass.
+ *
+ * Fail-closed, deliberately: a forged member's file aborts the operation rather
+ * than being skipped. Skipping would complete the revoke while leaving the
+ * forgery in place, and an untrusted store can already refuse writes — so the
+ * availability it costs was never guaranteed, while the integrity it buys is
+ * the point of the mechanism.
+ */
+export declare function assertRosterTagValid(file: KeyringFile, rosterKey: EnclaveKey, userId: string): Promise<void>;

package/dist/with-shape/blobs/blob-set.d.ts

@@ -13,7 +13,7 @@ export declare const BLOB_COLLECTION = "_blob";
 /** Stores `BlobObject` metadata envelopes, keyed by eTag. */
 export declare const BLOB_INDEX_COLLECTION = "_blob_index";
 /**
- * Stores encrypted chunk envelopes, keyed by `{eTag}/{chunkIndex}`.
+ * Stores encrypted chunk envelopes, keyed by `{eTag}_{chunkIndex}`.
  * NOT loaded into the in-memory query layer. Fetched on demand by
  * `BlobSet.get()` / `BlobSet.response()`.
  */
@@ -39,7 +39,7 @@ export declare const DEFAULT_CHUNK_SIZE: number;
  *
  * ```
  * _blob_index/{eTag}                            BlobObject metadata (vault-shared DEK)
- * _blob_chunks/{eTag}/{chunkIndex}              Encrypted chunk data (vault-shared DEK + AAD)
+ * _blob_chunks/{eTag}_{chunkIndex}              Encrypted chunk data (vault-shared DEK + AAD)
  * _blob_slots_{collection}/{recordId}           Slot map (parent collection DEK)
  * _blob_versions_{collection}/{recordId}/{slot}/{label}  Published versions (parent collection DEK)
  * ```
@@ -424,16 +424,68 @@ export declare class BlobSet {
      *  - not yet stamped → apply via `casUpdateRefCountStamped`, then proceed
      *    exactly like the unstamped path below.
      *
-     * A crash can also land AFTER the index row is deleted but BEFORE every
-     * chunk is — `loadBlobObject` then returns null (indistinguishable from
-     * "never existed") and the object's `chunkCount` is gone with it. A
-     * stamped caller who knows the true count (the journal marker's captured
-     * `holds`, once that plumbing lands) supplies it via `chunkCountHint` so
-     * this call can still finish the chunk deletion; without it, an
-     * already-index-gone eTag is reported `'shredded'` same as today (best
+     * A crash can also land part-way through the deletion itself. Since #1127
+     * that deletion runs CHUNKS FIRST (see `deleteChunksThenIndex`), so what
+     * survives is an index row with some chunks already gone — a reachable,
+     * re-runnable state rather than chunks nothing can ever address again.
+     *
+     * An eTag whose index row is ALREADY absent on entry is therefore either
+     * pre-#1127 residue or a completed deletion. `loadBlobObject` returns null
+     * (indistinguishable from "never existed") and the object's `chunkCount` is
+     * gone with it. A stamped caller who knows the true count (the journal
+     * marker's captured `holds`, once that plumbing lands) supplies it via
+     * `chunkCountHint` so this call can still finish the chunk deletion; without
+     * it, an already-index-gone eTag is reported `'shredded'` same as today (best
      * effort — nothing left to key the cleanup off of).
      */
     private releaseRef;
+    /**
+     * Delete a blob's chunks, THEN its index row. The order is the whole point
+     * (#1127).
+     *
+     * Both deletions used to run index-first, which meant a crash in between
+     * stranded chunks with no index row. Nothing can ever reach those again:
+     * `loadBlobObject` returns null, so no reader addresses them — and
+     * `rekeyBlobSet` derives its chunk ids from each index entry's `chunkCount`,
+     * so a rotation never visits them either. For a LEGACY blob (bytes under the
+     * `_blob` DEK itself rather than a per-blob content CEK) the bodies then stay
+     * openable under the retired `_blob` DEK — precisely the key a revoked member
+     * walked away with. Crash during `forget()`, revoke later, and real blob
+     * content sits readable indefinitely, with no error on either side.
+     *
+     * Reversing it removes the class rather than cleaning up after it: every
+     * chunk that still exists has an index row, so every chunk is reachable by
+     * `rekeyBlobSet` and gets re-keyed. There is no orphan to sweep because none
+     * is produced.
+     *
+     * The residue this ordering leaves instead is an index row whose chunks are
+     * partly gone. That state is better, but it is NOT free — it cost one reader
+     * correction (`resolveRehomedVersionETag`, which read an old blob's bytes
+     * while resuming a rehome and now checks `refCount <= 0` instead of relying
+     * on the row having vanished). An earlier draft of this comment called the
+     * new state "strictly better"; the full suite disproved that, and any future
+     * path that reads a blob by index needs the same care. What is true of it:
+     *   - it is REACHABLE, so a re-run of `releaseRef` completes the deletion
+     *     idempotently (both `store.delete` calls are void on an absent key);
+     *   - `rekeyBlobSet` already tolerates it — a missing chunk hits its
+     *     `if (!chunkEnv || !chunkEnv._iv) continue`, so a rotation still
+     *     succeeds and still re-keys every chunk that remains;
+     *   - it cannot leak, because the bytes that survive are the ones still
+     *     covered by rotation.
+     *
+     * This also makes one ordering rule true across the blob subsystem rather
+     * than two opposite ones: `kernel/enclave/record-keys/rekey-blob.ts` already
+     * re-encrypts chunks before re-sealing their index entry, and documents that
+     * order as its resume property.
+     *
+     * Deliberately NOT paired with a sweep that deletes pre-existing orphans:
+     * such a sweep must decide "orphaned" from `store.list(_blob_index)`, and the
+     * store is untrusted. A store that withholds one index row could make a LIVE
+     * blob's chunks look orphaned and have us destroy them — turning withholding,
+     * which is reversible, into permanent loss. Reporting them is safe; deleting
+     * them on the store's word is not. See #1133 for the report-then-reclaim follow-up.
+     */
+    private deleteChunksThenIndex;
     /**
      * Crypto-shred this record's blob attachments — called by
      * `vault.forget()`.

package/dist/withdraw-accessible-JYX3SPVY.js

@@ -0,0 +1,28 @@
+import {
+  FROZEN_SNAPSHOTS_COLLECTION,
+  freezeAndDeleteClosure,
+  freezeSnapshotOnly,
+  randomId,
+  withdrawAccessibleData
+} from "./chunk-RJYPFCID.js";
+import "./chunk-BXHG26KN.js";
+import "./chunk-2VMCJUK6.js";
+import "./chunk-HRSEAGLI.js";
+import "./chunk-DIVPOJPV.js";
+import "./chunk-PENPHA45.js";
+import "./chunk-IUQPNAGR.js";
+import "./chunk-AELW6OJZ.js";
+import "./chunk-DUUARUZI.js";
+import "./chunk-LP7BEXCT.js";
+import "./chunk-O5QXH7U7.js";
+import "./chunk-IGNJOJEP.js";
+import "./chunk-PKUJ3JLQ.js";
+import "./chunk-PZ5AY32C.js";
+export {
+  FROZEN_SNAPSHOTS_COLLECTION,
+  freezeAndDeleteClosure,
+  freezeSnapshotOnly,
+  randomId,
+  withdrawAccessibleData
+};
+//# sourceMappingURL=withdraw-accessible-JYX3SPVY.js.map

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@noy-db/hub",
-  "version": "0.6.0-pre.20",
+  "version": "0.6.0-pre.22",
   "description": "Zero-knowledge, offline-first, encrypted document store — core library with AES-256-GCM, PBKDF2, multi-user keyring, and sync engine",
   "license": "MIT",
   "author": "vLannaAi <vicio@lanna.ai>",
@@ -208,6 +208,7 @@
   "files": [
     "dist",
     "README.md",
+    "CHANGELOG.md",
     "LICENSE",
     "codemods"
   ],
@@ -215,14 +216,14 @@
     "node": ">=22.0.0"
   },
   "dependencies": {
-    "@noy-db/attestation": "0.6.0-pre.20"
+    "@noy-db/attestation": "0.6.0-pre.22"
   },
   "devDependencies": {
     "@types/node": "^22.0.0",
     "esbuild": "^0.25.0",
     "zod": "^4.0.0",
     "zod-to-json-schema": "^3.25.2",
-    "@noy-db/on-shamir": "0.6.0-pre.20"
+    "@noy-db/on-shamir": "0.6.0-pre.22"
   },
   "peerDependencies": {
     "zod-to-json-schema": "^3.25.0"

package/dist/api-Z5VHH24A.js

@@ -1,20 +0,0 @@
-import {
-  UserApi,
-  createUserApi
-} from "./chunk-CVYXIN5B.js";
-import "./chunk-JHO6FGZX.js";
-import "./chunk-D5UDZANO.js";
-import "./chunk-ZVAFJQZB.js";
-import "./chunk-OQLYMBJI.js";
-import "./chunk-DJ23QZIN.js";
-import "./chunk-SFD2LL7G.js";
-import "./chunk-LP7BEXCT.js";
-import "./chunk-VJ4B3ZXY.js";
-import "./chunk-3Y4OFWQJ.js";
-import "./chunk-P7L3OQLL.js";
-import "./chunk-PZ5AY32C.js";
-export {
-  UserApi,
-  createUserApi
-};
-//# sourceMappingURL=api-Z5VHH24A.js.map