founder-schema 0.18.0 → 0.20.0

package/dist/chat.d.ts

@@ -1,187 +0,0 @@
-/**
- * founder-schema — Chat: config, auth token, opening a conversation, participants
- *
- * Founder Circle does not run a chat server. It uses the shared one, which
- * serves several products, and that is the whole reason this file is careful:
- * when one server serves many tenants, the failure mode is SILENT. A push once
- * returned success having sent nothing, because the caller held the wrong
- * product's key and nothing in the exchange said which product it was for.
- *
- * So the rule these shapes exist to hold: TENANCY COMES FROM THE CREDENTIAL,
- * never from a request body. The token says which product it is for, the chat
- * server resolves the product from the token and from nothing else, and a
- * Founder Circle token cannot address another product's conversation even when
- * handed a valid-looking id.
- *
- * ⚠️ TEXT ONLY. There is deliberately no `callsEnabled` flag here, and its
- * absence is the feature: the user ruled chat is text only, there is no call
- * code to branch on, and the browser is told to deny camera and microphone
- * outright. A boolean that can never be true is an invitation to turn it on.
- *
- * @module founder-schema/chat
- */
-import { z } from 'zod';
-/**
- * The product this package speaks for.
- *
- * Typed as a LITERAL on purpose. If the shared chat server ever hands back a
- * config or a token minted for a different product, parsing fails loudly here
- * rather than the client quietly talking to the wrong tenant. That is exactly
- * the class of bug this file exists to prevent, so it should be impossible to
- * carry past the first parse.
- */
-export declare const CHAT_PRODUCT_ID: "founder-circle";
-export declare const chatProductIdSchema: z.ZodLiteral<"founder-circle">;
-export type ChatProductId = z.infer<typeof chatProductIdSchema>;
-/**
- * What the client needs before it can open a socket.
- *
- * ⚠️ `enabled` IS MANDATORY AND IS NOT DERIVED FROM `url`. "Messaging is not
- * switched on yet" is a first-class state, not a failure: a 404 is the expected
- * answer today, and the client collapses a disabled flag, a null url, a non-2xx
- * and a thrown fetch to the same quiet "not on yet" rather than an error. If
- * `enabled` were inferred from a missing url, "off" and "broken" would be the
- * same wire shape and the inbox could not tell a member which one it was.
- *
- * ⚠️ `userId` is required and is the field nothing works without. The client
- * needs to know WHO THE VIEWER IS to decide which side a bubble sits on, to
- * filter the viewer out of presence and typing, to pick the other participant
- * for a row's name and avatar, and to tell its own optimistic message from one
- * echoed back. Without it every conversation renders as though the viewer were
- * nobody. It was missing from the first sketch of this endpoint.
- */
-export declare const chatConfigSchema: z.ZodObject<{
-    enabled: z.ZodBoolean;
-    url: z.ZodNullable<z.ZodURL>;
-    userId: z.ZodString;
-    productId: z.ZodLiteral<"founder-circle">;
-}, z.core.$strip>;
-export type ChatConfig = z.infer<typeof chatConfigSchema>;
-/**
- * How long before expiry the client re-mints, in seconds.
- *
- * Exported because it is a contract detail and not an implementation one: a
- * token handed over with two seconds left is a socket that authenticates and is
- * closed again immediately, so the minting side needs to know the consuming
- * side will not use the last minute of a token's life.
- */
-export declare const CHAT_TOKEN_REFRESH_MARGIN_SECONDS = 60;
-/**
- * How often the live socket re-authenticates, in seconds.
- *
- * Auth is an EVENT on the open socket rather than a handshake parameter, so
- * re-authenticating does not drop the connection.
- *
- * ⚠️ THIS MUST STAY BELOW THE REAL TOKEN LIFETIME, by more than the refresh
- * margin. It assumes a 15 minute token. A re-auth interval longer than the
- * lifetime is a socket that dies every quarter of an hour with no explanation,
- * and the symptom appears far from the cause. If the issued lifetime changes,
- * this number moves with it or the two silently disagree.
- */
-export declare const CHAT_SOCKET_REAUTH_SECONDS: number;
-/**
- * A short-lived token for the shared chat server.
- *
- * ⚠️ BOTH TIME FIELDS ARE KEPT, and they are not redundant, because two
- * different parties read them with two different clocks:
- *
- *   `expiresAt`  an absolute instant, for the SERVER. The chat server holds the
- *                authoritative clock and must reject an expired token on its
- *                own, whatever any client believes.
- *   `expiresIn`  a duration in seconds, for the CLIENT. Scheduling a refresh
- *                from `receivedAt + expiresIn` uses only the client's own
- *                elapsed time, so a device whose absolute clock is wrong still
- *                refreshes correctly. Scheduling from `expiresAt` instead means
- *                a browser an hour fast treats every fresh token as already
- *                expired and re-mints forever.
- *
- * Dropping either one breaks the party that reads it. This is the same reason
- * OAuth carries `expires_in` on the wire while the token itself carries `exp`.
- *
- * ⚠️ AND THE CLIENT IS NOT THE ENFORCER. Its margin is an optimisation to avoid
- * a pointless round trip. A wrong clock, a tab asleep for an hour, or a modified
- * client all defeat anything the client does, so the chat server rejects an
- * expired token on its own.
- */
-export declare const chatAuthTokenSchema: z.ZodObject<{
-    token: z.ZodString;
-    expiresAt: z.ZodISODateTime;
-    expiresIn: z.ZodNumber;
-    productId: z.ZodLiteral<"founder-circle">;
-}, z.core.$strip>;
-export type ChatAuthToken = z.infer<typeof chatAuthTokenSchema>;
-/**
- * `POST /api/v1/chat/open`: start (or find) the direct conversation with
- * another member.
- *
- * Our backend decides who may talk to whom, because only it knows this
- * product's rules, and it does the whole exchange with the chat server itself:
- * it mints the viewer's token and an invitation naming both participants, and
- * redeems them server to server. No credential reaches the browser.
- */
-export declare const openChatBodySchema: z.ZodObject<{
-    userId: z.ZodPipe<z.ZodString, z.ZodTransform<string, string>>;
-}, z.core.$strip>;
-export type OpenChatBody = z.infer<typeof openChatBodySchema>;
-/**
- * The conversation to navigate to. `201` with `wasCreated: true` the first
- * time, `200` and `false` on every later open of the same pair.
- */
-export declare const openChatResponseSchema: z.ZodObject<{
-    conversationId: z.ZodString;
-    wasCreated: z.ZodBoolean;
-}, z.core.$strip>;
-export type OpenChatResponse = z.infer<typeof openChatResponseSchema>;
-/**
- * `POST /api/v1/chat/participants`: names and avatars for the people in the
- * viewer's conversations.
- *
- * The chat server knows ids and nothing about who anybody is, because it serves
- * several products and identity belongs to each; so the conversation list asks
- * here, once per screen. Bounded by `CHAT_PARTICIPANTS_MAX`, so it cannot page
- * through the directory.
- */
-export declare const chatParticipantsBodySchema: z.ZodObject<{
-    userIds: z.ZodArray<z.ZodPipe<z.ZodString, z.ZodTransform<string, string>>>;
-}, z.core.$strip>;
-export type ChatParticipantsBody = z.infer<typeof chatParticipantsBodySchema>;
-/** The public card fields any member already sees, and nothing more. */
-export declare const chatParticipantSchema: z.ZodObject<{
-    displayName: z.ZodString;
-    username: z.ZodString;
-    avatarUrl: z.ZodNullable<z.ZodURL>;
-}, z.core.$strip>;
-export type ChatParticipant = z.infer<typeof chatParticipantSchema>;
-/**
- * Keyed by user id. ⚠ An id with no active, onboarded profile is ABSENT, not
- * an error: the client renders it as a former member rather than guessing.
- */
-export declare const chatParticipantsResponseSchema: z.ZodObject<{
-    participants: z.ZodRecord<z.ZodString, z.ZodObject<{
-        displayName: z.ZodString;
-        username: z.ZodString;
-        avatarUrl: z.ZodNullable<z.ZodURL>;
-    }, z.core.$strip>>;
-}, z.core.$strip>;
-export type ChatParticipantsResponse = z.infer<typeof chatParticipantsResponseSchema>;
-/**
- * @deprecated Since 0.2.0: use `openChatBodySchema`, the same shape under the
- * name of the route that takes it.
- */
-export declare const chatInvitationBodySchema: z.ZodObject<{
-    userId: z.ZodPipe<z.ZodString, z.ZodTransform<string, string>>;
-}, z.core.$strip>;
-/** @deprecated Since 0.2.0: use `OpenChatBody`. */
-export type ChatInvitationBody = OpenChatBody;
-/**
- * @deprecated Since 0.2.0, and it describes nothing that exists. The browser
- * never holds an invitation: `/chat/open` mints and redeems it server to
- * server. The old `/invitation` route that handed one out could never have
- * worked and is gone.
- */
-export declare const chatInvitationSchema: z.ZodObject<{
-    invitationToken: z.ZodString;
-}, z.core.$strip>;
-/** @deprecated Since 0.2.0. */
-export type ChatInvitation = z.infer<typeof chatInvitationSchema>;
-//# sourceMappingURL=chat.d.ts.map

package/dist/chat.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"chat.d.ts","sourceRoot":"","sources":["../src/chat.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;GAqBG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAIxB;;;;;;;;GAQG;AACH,eAAO,MAAM,eAAe,EAAG,gBAAyB,CAAC;AACzD,eAAO,MAAM,mBAAmB,gCAA6B,CAAC;AAC9D,MAAM,MAAM,aAAa,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,mBAAmB,CAAC,CAAC;AAIhE;;;;;;;;;;;;;;;;GAgBG;AACH,eAAO,MAAM,gBAAgB;;;;;iBAQ3B,CAAC;AACH,MAAM,MAAM,UAAU,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,gBAAgB,CAAC,CAAC;AAI1D;;;;;;;GAOG;AACH,eAAO,MAAM,iCAAiC,KAAK,CAAC;AAEpD;;;;;;;;;;;GAWG;AACH,eAAO,MAAM,0BAA0B,QAAU,CAAC;AAElD;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,eAAO,MAAM,mBAAmB;;;;;iBAQ9B,CAAC;AACH,MAAM,MAAM,aAAa,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,mBAAmB,CAAC,CAAC;AAIhE;;;;;;;;GAQG;AACH,eAAO,MAAM,kBAAkB;;iBAG7B,CAAC;AACH,MAAM,MAAM,YAAY,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,kBAAkB,CAAC,CAAC;AAE9D;;;GAGG;AACH,eAAO,MAAM,sBAAsB;;;iBAGjC,CAAC;AACH,MAAM,MAAM,gBAAgB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,sBAAsB,CAAC,CAAC;AAItE;;;;;;;;GAQG;AACH,eAAO,MAAM,0BAA0B;;iBAErC,CAAC;AACH,MAAM,MAAM,oBAAoB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,0BAA0B,CAAC,CAAC;AAE9E,wEAAwE;AACxE,eAAO,MAAM,qBAAqB;;;;iBAKhC,CAAC;AACH,MAAM,MAAM,eAAe,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,qBAAqB,CAAC,CAAC;AAEpE;;;GAGG;AACH,eAAO,MAAM,8BAA8B;;;;;;iBAEzC,CAAC;AACH,MAAM,MAAM,wBAAwB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,8BAA8B,CAAC,CAAC;AAStF;;;GAGG;AACH,eAAO,MAAM,wBAAwB;;iBAAqB,CAAC;AAC3D,mDAAmD;AACnD,MAAM,MAAM,kBAAkB,GAAG,YAAY,CAAC;AAE9C;;;;;GAKG;AACH,eAAO,MAAM,oBAAoB;;iBAE/B,CAAC;AACH,+BAA+B;AAC/B,MAAM,MAAM,cAAc,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,oBAAoB,CAAC,CAAC"}

package/dist/chat.js

@@ -1,189 +0,0 @@
-/**
- * founder-schema — Chat: config, auth token, opening a conversation, participants
- *
- * Founder Circle does not run a chat server. It uses the shared one, which
- * serves several products, and that is the whole reason this file is careful:
- * when one server serves many tenants, the failure mode is SILENT. A push once
- * returned success having sent nothing, because the caller held the wrong
- * product's key and nothing in the exchange said which product it was for.
- *
- * So the rule these shapes exist to hold: TENANCY COMES FROM THE CREDENTIAL,
- * never from a request body. The token says which product it is for, the chat
- * server resolves the product from the token and from nothing else, and a
- * Founder Circle token cannot address another product's conversation even when
- * handed a valid-looking id.
- *
- * ⚠️ TEXT ONLY. There is deliberately no `callsEnabled` flag here, and its
- * absence is the feature: the user ruled chat is text only, there is no call
- * code to branch on, and the browser is told to deny camera and microphone
- * outright. A boolean that can never be true is an invitation to turn it on.
- *
- * @module founder-schema/chat
- */
-import { z } from 'zod';
-import { objectIdSchema, usernameSchema } from './common.js';
-import { CHAT_PARTICIPANTS_MAX } from './limits.js';
-/**
- * The product this package speaks for.
- *
- * Typed as a LITERAL on purpose. If the shared chat server ever hands back a
- * config or a token minted for a different product, parsing fails loudly here
- * rather than the client quietly talking to the wrong tenant. That is exactly
- * the class of bug this file exists to prevent, so it should be impossible to
- * carry past the first parse.
- */
-export const CHAT_PRODUCT_ID = 'founder-circle';
-export const chatProductIdSchema = z.literal(CHAT_PRODUCT_ID);
-// ─── Config ──────────────────────────────────────────────────────────────────
-/**
- * What the client needs before it can open a socket.
- *
- * ⚠️ `enabled` IS MANDATORY AND IS NOT DERIVED FROM `url`. "Messaging is not
- * switched on yet" is a first-class state, not a failure: a 404 is the expected
- * answer today, and the client collapses a disabled flag, a null url, a non-2xx
- * and a thrown fetch to the same quiet "not on yet" rather than an error. If
- * `enabled` were inferred from a missing url, "off" and "broken" would be the
- * same wire shape and the inbox could not tell a member which one it was.
- *
- * ⚠️ `userId` is required and is the field nothing works without. The client
- * needs to know WHO THE VIEWER IS to decide which side a bubble sits on, to
- * filter the viewer out of presence and typing, to pick the other participant
- * for a row's name and avatar, and to tell its own optimistic message from one
- * echoed back. Without it every conversation renders as though the viewer were
- * nobody. It was missing from the first sketch of this endpoint.
- */
-export const chatConfigSchema = z.object({
-    enabled: z.boolean(),
-    /** Null whenever chat is not switched on. Never a placeholder string. */
-    url: z.url().nullable(),
-    /** The VIEWER's id, as the chat server knows them. */
-    userId: z.string(),
-    /** Which product this config is for. See `chatProductIdSchema`. */
-    productId: chatProductIdSchema,
-});
-// ─── Auth token ──────────────────────────────────────────────────────────────
-/**
- * How long before expiry the client re-mints, in seconds.
- *
- * Exported because it is a contract detail and not an implementation one: a
- * token handed over with two seconds left is a socket that authenticates and is
- * closed again immediately, so the minting side needs to know the consuming
- * side will not use the last minute of a token's life.
- */
-export const CHAT_TOKEN_REFRESH_MARGIN_SECONDS = 60;
-/**
- * How often the live socket re-authenticates, in seconds.
- *
- * Auth is an EVENT on the open socket rather than a handshake parameter, so
- * re-authenticating does not drop the connection.
- *
- * ⚠️ THIS MUST STAY BELOW THE REAL TOKEN LIFETIME, by more than the refresh
- * margin. It assumes a 15 minute token. A re-auth interval longer than the
- * lifetime is a socket that dies every quarter of an hour with no explanation,
- * and the symptom appears far from the cause. If the issued lifetime changes,
- * this number moves with it or the two silently disagree.
- */
-export const CHAT_SOCKET_REAUTH_SECONDS = 10 * 60;
-/**
- * A short-lived token for the shared chat server.
- *
- * ⚠️ BOTH TIME FIELDS ARE KEPT, and they are not redundant, because two
- * different parties read them with two different clocks:
- *
- *   `expiresAt`  an absolute instant, for the SERVER. The chat server holds the
- *                authoritative clock and must reject an expired token on its
- *                own, whatever any client believes.
- *   `expiresIn`  a duration in seconds, for the CLIENT. Scheduling a refresh
- *                from `receivedAt + expiresIn` uses only the client's own
- *                elapsed time, so a device whose absolute clock is wrong still
- *                refreshes correctly. Scheduling from `expiresAt` instead means
- *                a browser an hour fast treats every fresh token as already
- *                expired and re-mints forever.
- *
- * Dropping either one breaks the party that reads it. This is the same reason
- * OAuth carries `expires_in` on the wire while the token itself carries `exp`.
- *
- * ⚠️ AND THE CLIENT IS NOT THE ENFORCER. Its margin is an optimisation to avoid
- * a pointless round trip. A wrong clock, a tab asleep for an hour, or a modified
- * client all defeat anything the client does, so the chat server rejects an
- * expired token on its own.
- */
-export const chatAuthTokenSchema = z.object({
-    token: z.string().min(1),
-    /** ISO 8601. Parsed with `Date.parse`, never an epoch number. */
-    expiresAt: z.iso.datetime(),
-    /** Seconds from issue. See the note above on why both exist. */
-    expiresIn: z.number().int().positive(),
-    /** The product this token is scoped to. A mismatch must fail loudly. */
-    productId: chatProductIdSchema,
-});
-// ─── Opening a conversation ──────────────────────────────────────────────────
-/**
- * `POST /api/v1/chat/open`: start (or find) the direct conversation with
- * another member.
- *
- * Our backend decides who may talk to whom, because only it knows this
- * product's rules, and it does the whole exchange with the chat server itself:
- * it mints the viewer's token and an invitation naming both participants, and
- * redeems them server to server. No credential reaches the browser.
- */
-export const openChatBodySchema = z.object({
-    /** The OTHER participant. The viewer is taken from the credential, never the body. */
-    userId: objectIdSchema,
-});
-/**
- * The conversation to navigate to. `201` with `wasCreated: true` the first
- * time, `200` and `false` on every later open of the same pair.
- */
-export const openChatResponseSchema = z.object({
-    conversationId: z.string().min(1),
-    wasCreated: z.boolean(),
-});
-// ─── Participants ────────────────────────────────────────────────────────────
-/**
- * `POST /api/v1/chat/participants`: names and avatars for the people in the
- * viewer's conversations.
- *
- * The chat server knows ids and nothing about who anybody is, because it serves
- * several products and identity belongs to each; so the conversation list asks
- * here, once per screen. Bounded by `CHAT_PARTICIPANTS_MAX`, so it cannot page
- * through the directory.
- */
-export const chatParticipantsBodySchema = z.object({
-    userIds: z.array(objectIdSchema).min(1).max(CHAT_PARTICIPANTS_MAX),
-});
-/** The public card fields any member already sees, and nothing more. */
-export const chatParticipantSchema = z.object({
-    displayName: z.string(),
-    username: usernameSchema,
-    /** Null when the member has no photo. Ours, or from the login provider. */
-    avatarUrl: z.url().nullable(),
-});
-/**
- * Keyed by user id. ⚠ An id with no active, onboarded profile is ABSENT, not
- * an error: the client renders it as a former member rather than guessing.
- */
-export const chatParticipantsResponseSchema = z.object({
-    participants: z.record(z.string(), chatParticipantSchema),
-});
-// ─── Deprecated ──────────────────────────────────────────────────────────────
-//
-// Unused by every consumer, and still exported: removing an export trips the
-// publish rule that refuses a release missing anything the live one has, so it
-// is the user's decision, not a side effect. They were meant to go in 0.3.0;
-// that release kept them.
-/**
- * @deprecated Since 0.2.0: use `openChatBodySchema`, the same shape under the
- * name of the route that takes it.
- */
-export const chatInvitationBodySchema = openChatBodySchema;
-/**
- * @deprecated Since 0.2.0, and it describes nothing that exists. The browser
- * never holds an invitation: `/chat/open` mints and redeems it server to
- * server. The old `/invitation` route that handed one out could never have
- * worked and is gone.
- */
-export const chatInvitationSchema = z.object({
-    invitationToken: z.string().min(1),
-});
-//# sourceMappingURL=chat.js.map

package/dist/chat.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"chat.js","sourceRoot":"","sources":["../src/chat.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;GAqBG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EAAE,cAAc,EAAE,cAAc,EAAE,MAAM,aAAa,CAAC;AAC7D,OAAO,EAAE,qBAAqB,EAAE,MAAM,aAAa,CAAC;AAEpD;;;;;;;;GAQG;AACH,MAAM,CAAC,MAAM,eAAe,GAAG,gBAAyB,CAAC;AACzD,MAAM,CAAC,MAAM,mBAAmB,GAAG,CAAC,CAAC,OAAO,CAAC,eAAe,CAAC,CAAC;AAG9D,gFAAgF;AAEhF;;;;;;;;;;;;;;;;GAgBG;AACH,MAAM,CAAC,MAAM,gBAAgB,GAAG,CAAC,CAAC,MAAM,CAAC;IACvC,OAAO,EAAE,CAAC,CAAC,OAAO,EAAE;IACpB,yEAAyE;IACzE,GAAG,EAAE,CAAC,CAAC,GAAG,EAAE,CAAC,QAAQ,EAAE;IACvB,sDAAsD;IACtD,MAAM,EAAE,CAAC,CAAC,MAAM,EAAE;IAClB,mEAAmE;IACnE,SAAS,EAAE,mBAAmB;CAC/B,CAAC,CAAC;AAGH,gFAAgF;AAEhF;;;;;;;GAOG;AACH,MAAM,CAAC,MAAM,iCAAiC,GAAG,EAAE,CAAC;AAEpD;;;;;;;;;;;GAWG;AACH,MAAM,CAAC,MAAM,0BAA0B,GAAG,EAAE,GAAG,EAAE,CAAC;AAElD;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,MAAM,CAAC,MAAM,mBAAmB,GAAG,CAAC,CAAC,MAAM,CAAC;IAC1C,KAAK,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;IACxB,iEAAiE;IACjE,SAAS,EAAE,CAAC,CAAC,GAAG,CAAC,QAAQ,EAAE;IAC3B,gEAAgE;IAChE,SAAS,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,EAAE,CAAC,QAAQ,EAAE;IACtC,wEAAwE;IACxE,SAAS,EAAE,mBAAmB;CAC/B,CAAC,CAAC;AAGH,gFAAgF;AAEhF;;;;;;;;GAQG;AACH,MAAM,CAAC,MAAM,kBAAkB,GAAG,CAAC,CAAC,MAAM,CAAC;IACzC,sFAAsF;IACtF,MAAM,EAAE,cAAc;CACvB,CAAC,CAAC;AAGH;;;GAGG;AACH,MAAM,CAAC,MAAM,sBAAsB,GAAG,CAAC,CAAC,MAAM,CAAC;IAC7C,cAAc,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;IACjC,UAAU,EAAE,CAAC,CAAC,OAAO,EAAE;CACxB,CAAC,CAAC;AAGH,gFAAgF;AAEhF;;;;;;;;GAQG;AACH,MAAM,CAAC,MAAM,0BAA0B,GAAG,CAAC,CAAC,MAAM,CAAC;IACjD,OAAO,EAAE,CAAC,CAAC,KAAK,CAAC,cAAc,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,GAAG,CAAC,qBAAqB,CAAC;CACnE,CAAC,CAAC;AAGH,wEAAwE;AACxE,MAAM,CAAC,MAAM,qBAAqB,GAAG,CAAC,CAAC,MAAM,CAAC;IAC5C,WAAW,EAAE,CAAC,CAAC,MAAM,EAAE;IACvB,QAAQ,EAAE,cAAc;IACxB,2EAA2E;IAC3E,SAAS,EAAE,CAAC,CAAC,GAAG,EAAE,CAAC,QAAQ,EAAE;CAC9B,CAAC,CAAC;AAGH;;;GAGG;AACH,MAAM,CAAC,MAAM,8BAA8B,GAAG,CAAC,CAAC,MAAM,CAAC;IACrD,YAAY,EAAE,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,MAAM,EAAE,EAAE,qBAAqB,CAAC;CAC1D,CAAC,CAAC;AAGH,gFAAgF;AAChF,EAAE;AACF,6EAA6E;AAC7E,+EAA+E;AAC/E,6EAA6E;AAC7E,0BAA0B;AAE1B;;;GAGG;AACH,MAAM,CAAC,MAAM,wBAAwB,GAAG,kBAAkB,CAAC;AAI3D;;;;;GAKG;AACH,MAAM,CAAC,MAAM,oBAAoB,GAAG,CAAC,CAAC,MAAM,CAAC;IAC3C,eAAe,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;CACnC,CAAC,CAAC","sourcesContent":["/**\n * founder-schema — Chat: config, auth token, opening a conversation, participants\n *\n * Founder Circle does not run a chat server. It uses the shared one, which\n * serves several products, and that is the whole reason this file is careful:\n * when one server serves many tenants, the failure mode is SILENT. A push once\n * returned success having sent nothing, because the caller held the wrong\n * product's key and nothing in the exchange said which product it was for.\n *\n * So the rule these shapes exist to hold: TENANCY COMES FROM THE CREDENTIAL,\n * never from a request body. The token says which product it is for, the chat\n * server resolves the product from the token and from nothing else, and a\n * Founder Circle token cannot address another product's conversation even when\n * handed a valid-looking id.\n *\n * ⚠️ TEXT ONLY. There is deliberately no `callsEnabled` flag here, and its\n * absence is the feature: the user ruled chat is text only, there is no call\n * code to branch on, and the browser is told to deny camera and microphone\n * outright. A boolean that can never be true is an invitation to turn it on.\n *\n * @module founder-schema/chat\n */\n\nimport { z } from 'zod';\nimport { objectIdSchema, usernameSchema } from './common.js';\nimport { CHAT_PARTICIPANTS_MAX } from './limits.js';\n\n/**\n * The product this package speaks for.\n *\n * Typed as a LITERAL on purpose. If the shared chat server ever hands back a\n * config or a token minted for a different product, parsing fails loudly here\n * rather than the client quietly talking to the wrong tenant. That is exactly\n * the class of bug this file exists to prevent, so it should be impossible to\n * carry past the first parse.\n */\nexport const CHAT_PRODUCT_ID = 'founder-circle' as const;\nexport const chatProductIdSchema = z.literal(CHAT_PRODUCT_ID);\nexport type ChatProductId = z.infer<typeof chatProductIdSchema>;\n\n// ─── Config ──────────────────────────────────────────────────────────────────\n\n/**\n * What the client needs before it can open a socket.\n *\n * ⚠️ `enabled` IS MANDATORY AND IS NOT DERIVED FROM `url`. \"Messaging is not\n * switched on yet\" is a first-class state, not a failure: a 404 is the expected\n * answer today, and the client collapses a disabled flag, a null url, a non-2xx\n * and a thrown fetch to the same quiet \"not on yet\" rather than an error. If\n * `enabled` were inferred from a missing url, \"off\" and \"broken\" would be the\n * same wire shape and the inbox could not tell a member which one it was.\n *\n * ⚠️ `userId` is required and is the field nothing works without. The client\n * needs to know WHO THE VIEWER IS to decide which side a bubble sits on, to\n * filter the viewer out of presence and typing, to pick the other participant\n * for a row's name and avatar, and to tell its own optimistic message from one\n * echoed back. Without it every conversation renders as though the viewer were\n * nobody. It was missing from the first sketch of this endpoint.\n */\nexport const chatConfigSchema = z.object({\n  enabled: z.boolean(),\n  /** Null whenever chat is not switched on. Never a placeholder string. */\n  url: z.url().nullable(),\n  /** The VIEWER's id, as the chat server knows them. */\n  userId: z.string(),\n  /** Which product this config is for. See `chatProductIdSchema`. */\n  productId: chatProductIdSchema,\n});\nexport type ChatConfig = z.infer<typeof chatConfigSchema>;\n\n// ─── Auth token ──────────────────────────────────────────────────────────────\n\n/**\n * How long before expiry the client re-mints, in seconds.\n *\n * Exported because it is a contract detail and not an implementation one: a\n * token handed over with two seconds left is a socket that authenticates and is\n * closed again immediately, so the minting side needs to know the consuming\n * side will not use the last minute of a token's life.\n */\nexport const CHAT_TOKEN_REFRESH_MARGIN_SECONDS = 60;\n\n/**\n * How often the live socket re-authenticates, in seconds.\n *\n * Auth is an EVENT on the open socket rather than a handshake parameter, so\n * re-authenticating does not drop the connection.\n *\n * ⚠️ THIS MUST STAY BELOW THE REAL TOKEN LIFETIME, by more than the refresh\n * margin. It assumes a 15 minute token. A re-auth interval longer than the\n * lifetime is a socket that dies every quarter of an hour with no explanation,\n * and the symptom appears far from the cause. If the issued lifetime changes,\n * this number moves with it or the two silently disagree.\n */\nexport const CHAT_SOCKET_REAUTH_SECONDS = 10 * 60;\n\n/**\n * A short-lived token for the shared chat server.\n *\n * ⚠️ BOTH TIME FIELDS ARE KEPT, and they are not redundant, because two\n * different parties read them with two different clocks:\n *\n *   `expiresAt`  an absolute instant, for the SERVER. The chat server holds the\n *                authoritative clock and must reject an expired token on its\n *                own, whatever any client believes.\n *   `expiresIn`  a duration in seconds, for the CLIENT. Scheduling a refresh\n *                from `receivedAt + expiresIn` uses only the client's own\n *                elapsed time, so a device whose absolute clock is wrong still\n *                refreshes correctly. Scheduling from `expiresAt` instead means\n *                a browser an hour fast treats every fresh token as already\n *                expired and re-mints forever.\n *\n * Dropping either one breaks the party that reads it. This is the same reason\n * OAuth carries `expires_in` on the wire while the token itself carries `exp`.\n *\n * ⚠️ AND THE CLIENT IS NOT THE ENFORCER. Its margin is an optimisation to avoid\n * a pointless round trip. A wrong clock, a tab asleep for an hour, or a modified\n * client all defeat anything the client does, so the chat server rejects an\n * expired token on its own.\n */\nexport const chatAuthTokenSchema = z.object({\n  token: z.string().min(1),\n  /** ISO 8601. Parsed with `Date.parse`, never an epoch number. */\n  expiresAt: z.iso.datetime(),\n  /** Seconds from issue. See the note above on why both exist. */\n  expiresIn: z.number().int().positive(),\n  /** The product this token is scoped to. A mismatch must fail loudly. */\n  productId: chatProductIdSchema,\n});\nexport type ChatAuthToken = z.infer<typeof chatAuthTokenSchema>;\n\n// ─── Opening a conversation ──────────────────────────────────────────────────\n\n/**\n * `POST /api/v1/chat/open`: start (or find) the direct conversation with\n * another member.\n *\n * Our backend decides who may talk to whom, because only it knows this\n * product's rules, and it does the whole exchange with the chat server itself:\n * it mints the viewer's token and an invitation naming both participants, and\n * redeems them server to server. No credential reaches the browser.\n */\nexport const openChatBodySchema = z.object({\n  /** The OTHER participant. The viewer is taken from the credential, never the body. */\n  userId: objectIdSchema,\n});\nexport type OpenChatBody = z.infer<typeof openChatBodySchema>;\n\n/**\n * The conversation to navigate to. `201` with `wasCreated: true` the first\n * time, `200` and `false` on every later open of the same pair.\n */\nexport const openChatResponseSchema = z.object({\n  conversationId: z.string().min(1),\n  wasCreated: z.boolean(),\n});\nexport type OpenChatResponse = z.infer<typeof openChatResponseSchema>;\n\n// ─── Participants ────────────────────────────────────────────────────────────\n\n/**\n * `POST /api/v1/chat/participants`: names and avatars for the people in the\n * viewer's conversations.\n *\n * The chat server knows ids and nothing about who anybody is, because it serves\n * several products and identity belongs to each; so the conversation list asks\n * here, once per screen. Bounded by `CHAT_PARTICIPANTS_MAX`, so it cannot page\n * through the directory.\n */\nexport const chatParticipantsBodySchema = z.object({\n  userIds: z.array(objectIdSchema).min(1).max(CHAT_PARTICIPANTS_MAX),\n});\nexport type ChatParticipantsBody = z.infer<typeof chatParticipantsBodySchema>;\n\n/** The public card fields any member already sees, and nothing more. */\nexport const chatParticipantSchema = z.object({\n  displayName: z.string(),\n  username: usernameSchema,\n  /** Null when the member has no photo. Ours, or from the login provider. */\n  avatarUrl: z.url().nullable(),\n});\nexport type ChatParticipant = z.infer<typeof chatParticipantSchema>;\n\n/**\n * Keyed by user id. ⚠ An id with no active, onboarded profile is ABSENT, not\n * an error: the client renders it as a former member rather than guessing.\n */\nexport const chatParticipantsResponseSchema = z.object({\n  participants: z.record(z.string(), chatParticipantSchema),\n});\nexport type ChatParticipantsResponse = z.infer<typeof chatParticipantsResponseSchema>;\n\n// ─── Deprecated ──────────────────────────────────────────────────────────────\n//\n// Unused by every consumer, and still exported: removing an export trips the\n// publish rule that refuses a release missing anything the live one has, so it\n// is the user's decision, not a side effect. They were meant to go in 0.3.0;\n// that release kept them.\n\n/**\n * @deprecated Since 0.2.0: use `openChatBodySchema`, the same shape under the\n * name of the route that takes it.\n */\nexport const chatInvitationBodySchema = openChatBodySchema;\n/** @deprecated Since 0.2.0: use `OpenChatBody`. */\nexport type ChatInvitationBody = OpenChatBody;\n\n/**\n * @deprecated Since 0.2.0, and it describes nothing that exists. The browser\n * never holds an invitation: `/chat/open` mints and redeems it server to\n * server. The old `/invitation` route that handed one out could never have\n * worked and is gone.\n */\nexport const chatInvitationSchema = z.object({\n  invitationToken: z.string().min(1),\n});\n/** @deprecated Since 0.2.0. */\nexport type ChatInvitation = z.infer<typeof chatInvitationSchema>;\n"]}