# Accounts & guest conversations

Keep account history scoped and guest linking explicit.

Version 0.1.0 · Early pilot · unreleased SDK · Reviewed 4 November 2026

## Register when Help opens

Creating a LobbyClient or fetching public configuration does not register a customer. Opening Help registers a guest installation. The public configuration ID selects an app and environment; it grants no transcript access.

## Verified identity: implemented and pending boundaries

The PostgreSQL API, MongoDB hosting service and Swift client implement one-use, session-bound challenges, short-lived host-signed assertions and explicit guest linking. The host backend must authenticate its own user before signing; email, metadata and display names never prove identity. MongoDB stores the per-app host key encrypted, with owner-only configuration, reveal and rotation. Missing host configuration fails closed. The expanded MongoDB identity flow passes isolated API tests; deployment and each merchant’s actual backend integration need their own exchange/link canary.

## Link only with consent

Signing in leaves guest conversations separate by default in the implemented identity flows. Explicit linking needs the current guest proof and a fresh assertion for the link purpose. Original authors and separate thread IDs remain intact. Never collect guest transcripts by matching an email.

## Customer context is not identity

The Swift client stages customer labels, device context, reported provider IDs and up to 20 bounded metadata pairs without registering a guest before Help. Call setMetadata, setCustomerDetails, setDeviceContext or setReportedProviderIDs; invalid input preserves the previous values. Supplied maps are complete replacements, including an empty map to clear. Once a session exists, profile synchronization saves the exact attempted payload, revision and request key before networking; a lost response retries that envelope before newer changes. Native profile synchronization was observed against the hosted development API. Labels and reported provider IDs never prove identity, grant history or establish a subscription; trusted bindings require separate server proof.

## Recover a failed identity change

A failed host assertion keeps the valid guest and draft. A fresh identify call refreshes expired access before asking for its challenge. If an accepted handover response is lost, the client retains the original route, body, key and old proof in Keychain and replays that exact attempt with the same explicit guest-link choice. Confirm the same host account is still active before retrying; an actual account switch calls reset. Successful handover never revokes the predecessor again, because that would revoke its successor family. Recovery expiry does not silently register a new guest.

## Account switch

Call resetForAccountSwitch synchronously when the host logs out or switches accounts. The SDK fences in-flight work, clears scoped private data and queues remote revocation. A secure-storage reset marker prevents an old account from returning after a temporary Keychain deletion failure. Keychain unavailable or corrupt proof is a retry condition, not permission to create a fresh guest. Already accepted old-account messages remain with that old account; reset is not server deletion.

```
support.resetForAccountSwitch()
```