@byok-sdk/server 0.12.0 → 0.13.0

package/dist/ids.d.ts

@@ -1,3 +0,0 @@
-export declare function generatePairingCode(length?: number): string;
-export declare function generateDeviceId(): string;
-export declare function generateTaskId(): string;

package/dist/pairing.d.ts

@@ -1,87 +0,0 @@
-import type { TenantId } from './auth';
-/**
- * S1: the tenant identity a pairing code carries. Minted out-of-band by the
- * SaaS's own auth/device-flow UI — the only party that knows which tenant a
- * human is acting for — and returned by {@link PairingManager.redeemPairingCode}
- * so `POST /byok/pair` can write it onto the device row in the same
- * synchronous step that consumes the code.
- *
- * Deliberately NOT a wire field: `PairRequest` has no tenant of its own
- * (docs/protocol.md §6.1), so a device can never name the tenant it lands in.
- * These claims are the single source of truth for the row, and the row — not
- * a later token, and never client input — is what every authed surface
- * checks against.
- */
-export interface PairingCodeClaims {
-    tenantId: TenantId;
-    productId: string;
-}
-export interface PairingCodeInfo {
-    code: string;
-    expiresAt: string;
-}
-/** Immutable facts supplied by one first-pair HTTP request. */
-export interface PairingAttemptBinding {
-    deviceName: string;
-    devicePublicKey: string;
-}
-/** The recoverable enrollment fact created exactly once for one pairing code. */
-export interface PairingCompletion {
-    deviceId: string;
-    tenantId: TenantId;
-    productId: string;
-    deviceName: string;
-    devicePublicKey: string;
-}
-/** Thrown when a pairing code is missing, expired, or already used. */
-export declare class PairingCodeInvalidError extends Error {
-    constructor(reason: string);
-}
-/** A spent code may be replayed only with the immutable request that spent it. */
-export declare class PairingAttemptConflictError extends Error {
-    constructor();
-}
-/**
- * In-memory pairing-code lifecycle: single-use, ~10min TTL codes minted
- * out-of-band (by the SaaS's own auth/device-flow UI) and redeemed exactly
- * once by `POST /byok/pair`.
- *
- * Device identity (deviceId/deviceName/devicePublicKey/revocation) and
- * token issuance moved to `auth.ts`'s `DeviceRegistry`/`TokenSigner` as of
- * Auth v2 (docs/protocol.md §6) — this class knows about devices only to the
- * extent of carrying the {@link PairingCodeClaims} that decide which tenant
- * and product the device being paired will belong to (S1).
- */
-export declare class PairingManager {
-    private readonly codes;
-    /**
-     * Mint a single-use code bound to `claims`. Claims are REQUIRED — a
-     * claimless mint is a compile error, and (for a JS caller, or a claims
-     * object assembled from untyped config) a runtime {@link TypeError}. There
-     * is no default tenant and no default product: a device with no tenant
-     * must be inexpressible, so the failure happens here, at the mint, rather
-     * than being filled in downstream.
-     */
-    createPairingCode(claims: PairingCodeClaims): PairingCodeInfo;
-    /**
-     * Validate and consume a pairing code, returning the {@link PairingCodeClaims}
-     * it was minted with. Throws {@link PairingCodeInvalidError} if the code is
-     * unknown, expired, or already used — callers (the HTTP handler) map that to
-     * a 401. Single-use is what makes the caller's "redeem, then register the
-     * device row with these claims" sequence safe: a second redeem of the same
-     * code can never reach the registration step at all.
-     */
-    redeemPairingCode(code: string): PairingCodeClaims;
-    /**
-     * Bind a code to one exact pairing request, returning any completion that a
-     * prior response/token failure left recoverable. This mutation is entirely
-     * synchronous: the HTTP route cannot yield between binding, registration,
-     * and completion recording, so concurrent requests have one winner.
-     */
-    beginPairingAttempt(code: string, binding: PairingAttemptBinding): {
-        claims: PairingCodeClaims;
-        completion?: PairingCompletion;
-    };
-    /** Record the one device identity a bound pairing attempt completed as. */
-    completePairingAttempt(code: string, binding: PairingAttemptBinding, completion: PairingCompletion): PairingCompletion;
-}

package/dist/sqlite-blob-store.d.ts

@@ -1,94 +0,0 @@
-import type { DatabaseSync } from 'node:sqlite';
-import { type BlobStore, type CreateUploadInput, type ReadContentResult, type WriteContentResult } from './blob-store';
-import type { TenantId } from './auth';
-export interface SqliteBlobStoreOptions {
-    /**
-     * Database file path. Use `:memory:` to exercise the SQLite code path
-     * without persistence — defeats this store's whole purpose (same caveat
-     * as `SqliteTaskStore`'s `:memory:` option); real restart-safety requires
-     * a real file path.
-     */
-    path: string;
-    /** How long a presigned upload/download URL stays valid, ms. Default 15 minutes — same default as `LocalDiskBlobStore`. */
-    urlTtlMs?: number;
-    /**
-     * HMAC signing key for presigned URLs. Defaults to a key generated once
-     * and persisted in this same database (a `meta` table) — so, unlike
-     * `LocalDiskBlobStore`'s fresh-per-instance `randomBytes(32)` (fine there
-     * only because its metadata doesn't survive a restart either), the
-     * default here is *already* stable across restarts: a URL signed by one
-     * process instance still verifies against a later instance pointed at
-     * the same database file. Pass this explicitly only if the key needs to
-     * live outside the database (e.g. shared across multiple database files,
-     * or rotated independently of the data).
-     */
-    signingKey?: Buffer;
-}
-/** Exported (only) so `sqlite-blob-store.test.ts` can apply the same schema to a raw `DatabaseSync` connection when testing {@link loadOrCreateSigningSecret}'s concurrency behavior directly. */
-export declare const SCHEMA = "\nCREATE TABLE IF NOT EXISTS meta (\n  key   TEXT PRIMARY KEY,\n  value TEXT NOT NULL\n);\nCREATE TABLE IF NOT EXISTS blobs (\n  blob_id      TEXT PRIMARY KEY,\n  tenant_id    TEXT NOT NULL,\n  size         INTEGER NOT NULL,\n  content_type TEXT NOT NULL,\n  content_hash TEXT NOT NULL,\n  uploaded     INTEGER NOT NULL DEFAULT 0,\n  data         BLOB\n);\n";
-/**
- * Atomically load the persisted HMAC signing secret from `db`'s `meta`
- * table, generating and persisting one if none exists yet.
- *
- * Safe under two `DatabaseSync` connections racing on the same file — e.g.
- * two fresh `SqliteBlobStore` instances constructed against a brand-new
- * database at nearly the same moment. Both may see no existing row (via the
- * initial `SELECT`) and both generate a candidate secret, but `INSERT OR
- * IGNORE` guarantees at most one candidate is ever persisted, and —
- * critically — EVERY caller unconditionally re-reads the row afterward and
- * returns THAT value, never its own locally-generated candidate. Without
- * that re-read (the bug this fixes: the previous implementation used
- * `INSERT OR REPLACE` and returned its own candidate unconditionally), a
- * caller whose candidate lost the race would keep using its own discarded
- * value in memory — so a presigned URL it signs would fail to verify
- * against any other instance, which persisted (and uses) the winning value.
- *
- * `generateCandidate` defaults to `randomBytes(32)`; overridable so
- * `sqlite-blob-store.test.ts` can deterministically force the race window —
- * real callers never need to pass it.
- */
-export declare function loadOrCreateSigningSecret(db: DatabaseSync, generateCandidate?: () => Buffer): Buffer;
-/**
- * Persistent {@link BlobStore} backed by `node:sqlite` — no native
- * dependency, same rationale as `SqliteTaskStore` (`sqlite-support.ts`).
- * Metadata AND content bytes both live in the same database file (a `data
- * BLOB` column), so a fresh instance pointed at the same file recovers
- * everything: declared blobs, upload state, and the bytes themselves,
- * byte-for-byte.
- *
- * Presigned URLs use the same HMAC-signed-query-param scheme as
- * `LocalDiskBlobStore` (`/byok/blobs/:id/content?sig=...&exp=...`, verified
- * generically by `http.ts` via {@link verifySignedUrl} regardless of which
- * `BlobStore` is plugged in) — the only difference is where the signing
- * secret comes from; see {@link SqliteBlobStoreOptions.signingKey}.
- *
- * Requires Node.js 22.5+ (`node:sqlite`'s minimum); constructing this on an
- * unsupported runtime throws `SqliteUnavailableError` (`sqlite-support.ts`).
- */
-export declare class SqliteBlobStore implements BlobStore {
-    private readonly db;
-    private readonly urlTtlMs;
-    private readonly secret;
-    private readonly insertBlobStmt;
-    private readonly selectBlobStmt;
-    private readonly selectUploadedStmt;
-    private readonly writeContentStmt;
-    private closed;
-    constructor(opts: SqliteBlobStoreOptions);
-    createUpload(tenantId: TenantId, input: CreateUploadInput, requestedBlobId?: string): Promise<{
-        blobId: string;
-        uploadUrl: string;
-    }>;
-    getDownloadUrl(tenantId: TenantId, blobId: string): Promise<string | undefined>;
-    exists(tenantId: TenantId, blobId: string): Promise<boolean>;
-    getUploadReservation(blobId: string): Promise<{
-        size: number;
-    } | undefined>;
-    verifySignedUrl(blobId: string, action: 'put' | 'get', sig: string, exp: number): boolean;
-    writeContent(blobId: string, data: Buffer): Promise<WriteContentResult>;
-    readContent(blobId: string): Promise<ReadContentResult | undefined>;
-    /** Close the underlying database connection — see `SqliteTaskStore.close`'s doc comment; same rationale. */
-    close(): void;
-    private computeSig;
-    private signUrl;
-}

package/dist/sqlite-task-store.d.ts

@@ -1,124 +0,0 @@
-import { type TaskState } from '@byok-sdk/protocol';
-import type { DatabaseSync } from 'node:sqlite';
-import { type CreateTaskInput, type TaskRecord, type TaskStore } from './task-store';
-export interface SqliteTaskStoreOptions {
-    /**
-     * Database file path. Use `:memory:` to exercise the SQLite code path
-     * without a temp file (e.g. schema/query correctness tests) — but note
-     * that defeats the entire point of this store (restart-safety), since an
-     * in-memory SQLite database vanishes with the process exactly like
-     * `InMemoryTaskStore` does. Real persistence requires a real file path.
-     */
-    path: string;
-}
-/**
- * S5 hardening: two processes (or two `SqliteTaskStore` instances in this
- * one) can both construct against the same pre-existing file at close to the
- * same instant, both see a given column missing via the `PRAGMA table_info`
- * read below, and both attempt the same `ALTER TABLE ... ADD COLUMN` —
- * SQLite allows only one to actually add it; the loser's `db.exec` throws
- * `duplicate column name`. That failure means the OTHER writer already won —
- * the column now genuinely exists, which is exactly the end state this
- * function is trying to reach — so it's caught here, the column list is
- * re-inspected fresh, and this function proceeds normally (no throw) once
- * confirmed. Anything else (a real schema problem, a disk error, a
- * `duplicate column name` for a DIFFERENT column than expected) is rethrown
- * unchanged — this only swallows the exact race this is written for.
- *
- * Exported only for this package's own tests to exercise the race
- * deterministically (mirrors `sqlite-support.ts`'s
- * `isSqliteCapableNodeVersion` convention) — not re-exported from
- * `index.ts`, so not part of the public package API.
- */
-export declare function ensureAdditiveColumns(db: DatabaseSync): void;
-/**
- * Persistent {@link TaskStore} backed by the Node.js built-in `node:sqlite`
- * module — no native dependency (`sqlite-support.ts`'s doc comment explains
- * why that's a hard requirement here). A fresh instance pointed at the same
- * database file recovers every task's full RECORD (instruction, policy,
- * device/session refs, result) exactly as `InMemoryTaskStore` would have
- * held it in memory — this is the M3 "task records survive a process
- * restart" story.
- *
- * Scope of that claim, precisely: this is RECORD persistence, not live
- * active-task recovery. A fresh `ConnectionHub` (`hub.ts`) wired to a
- * reopened store starts with empty runtimes/result-promises/event-queues/
- * device-registry/outboxes — so a task that was `Running` at restart comes
- * back as a `Running` *record* you can read and further `transition()`, not
- * as a task with its device/runtime connection reattached that will go on
- * to actually produce more events. Recovering/resuming an in-flight task's
- * live connection is a larger feature and out of scope here.
- *
- * Every write goes through a compare-and-set `UPDATE ... WHERE task_id = ?
- * AND state = ?` (the state {@link transition} just validated against), not
- * an unconditional update: two connections racing on the same task (both
- * reading e.g. `Running`, both independently validating a different target
- * state) can't both commit, which would otherwise let the later write
- * silently perform an illegal transition — including terminal -> terminal —
- * that neither validation call would have allowed had it seen the other's
- * write first. A lost compare-and-set re-reads the row and either
- * re-validates the requested move against the state that actually won, or
- * throws {@link IllegalTaskTransitionError} against it.
- *
- * Requires Node.js 22.5+ (`node:sqlite`'s minimum); constructing this on an
- * older/unsupported runtime throws `SqliteUnavailableError`
- * (`sqlite-support.ts`) with a clear message rather than a cryptic "Cannot
- * find module" trace.
- *
- * Enforces the exact same `TASK_TRANSITIONS`/`canTransition` state machine
- * as `InMemoryTaskStore`, via the same {@link IllegalTaskTransitionError}.
- */
-export declare class SqliteTaskStore implements TaskStore {
-    private readonly db;
-    private readonly insertStmt;
-    private readonly updateStmt;
-    private readonly selectStmt;
-    private readonly selectAllStmt;
-    private readonly updatePendingApprovalIdStmt;
-    private closed;
-    constructor(opts: SqliteTaskStoreOptions);
-    create(input: CreateTaskInput): TaskRecord;
-    get(taskId: string): TaskRecord | undefined;
-    list(): TaskRecord[];
-    /**
-     * Apply `taskId`'s state -> `to`, merging `patch` into the record. Throws
-     * {@link IllegalTaskTransitionError} if the move isn't legal per
-     * `TASK_TRANSITIONS`, and if the task doesn't exist at all — identical
-     * contract and error shapes to `InMemoryTaskStore.transition`.
-     *
-     * Implemented as a compare-and-set retry loop rather than a single
-     * read-validate-write, because two separate connections (two processes,
-     * or two `SqliteTaskStore` instances in this one) can both read the same
-     * current state and both validate a move against it before either writes.
-     * An unconditional `UPDATE` would let whichever commits last silently win
-     * — including an illegal terminal -> terminal transition neither
-     * validation call would have allowed with up-to-date information. Each
-     * iteration here reads the CURRENT state fresh, validates `to` against
-     * it, then writes with `WHERE state = <the state just validated>`
-     * (`updateStmt`). If zero rows changed, some other writer committed
-     * between this read and this write, so the loop re-reads and either
-     * re-validates `to` against whatever the state actually is now, or throws
-     * {@link IllegalTaskTransitionError} against it — the same outcome a
-     * caller would get if it happened to run a moment later.
-     */
-    transition(taskId: string, to: TaskState, patch?: Partial<Omit<TaskRecord, 'taskId' | 'state'>>): TaskRecord;
-    /**
-     * See {@link TaskStore.setPendingApprovalId}'s own doc comment for the
-     * full rationale, and `updatePendingApprovalIdStmt`'s own doc comment
-     * (constructor, above) for the S3 CAS-guard rationale. The guarded
-     * statement affecting 0 rows means `taskId` is no longer `AwaitApproval`
-     * (or vanished) as of the write — a legitimate no-op, not an error: this
-     * method never throws for a state mismatch (best-effort bookkeeping, same
-     * as its unconditional pre-S3 form). Returns a FRESH read in that case
-     * rather than the caller's now-stale pre-write snapshot, so a caller sees
-     * what's actually stored.
-     */
-    setPendingApprovalId(taskId: string, pendingApprovalId: string | undefined): TaskRecord | undefined;
-    /**
-     * Close the underlying database connection. Not part of the `TaskStore`
-     * interface (an in-memory store has nothing to close) — call this
-     * explicitly when a store instance is done, e.g. before opening a second
-     * instance against the same file, or on process shutdown.
-     */
-    close(): void;
-}

package/dist/task-store.d.ts

@@ -1,127 +0,0 @@
-import { type AgentRef, type PermissionPolicy, type RuntimeId, type TaskState, type ToolsetId } from '@byok-sdk/protocol';
-import type { TaskSnapshot } from './types';
-/** Thrown by a {@link TaskStore}'s `transition` when `from -> to` is not in TASK_TRANSITIONS. Every implementation (in-memory, SQLite, or otherwise) must throw this rather than silently applying an invalid move. */
-export declare class IllegalTaskTransitionError extends Error {
-    readonly taskId: string;
-    readonly from: TaskState;
-    readonly to: TaskState;
-    constructor(taskId: string, from: TaskState, to: TaskState);
-}
-export interface CreateTaskInput {
-    taskId: string;
-    instruction: string;
-    runtime?: RuntimeId;
-    policy: PermissionPolicy;
-    requiredToolsets?: ToolsetId[];
-    deviceId?: string;
-    sessionRef?: string;
-    agentRef?: AgentRef;
-}
-/** A task's full persisted state, as tracked by any {@link TaskStore} implementation. Same shape as {@link TaskSnapshot} — kept as its own (structurally identical) type so this storage-layer contract can evolve independently of the SDK-facing `TaskSnapshot` if a future need arises. */
-export interface TaskRecord extends TaskSnapshot {
-}
-/**
- * Storage contract for task records — the M3 injection point, mirroring how
- * {@link BlobStore} (`blob-store.ts`) is injectable: `createByokServer`
- * (`index.ts`) accepts `opts.taskStore`, defaulting to {@link InMemoryTaskStore}
- * so nothing breaks for an embedder that doesn't override it. `ConnectionHub`
- * (`hub.ts`) is written against this interface only — it never references
- * {@link InMemoryTaskStore} (or any other concrete implementation) directly —
- * so a persistent implementation such as `sqlite-task-store.ts`'s
- * `SqliteTaskStore` (M3) drops in with zero changes anywhere else.
- *
- * Every implementation MUST enforce the protocol's `TASK_TRANSITIONS` state
- * machine (via `canTransition`) inside `transition`, throwing
- * {@link IllegalTaskTransitionError} rather than silently applying an
- * invalid move — this is part of the interface's contract, not just an
- * `InMemoryTaskStore` implementation detail. `ConnectionHub`'s `applyOrFail`
- * (`hub.ts`) relies on that exception type to decide "illegal transition ->
- * force `Failed` if possible, else drop".
- */
-export interface TaskStore {
-    /** Create a new task record in the `Offered` state. */
-    create(input: CreateTaskInput): TaskRecord;
-    /** Look up a task by id, or `undefined` if unknown. */
-    get(taskId: string): TaskRecord | undefined;
-    /** All known tasks. */
-    list(): TaskRecord[];
-    /**
-     * Apply `taskId`'s state -> `to`, merging `patch` into the record. Must
-     * throw {@link IllegalTaskTransitionError} if the move isn't legal per
-     * `TASK_TRANSITIONS`, and a plain `Error` (message: `` `unknown taskId:
-     * ${taskId}` ``) if the task doesn't exist at all —
-     * {@link InMemoryTaskStore.transition}'s existing message format, which
-     * some tests match on.
-     */
-    transition(taskId: string, to: TaskState, patch?: Partial<Omit<TaskRecord, 'taskId' | 'state'>>): TaskRecord;
-    /**
-     * M5 (approval targeting): update `taskId`'s `pendingApprovalId` WITHOUT a
-     * state transition. Needed because `AwaitApproval -> AwaitApproval` is
-     * deliberately not a legal `TASK_TRANSITIONS` edge (`@byok-sdk/protocol`'s
-     * `task-state.ts`) — self-transitions aren't part of the frozen wire state
-     * machine, so `transition` above cannot be used to update this field while
-     * the record STAYS in `AwaitApproval` — yet a re-sent/updated
-     * `task.await_approval` carrying a NEWER id while the record is ALREADY
-     * `AwaitApproval` must still be reflected (see `ConnectionHub.
-     * onAwaitApproval`, `hub.ts`). Every state-CHANGING write still goes
-     * through `transition`; this is the one narrow exception for a same-state
-     * field update. Returns `undefined` for an unknown `taskId` rather than
-     * throwing — this is a best-effort bookkeeping update, not a
-     * state-machine-enforced operation like `transition`.
-     *
-     * OPTIONAL: a `TaskStore` implementation predating M5 (a custom embedder
-     * store written against the pre-M5 interface) doesn't have this method at
-     * all — every call site in `hub.ts` guards its absence with `?.()`. A
-     * store that omits it simply never records a superseding
-     * `pendingApprovalId` on the same-state redelivery path (the first entry
-     * into `AwaitApproval` still records one via `transition`'s own patch,
-     * same as ever); an operator-supplied `opts.approvalId` on
-     * `approveTask`/`rejectTask` then has nothing recorded to compare against
-     * and proceeds untargeted, exactly like a legacy daemon that never
-     * reported an id at all — a graceful degrade, not a broken embedder.
-     * Every CURRENT implementation in this package ({@link InMemoryTaskStore},
-     * `sqlite-task-store.ts`'s `SqliteTaskStore`) still implements it as a
-     * required, always-present method — optionality is a concession to
-     * EXISTING third-party implementations of this interface, not a hint that
-     * a new one should skip it.
-     */
-    setPendingApprovalId?(taskId: string, pendingApprovalId: string | undefined): TaskRecord | undefined;
-}
-/**
- * Plain, framework-agnostic in-memory {@link TaskStore}. Enforces the
- * protocol's `TASK_TRANSITIONS` state machine via `canTransition` — every
- * state change must go through {@link transition}, which throws
- * {@link IllegalTaskTransitionError} rather than silently applying an invalid
- * move. Callers (the connection hub) decide what to do with that error; see
- * `hub.ts`'s `applyOrFail` for the "illegal transition -> force Failed if
- * possible, else drop" policy.
- *
- * M0/M1/M2 reference default — loses all state on process restart. See
- * `sqlite-task-store.ts`'s `SqliteTaskStore` (M3) for a persistent
- * alternative implementing the same {@link TaskStore} contract.
- */
-export declare class InMemoryTaskStore implements TaskStore {
-    private readonly tasks;
-    create(input: CreateTaskInput): TaskRecord;
-    get(taskId: string): TaskRecord | undefined;
-    list(): TaskRecord[];
-    /**
-     * Apply `taskId`'s state -> `to`, merging `patch` into the record. Throws
-     * {@link IllegalTaskTransitionError} if the move isn't legal per
-     * `TASK_TRANSITIONS`, and if the task doesn't exist at all.
-     */
-    transition(taskId: string, to: TaskState, patch?: Partial<Omit<TaskRecord, 'taskId' | 'state'>>): TaskRecord;
-    /**
-     * See {@link TaskStore.setPendingApprovalId}'s own doc comment for the
-     * full rationale. State-guarded (S3 hardening): a write only applies while
-     * `taskId` is still `AwaitApproval` — mirrors `SqliteTaskStore`'s own `AND
-     * state = 'AwaitApproval'` CAS predicate (`sqlite-task-store.ts`) for
-     * symmetry between the two reference implementations, guarding against a
-     * laggard caller resurrecting a pending id after the task already left
-     * `AwaitApproval` (e.g. a queued/delayed `task.await_approval` processed
-     * after a real `approveTask`/`rejectTask` already transitioned it
-     * elsewhere). A non-matching call is a no-op: returns the record exactly
-     * as it currently stands, not the caller's requested (rejected) value.
-     */
-    setPendingApprovalId(taskId: string, pendingApprovalId: string | undefined): TaskRecord | undefined;
-}

package/dist/ws-server.d.ts

@@ -1,23 +0,0 @@
-import type { Server as HttpServer } from 'node:http';
-import { type AuthDeps } from './auth';
-import type { ConnectionHub } from './hub';
-interface AttachDeps extends AuthDeps {
-    hub: ConnectionHub;
-    productId: string;
-    /** WS-native ping interval, ms. Defaults inside `heartbeat.ts` (30s) if omitted. */
-    heartbeatIntervalMs?: number;
-    helloTimeoutMs: number;
-    maxPendingWebSockets: number;
-    maxPayloadBytes: number;
-}
-/**
- * Wire up the `GET /byok/ws` upgrade on a raw Node HTTP server (the one
- * `@hono/node-server`'s `serve()` returns). Auth happens on the upgrade
- * request itself via `Authorization: Bearer <accessToken>` (a JWT minted by
- * `/byok/pair` or `/byok/token` — Auth v2, §6); an invalid, expired, or
- * revoked token gets a 401 and the socket is destroyed. Handshake
- * (`conn.hello` -> `conn.ack`) happens on the first WS message once
- * upgraded.
- */
-export declare function attachWebSocket(server: HttpServer, deps: AttachDeps): void;
-export {};