key

Client key used to identify the client. If not set, a random key is generated — generateClientKey, freshly minted per Client instance, so it differs on every launch.

Offline persistence requires a stable key: the server derives the actor stamped into every change from the project and this key, and it also scopes the docStore keys (apiKey/clientKey/docKey, Client.storeKey). A new key therefore does not address the previous launch's entries at all — the restore finds nothing, the un-pushed edits are lost silently (no actor-mismatch diagnostic fires: that guard in Document.restoreFromBytes only fires when the same store key is reached under a different actor, which a fresh key by definition never does), and the previous namespace is orphaned. DocStore exposes no enumeration or prune, so nothing can reclaim those entries afterwards — a durable backend grows without bound, one dead namespace per launch.

An app setting docStore must therefore pass a key it persists itself and reuses on the next launch. Make it an opaque random value the app mints once — a UUID.randomUUID() kept in local storage, say — scoped to the signed-in user and cleared on sign-out. Do not derive it from a user id, a device id, an email, or anything else guessable or shared:

• The key is an identifier, not a credential. It is sent verbatim in the activate request and nothing proves the caller owns it, so a guessable key lets another client of the same project activate under the same derived actor and attribute changes to it.

• A key shared between users of one device gives them one store namespace: attachDocument loads and rehydrates the persisted bytes locally before the attach RPC, so the previous user's document content and un-pushed edits would surface in the next user's session ahead of any server authorization.

Ported from JS client.ts's rewritten ClientOptions.key JSDoc (3b9c668c/#1402).