decane-connect-kit 2.6.0 → 2.6.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/dist/index.d.cts CHANGED
@@ -442,22 +442,6 @@ interface DecaneConnectConfig {
442
442
  }>;
443
443
  /** Recovery stage callbacks, for dApp UI. */
444
444
  onRecoveryProgress?: (event: RecoveryProgress) => void;
445
- /**
446
- * Let the enclave hand a device a working share on the strength of a valid
447
- * login alone — no synced passkey, no recovery file, nothing for the user to
448
- * keep. Default TRUE, because a wallet a person cannot re-enter after
449
- * clearing their browser is worse than useless to them.
450
- *
451
- * The trade, stated plainly: enrolling stores a second Shamir share sealed to
452
- * the enclave, so the enclave can reconstruct a wallet by itself. It is sealed
453
- * with a key derived inside the TEE, so your backend and its database still
454
- * cannot — but a malicious enclave image, or anyone able to mint JWTs, could.
455
- *
456
- * Set false to keep the stricter property that no single party can
457
- * reconstruct. Users then need a synced passkey or their recovery file on
458
- * every new device, and losing both means losing the wallet.
459
- */
460
- serverAssistedRecovery?: boolean;
461
445
  /**
462
446
  * Rotate the whole share set whenever a NEW device recovers via passkey sync
463
447
  * (Flow A) — the "every device holds a distinct share" model.
package/dist/index.d.ts CHANGED
@@ -442,22 +442,6 @@ interface DecaneConnectConfig {
442
442
  }>;
443
443
  /** Recovery stage callbacks, for dApp UI. */
444
444
  onRecoveryProgress?: (event: RecoveryProgress) => void;
445
- /**
446
- * Let the enclave hand a device a working share on the strength of a valid
447
- * login alone — no synced passkey, no recovery file, nothing for the user to
448
- * keep. Default TRUE, because a wallet a person cannot re-enter after
449
- * clearing their browser is worse than useless to them.
450
- *
451
- * The trade, stated plainly: enrolling stores a second Shamir share sealed to
452
- * the enclave, so the enclave can reconstruct a wallet by itself. It is sealed
453
- * with a key derived inside the TEE, so your backend and its database still
454
- * cannot — but a malicious enclave image, or anyone able to mint JWTs, could.
455
- *
456
- * Set false to keep the stricter property that no single party can
457
- * reconstruct. Users then need a synced passkey or their recovery file on
458
- * every new device, and losing both means losing the wallet.
459
- */
460
- serverAssistedRecovery?: boolean;
461
445
  /**
462
446
  * Rotate the whole share set whenever a NEW device recovers via passkey sync
463
447
  * (Flow A) — the "every device holds a distinct share" model.
package/dist/index.js CHANGED
@@ -3413,7 +3413,7 @@ async function createDecaneConnect(config) {
3413
3413
  let persisted = loadPersisted(PERSIST_KEY);
3414
3414
  let ethProvider = null;
3415
3415
  const persistSession = config.persistSession !== false;
3416
- const serverAssistedRecovery = config.serverAssistedRecovery !== false;
3416
+ const serverAssistedRecovery = true;
3417
3417
  const SESSION_KEY = sessionPersistKey(config.apiKey);
3418
3418
  function persistLiveSession() {
3419
3419
  if (!persistSession) return;