Host-asserted chat identity
In-product chat needs to know who is sending. Building a second login just for messaging is usually wrong when your SaaS already has sessions.
Bootstrapware Chat does not authenticate end users. Your host app asserts identity on every render:
user={{ id: "opaque-stable-id", name: "Ada" }}Anonymous chat is not supported. Pass the same stable id you use in your product. Do not invent ids.
Fields
| Field | Role |
|---|---|
| id | Required. Opaque and stable for the same person across sessions. |
| name | Optional display metadata. |
| Optional display metadata, not used as auth. | |
| avatarUrl | Optional display metadata. |
| authorToken | Host-signed assertion from POST /api/v1/author-tokens (secret key). Required when the app enables requireAuthorToken. |
Why opacity matters
Prefer internal ids (user_…, UUID) over emails as id. Membership and unread are keyed by that string. If the id changes when someone renames their display name, they look like a new person.
Threat model
Publishable keys may appear in the browser. If a publishable key leaks, a client can forge author.id against Hosted APIs. Mitigate with allowed origins, keep secret keys server-side, enable requireAuthorToken for production Hosted, and treat BYO Route Handlers as the place to re-bind authorship to the real session.
Reference: identity docs.
Related: Identity docs · Security · API keys · Embed-only