decane-connect-kit 2.6.0 → 2.6.2

package/dist/index.d.cts

@@ -442,22 +442,6 @@ interface DecaneConnectConfig {
     }>;
     /** Recovery stage callbacks, for dApp UI. */
     onRecoveryProgress?: (event: RecoveryProgress) => void;
-    /**
-     * Let the enclave hand a device a working share on the strength of a valid
-     * login alone — no synced passkey, no recovery file, nothing for the user to
-     * keep. Default TRUE, because a wallet a person cannot re-enter after
-     * clearing their browser is worse than useless to them.
-     *
-     * The trade, stated plainly: enrolling stores a second Shamir share sealed to
-     * the enclave, so the enclave can reconstruct a wallet by itself. It is sealed
-     * with a key derived inside the TEE, so your backend and its database still
-     * cannot — but a malicious enclave image, or anyone able to mint JWTs, could.
-     *
-     * Set false to keep the stricter property that no single party can
-     * reconstruct. Users then need a synced passkey or their recovery file on
-     * every new device, and losing both means losing the wallet.
-     */
-    serverAssistedRecovery?: boolean;
     /**
      * Rotate the whole share set whenever a NEW device recovers via passkey sync
      * (Flow A) — the "every device holds a distinct share" model.

package/dist/index.d.ts

@@ -442,22 +442,6 @@ interface DecaneConnectConfig {
     }>;
     /** Recovery stage callbacks, for dApp UI. */
     onRecoveryProgress?: (event: RecoveryProgress) => void;
-    /**
-     * Let the enclave hand a device a working share on the strength of a valid
-     * login alone — no synced passkey, no recovery file, nothing for the user to
-     * keep. Default TRUE, because a wallet a person cannot re-enter after
-     * clearing their browser is worse than useless to them.
-     *
-     * The trade, stated plainly: enrolling stores a second Shamir share sealed to
-     * the enclave, so the enclave can reconstruct a wallet by itself. It is sealed
-     * with a key derived inside the TEE, so your backend and its database still
-     * cannot — but a malicious enclave image, or anyone able to mint JWTs, could.
-     *
-     * Set false to keep the stricter property that no single party can
-     * reconstruct. Users then need a synced passkey or their recovery file on
-     * every new device, and losing both means losing the wallet.
-     */
-    serverAssistedRecovery?: boolean;
     /**
      * Rotate the whole share set whenever a NEW device recovers via passkey sync
      * (Flow A) — the "every device holds a distinct share" model.

package/dist/index.js

@@ -2833,7 +2833,7 @@ function buildAuthUrl(clientId, scopes) {
   return url.toString();
 }
 function loginWithKingsChatPopup(opts) {
-  const scopes = opts.scopes ?? ["send_chat_message"];
+  const scopes = opts.scopes ?? ["profile"];
   const popup = window.open(
     buildAuthUrl(opts.clientId, scopes),
     "decane-kingschat",
@@ -3413,7 +3413,7 @@ async function createDecaneConnect(config) {
   let persisted = loadPersisted(PERSIST_KEY);
   let ethProvider = null;
   const persistSession = config.persistSession !== false;
-  const serverAssistedRecovery = config.serverAssistedRecovery !== false;
+  const serverAssistedRecovery = true;
   const SESSION_KEY = sessionPersistKey(config.apiKey);
   function persistLiveSession() {
     if (!persistSession) return;