Host-asserted feedback identity

Feature-request boards need to know who submitted and who voted. Building a second login just for feedback is usually wrong when your SaaS already has sessions.

Bootstrapware Feedback does not authenticate board end users. Your host app asserts identity on every render:

user={{ id: "opaque-stable-id", name: "Ada" }}

Fields

Field	Role
id	Required. Opaque and stable for the same person across sessions.
name	Optional display metadata.
email	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 board enables `requireAuthorToken`.

Why opacity matters

Prefer internal ids (user_…, UUID) over emails as id. Votes and posts are keyed by that string. If the id changes when someone renames their display name, they look like a new voter.

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, and treat BYO Route Handlers as the place to re-bind authorship to the real session.

Hosted rate limits (roughly 30 creates / 120 other actions per minute per board) reduce abuse but do not replace origin controls. See security.

Example from a session

<Feedback
  boardId="brd_..."
  publishableKey={process.env.NEXT_PUBLIC_BSW_PUBLISHABLE_KEY!}
  user={
    session
      ? { id: session.userId, name: session.displayName }
      : null
  }
/>

Passing user= is valid when you want a signed-out empty state; submissions still need a user when your board disallows anonymous posts.

Pitfalls

Using email as id and then allowing email changes without migration.
Trusting client-supplied author on BYO endpoints without session checks.
Skipping authorToken on a board with requireAuthorToken enabled. Mint it server-side with your secret key.

Related: Identity docs · Security · Origins · Adapter · Voting