Skip to main content

browserClient

Initialize with initializeFromShyConfig — see the Web SDK overview for the common setup pattern.

Non-standard options for this client: deriveSealerKey.

Initialize​

const client = initializeFromShyConfig(shyconfig, {
  getAuthHeaders: async () => ({ Authorization: `Bearer ${token}` }),
  deriveSealerKey: async () => derivedKeyMaterial
});

const state = client.initialize();
// → { contractVersion, productType, apiBase, sealerMode }

Store sealed browser data​

const record = await client.storeSealedBrowserData({
  payload: { page: "/checkout", duration_ms: 4200, referrer: "email" },
  category: "pageview"
});
// → { recordID, sealed: true }

The payload is encrypted client-side before transmission. The ABCI layer writes only ciphertext to List 1. No plaintext analytics data is ever stored on the canonical ledger or observable by the operator from canonical state alone.

Read stored browser data​

const records = await client.getStoredBrowserData();
const decrypted = await client.getStoredBrowserDataDecrypted();

getStoredBrowserData returns the sealed envelopes. getStoredBrowserDataDecrypted additionally applies deriveSealerKey to decrypt each record client-side.

Submit a List 2 identity attribute​

await client.submitList2IdentityAttribute({
  attributeHash: sha256(subClaim + scopingId)
});

In shybrowser, both List 1 (sealed payload) and List 2 (sealed identity attribute) are sealed by the operator-supplied sealer. The identity attribute is server-supplied from request metadata — the participant device does not generate it. This is the dual-sealing pattern.

Structural properties​

  • Sealed canonical payload — analytics content is AES-GCM encrypted before any canonical write; the operator cannot enumerate analytics payloads from canonical state
  • Sealed List 2 identity attribute — identity is server-derived and sealed; participants cannot be linked across sessions from canonical state alone
  • No rescission pathway — TxTypeAuthorityRescind unavailable; erasure = sealer key deletion
  • Structurally write-only on browser — no receipt confirmation; web cannot satisfy non-write-only assurance. See Write-only posture