Skip to main content

chatClient

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

Non-standard options for this client: deriveSealerKey.

Initialize​

import { initializeFromShyConfig } from "shyware/sdk/web/chatClient.js";

const client = initializeFromShyConfig(shyconfig);
const state = client.initialize();

The returned state includes:

  • surfaceModel
  • accountModel
  • participantBinding
  • payloadModel
  • auditModel
  • allowedPayloadFormats

Queue a dispatch​

await client.queueDispatch({
  mailboxId: "mbx-001",
  recipientAddress: "operations@confidential.example",
  subject: "Case packet",
  body: "Readable content stays sealed off-canonical.",
  deliveryWindow: "next attested close",
  contentClass: "report",
  payloadFormat: "json_form",
  privateFields: {
    case_id: "case-001",
    reporter_email: "source@example.com"
  },
  auditMode: "delivery_commitment_only",
  attachmentRefs: ["ipfs://sealed-packet-001"]
});

Audit model​

shychat separates the canonical audit surface from the private payload surface.

  • delivery_commitment_only
    • canonical audit includes delivery continuity and payload commitments only
  • delivery_metadata_commitment
    • canonical audit may additionally include safe descriptors such as content_class and payload_format

Readable content, structured private fields, and attachment references remain sealed off-canonical under payload_model: "sealed_private_content".

Community launch, later migration​

shychat is a natural fit for the community deployment tier: a tenant can launch on a shared chain with a tenant manifest and tenant subdomain first, then later move to dedicated or self-hosted infrastructure. See Community-to-dedicated migration for the current cutover design, the new Scytale checkpoint/export/import CLI, and what still remains for full cross-chain bootstrap continuity. The same import/export path works in reverse if a tenant later wants to move back into community hosting without giving up continuity.