# Redeemable Board Invitations — Step 1: Solution Assessment

## Problem Statement

An approved user should be able to invite a recipient who creates a new,
disposable browser-key identity and is then automatically approved and signed
into the private board.

## Option A — Signed, single-use invitation bound to the new identity

An approved inviter creates a signed invitation containing a commitment to a
high-entropy secret. The recipient opens the Lobby, chooses a username (or a
clearly temporary display name), proves control of a browser key, and redeems
the secret; redemption consumes the invitation and creates the inviter's
attributable approval for that identity.

- Pros:
  - Implements the proposed reverse-approval experience without making a link
    itself a durable logged-in session.
  - Preserves a clear chain: inviter → invitation → verified recipient key →
    approved identity.
  - Allows one-time use, expiry, revocation, and an auditable inviter.
- Cons:
  - Adds an invitation lifecycle beyond the existing approval flow.
  - A forwarded, unredeemed secret can be claimed by the first recipient.

## Option B — Operator-issued generic redemption codes

Operators issue codes from a central tool; recipients redeem them through the
same identity-creation and authentication flow.

- Pros:
  - Simple authority model and centralized oversight.
  - Useful when ordinary members must not invite others.
- Cons:
  - Does not satisfy the approved-user-as-inviter model.
  - Loses the social attribution that the inviter's signed record provides.

## Option C — Lobby link only

Share `/lobby/` and retain the normal separate approval workflow.

- Pros:
  - Uses the existing Lobby without new invitation lifecycle rules.
- Cons:
  - Does not automatically approve or sign in the recipient.
  - Leaves the operator or inviter with a separate approval action.

## Recommendation

Choose **Option A**. The recipient must first have a distinct browser-key
identity; a shared `guest` login should not be used because it removes
accountability and prevents reliable revocation. Let the recipient choose a
username during that flow, subject to normal uniqueness rules, with a
temporary generated label only if the product needs one.

The unhashed secret is a bearer credential: it must be submitted only to the
redemption flow, never included in a public post, URL query, logs, or the
canonical approval record. The invitation must be atomic single-use, expiring
and revocable, and result in an authenticated session only after the browser
proves possession of the bound key. A stored hash/commitment is appropriate
only when the original secret has sufficient unpredictable entropy.