Encryption, devices and recovery
Wallet or Google sign-in authorizes access to encrypted records. A wallet address is public and is not an encryption key. Dr. Nib uses random browser-vault and project-key material; changing a login method does not make research content readable without the appropriate vault unlock.
The Projects page groups private projects under vault folders. You can create a fresh vault under the same signed-in account when the old vault cannot be unlocked, then switch between folders. Each vault has its own password, backup code and optional passkey. Switching selects which vault’s projects to show and where new projects are created; it never decrypts, moves, resets or erases projects in another vault. The selected vault follows the account across devices, so refresh other open tabs after switching. If you later find an old vault’s unlock method, select that folder and unlock it. Creating or switching vaults requires no onchain transaction. Keep the original vault and its encrypted records intact.
Passwords, backup codes and enrolled browsers
New private vaults require a user-chosen, strong private-project password. It is separate from wallet or Google sign-in. The setup requires at least 15 characters, rejects predictable choices with a password-strength check, and asks for confirmation. Long passphrases and password managers work; special characters or capitals are not required. A separately saved random backup code is also required and must be confirmed. Both unlock the same encrypted vault on a new browser after normal account sign-in. The password is used only in the browser to derive a key with a unique salt and 600,000 PBKDF2-HMAC-SHA-256 iterations; Nibgate stores encrypted wrappers, never the password or plaintext vault key. A weak password is vulnerable to offline guessing if encrypted records leak, so do not reuse a login password. Existing code-only vaults remain code-only until an enrolled browser explicitly replaces their recovery credentials.
An enrolled browser keeps a random non-extractable vault key in IndexedDB. Independent random project seeds protect project content. A password or backup code opens the vault; neither changes the project seeds. Help can also add an optional WebAuthn PRF recovery passkey after the vault is unlocked. The browser tests an assertion before saving the passkey’s encrypted vault-key wrapper. Nibgate stores the credential ID, random salt and ciphertext, never the PRF output or plaintext key. An ordinary passkey without PRF support cannot recover private projects. Passkeys are bound to their site: nibgate.xyz and testnet.nibgate.xyz need separate enrollment.
The Dr. Nib Help page starts with a recovery guide and checks whether the current browser and signed-in account can replace lost credentials. Its button remains unavailable unless the browser has a usable enrolled key. Checking does not unlock a vault or rotate a key.
| What you still have | What to do |
|---|---|
| An enrolled browser that opens these private projects | Open Help in that same browser, choose Replace password and backup code, set a strong new password, save and confirm the new backup code, and wait for confirmation. Existing project content is preserved. |
| The private-project password, backup code or an enrolled recovery passkey, but no enrolled browser | Sign in to the same account on a new browser, open Help and choose Unlock this vault. Use an available unlock method. Older code-only vaults use their existing recovery code. A passkey works on another device only when that same credential and its PRF output are available there. |
| No enrolled browser, password, backup code or previously enrolled passkey | The old encrypted content cannot be decrypted by Nibgate or reset through wallet sign-in. Preserve old devices and browser data while checking for an enrolled browser. |
The private-project password and backup code are not a wallet seed phrase or wallet recovery phrase. Never type a wallet phrase into Dr. Nib’s vault prompt. Older testnet Legacy history is a separate plaintext archive and does not use the private vault.
Save both credentials privately. Nibgate should never ask you to paste them into chat, support messages, logs or a research prompt. If every enrolled device, saved credential and enrolled passkey is lost, Nibgate cannot recover the content. A server-side password reset would only permit a new vault; it could not decrypt old projects. A wallet signature proves account control but does not derive the vault key.
From an already enrolled browser, Help supports replacing the password and backup code together. The operation preserves project seeds and content, includes deleted projects and atomically replaces encrypted wrappers and the recovery record. Old/pending local keys remain available until the server commit is confirmed. Only treat replacement as complete after the app confirms it. Replacement removes the old passkey wrapper; add and test a new passkey afterward if desired.
A new browser must complete both account sign-in and vault recovery before it can read encrypted projects. Wallet extensions have their own browser permissions, including Incognito access; those settings are separate from project encryption.
Pauses and failures
| Situation | Expected behavior |
|---|---|
| User pauses or a question needs an answer | Checkpoint work, show the actual question/reply history, stop research until resumed |
| Tab reload or temporary disconnect | Read encrypted saved state and reconnect; do not erase completed work |
| Worker restart | Verify the fresh worker and restore authenticated completed operations before doing new work |
| Known completed model/tool/payment operation | Reuse its recorded result and charge; do not purchase it again |
| Interrupted model completion with no saved result | After the old worker lease expires, allow at most two model-only replacements; retain the full unknown cost under the operator cap, never the customer escrow |
| Uncertain tool or payment outcome | Preserve reservation/checkpoint and reconcile; never repeat the operation blindly |
| Definite supported rate-limit rejection | Apply bounded recovery; any unresolved provider cost remains operator exposure rather than a fabricated zero bill |
| Resumable infrastructure failure | Preserve escrow; do not terminate and refund merely because recovery is needed |
Processing keys are delivered by an authorized browser after verification. A live worker can use keys already delivered for its authorized action while they remain in memory. After a stop/crash loses in-memory keys, the user may need to reconnect and unlock before processing resumes. Nibgate does not hold an operator master decryption key.
Active-work duration excludes recorded owner waits and offline gaps. Activity is encrypted project history, including model-authored summaries, decisions and tool observations. It is not a transcript of hidden internal reasoning.
Existing projects
Encryption follows the processing path used when a project is created. Changing a UI setting does not retroactively encrypt previously stored plaintext. Ordinary API/MCP access is not an alternate way to bypass a private project’s vault.