@veltdev/types 6.0.0-beta.7 → 6.0.0-beta.8

package/app/models/data/config.data.model.d.ts

@@ -66,6 +66,127 @@ export declare class Config {
      * Configuration for routing all traffic through reverse proxies.
      */
     proxyConfig?: ProxyConfig;
+    /**
+     * Self-hosting / on-prem backend configuration. When set, a deployment can point
+     * Velt-infra endpoints (Firebase config, cloud-function URLs, the notifications-hub
+     * RTDB URL, the regional setEncryptedData endpoints) at the customer's own infra.
+     *
+     * Every field is OPTIONAL and every unspecified value falls back to the per-build
+     * default in `src/environments/*` — so an existing SaaS build with no `selfHosted`
+     * config behaves exactly as before (behavior-preserving).
+     */
+    selfHosted?: SelfHostedConfig;
+}
+/**
+ * VENDORED from the backend deployment-profile manifest — source of truth:
+ * `shared-firebase-function` repo, `functions/src/deployment-profiles/modules.manifest.ts`
+ * (`DeploymentModuleId`, 13 modules; backend plan §8.3, ratified 2026-07-03; `console`
+ * split added in backend iteration-4). Do NOT add, remove, or rename ids here without a
+ * matching manifest change — the endpoint→module map in `endpoints.service.ts` and its
+ * cross-repo drift-fence test key off this list.
+ */
+export declare const DEPLOYMENT_MODULE_IDS: readonly ["core", "notifications", "recorder-media", "ai", "agents", "huddle-webrtc", "integrations-workflow", "superflow", "billing-stripe", "analytics-telemetry", "migrations", "velt-internal", "console"];
+/** A backend feature-module id (see {@link DEPLOYMENT_MODULE_IDS} for provenance). */
+export type DeploymentModuleId = typeof DEPLOYMENT_MODULE_IDS[number];
+/**
+ * Per-endpoint overrides for the cloud-function fleet. Each value is a fully-configurable
+ * ABSOLUTE base URL — do NOT assume the `*.cloudfunctions.net` shape (Tier A now serves the
+ * fleet from Cloud Run with arbitrary hostnames). Keys mirror `environment.cloudFunction.*`.
+ * Unspecified keys fall back to the `environment` default.
+ */
+export interface SelfHostedCloudFunctionConfig {
+    validateClient?: string;
+    getPlanDetails?: string;
+    sa?: string;
+    getIceServers?: string;
+    chatgptCompletion?: string;
+    rewriterAskAi?: string;
+    whisperTranscription?: string;
+    getAllowedDocuments?: string;
+    getNotificationsForDocuments?: string;
+    videoBackend?: string;
+    convertRecording?: string;
+    processRecording?: string;
+    sdkProxy?: string;
+    screenshot?: string;
+    /**
+     * Single override for the write endpoint that collapses the ×5 regional
+     * `setEncryptedData` split — when set, it is used for ALL regions. Self-hosted
+     * deployments typically run a single region.
+     */
+    setEncryptedData?: string;
+    /**
+     * Optional per-region overrides (used only if the single `setEncryptedData` above is
+     * unset). Keys are the `FirebaseRegion` values (`usCentral1`, `asiaSouthEast1`, ...).
+     */
+    regions?: {
+        [region: string]: {
+            setEncryptedData?: string;
+        };
+    };
+}
+export interface SelfHostedConfig {
+    /**
+     * Strict (full self-hosted) mode. Default `false`.
+     *
+     * - `false` (hybrid / staged rollout): any endpoint WITHOUT an injected override falls
+     *   back to the Velt default in `src/environments/*` — useful for testing one
+     *   self-hosted endpoint at a time while the rest stay on Velt SaaS.
+     * - `true` (full self-hosting / data sovereignty): there is NO fallback to Velt. An
+     *   endpoint without an injected override resolves to an inert
+     *   `velt://self-hosted-disabled/<endpoint>` sentinel that can never produce network
+     *   egress — the feature behind it is effectively disabled. Missing CORE endpoints
+     *   (`validateClient`, `sdkProxy`, `setEncryptedData`, `getNotificationsForDocuments`,
+     *   the notifications DB URL, `firebaseConfig`) are additionally
+     *   reported once as a loud misconfiguration error, since the SDK cannot function
+     *   without them (plan §4.3: every endpoint runs in the customer cloud or is disabled).
+     */
+    strict?: boolean;
+    /**
+     * Firebase config override (deep-merged over `environment.firebaseConfig`). Injected
+     * keys win; unspecified keys keep the `environment` default. Per-tenant auth-token
+     * claims still override this at runtime (within-project tenant routing is preserved).
+     *
+     * NOTE (strict mode): this is the ONE value that still falls back to the `environment`
+     * default when unset, because an undefined base config would break the Firebase
+     * bootstrap chain outright. The miss is still reported as a core misconfiguration, and
+     * the `identify()` response config overrides this base at runtime anyway. Making the
+     * bootstrap itself injectable is the tracked Phase A gap (`app.module.ts` static
+     * `initializeApp`).
+     */
+    firebaseConfig?: Partial<FirebaseOptions>;
+    /** Override for the notifications-hub RTDB URL (`firebaseNotificationsDatabaseURL`). */
+    firebaseNotificationsDatabaseURL?: string;
+    /** Per-endpoint cloud-function URL overrides. */
+    cloudFunction?: SelfHostedCloudFunctionConfig;
+    /**
+     * Enables defensive consumption of the portable-backend `identify()` response
+     * (`{ token, backend, wsEndpoint, apiEndpoint }`, backend §6.1). Default `false`:
+     * when false, a portable response is ignored and the existing Firebase path runs
+     * unchanged — no behavior change when the backend does not send it.
+     */
+    enablePortableBackend?: boolean;
+    /**
+     * The RESOLVED module closure of the deployment profile (backend plan §8.3) — the
+     * enabled-module-id list the backend deploy tooling emits in
+     * `velt-deployment-profile.json`. The customer's tooling inlines it at init; the SDK
+     * does NOT fetch it at runtime and does NOT re-resolve module dependencies (the
+     * backend's `profile-resolver.ts` already computed the fail-closed closure).
+     *
+     * Semantics (ratified — SDK-side synthesis, no Tier A server router):
+     * - Absent, not an array, or an EMPTY array (a valid resolved closure is never empty):
+     *   ALL modules enabled — byte-identical to today for SaaS and existing selfHosted
+     *   configs.
+     * - Non-empty: LITERAL membership — any endpoint whose module is NOT in the list
+     *   resolves to the inert `velt://self-hosted-disabled/*` sentinel, so the denial
+     *   normalizer synthesizes `'unimplemented'` locally with zero egress. Works with or
+     *   without `strict`. Unknown/typo'd ids enable nothing (fail-closed, mirroring the
+     *   backend resolver — a malformed profile must not silently re-open Velt egress).
+     * - A profile opt-out is authoritative: it wins over an injected endpoint URL, and its
+     *   endpoints degrade silently even when classified `core` (opt-out ≠ misconfiguration
+     *   — they are excluded from the strict-mode core-misconfiguration report).
+     */
+    deploymentProfile?: DeploymentModuleId[];
 }
 export interface ProxyConfig {
     /** Custom host for the Velt CDN (e.g., 'cdn-proxy.customer.com') */

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@veltdev/types",
-    "version": "6.0.0-beta.7",
+    "version": "6.0.0-beta.8",
     "description": "Velt is an SDK to add collaborative features to your product within minutes. Example: Comments like Figma, Frame.io, Google docs or sheets, Recording like Loom, Huddles like Slack and much more.",
     "homepage": "https://velt.dev",
     "keywords": [