cumarsaide · cts
Open with wallet

For merchants · Aithne ecosystem

Offer your users anonymous communications — without their data touching you or us.

Integrate the Aithne PPIL client, hold the cts-api-key-cumarsaide license, and broker pseudonymous relay conversations between your site and your users. Signing stays under your control. No PII enters your schema or ours.

Trust without data

Your users don't hand over email or phone to talk to you. Trust is the wallet PIC — a verified credential, not a form field.

Merchant-controlled signing

Your signing keys and hooks stay in your systems or HSM. The client never holds your private keys — signing happens in your hooks.

Spec-conformant relay

A single requestRelay call opens a signed, ephemeral relay via PPIL — with callbacks wired into your correlation state.

Integrate in five steps

All integration happens under merchant control. No PII enters the contract.

  1. Install the client

    npm install @aithne/ppil-client // high-throughput PPIL client — relay, verify, callbacks

  2. Configure the license

    Key id cts-api-key-cumarsaide, configured server-side in config/ppil-client-config.json or env. Never in client bundles or repos.

  3. Implement merchant hooks

    authenticatePIC, getSignedPIC (signing via external signer/HSM), correlation/session storage, and optional signalCorrelation. The client throws if required hooks are missing.

    Hooks run under merchant control. Your signing keys never ship to CTS or the browser.

  4. Wire callbacks

    CTS pushes relay events to POST {merchant}/ppil/cts-callback; persist via setCorrelation, notify via signalCorrelation (its failure doesn't fail the callback). Idempotent on correlationId.

  5. Go live — zero-PII clean

    Verify with contract tests; ensure no raw tokens in logs (maskSensitive → abc****xyz), no PII fields in your schema, and your signing keys never ship to CTS or the browser.

Contract reference

All values are structural references — no real keys or tokens appear in this documentation.

ItemContract
EndpointPOST /cts/ppil/comm/request-relay
Auth headerAPI key — key id cts-api-key-cumarsaide (value configured server-side)
Required headercorrelationId — non-empty; drives idempotency/retry
Body{ pptId, purpose, commToken, addrToken }
CallbackPOST {merchant}/ppil/cts-callback — correlation/relay payloads
Token handlingephemeral · server-side verified · masked in logs (abc****xyz)

Your signing keys never enter these calls. Signing happens in your hooks. The client never logs raw tokens.

Request example

import PPILClient from '@aithne/ppil-client';

const client = new PPILClient('./config/ppil-client-config.json');
await client.register(app, './config/ppil-hooks.js');

await client.requestRelay({
  pptId,          // from wallet PIC
  purpose: 'order_support',
  correlationId: crypto.randomUUID(),
  commToken,     // wallet-issued, ephemeral
  addrToken      // routing scope, ephemeral
});

Your signing keys never enter this call — signing happens in your hooks.

Your side

Keep signing keys under merchant control — external signer or HSM.
Mask tokens in logs — maskSensitive → abc****xyz.
Correlation state without PII — hashed pseudonymous ids only.
Respond to callbacks idempotently — keyed on correlationId.

Our side

Verify PIC/comm/addr server-side — against ecosystem trust anchors.
Mint ephemeral relays with TTL + revocation — short-lived by design.
Store hashed pseudonymous ids only — append-only, non-PII audit.
Never inspect message content — routes opaquely, per spec.

Both sides share one absolute: no PII is collected, stored, or logged — anywhere in the flow.

Licensing & status

CTS · cts-api-key-cumarsaide Operational

Merchant onboarding is wallet-based and managed through the Aithne ecosystem. To begin, get the wallet — no email or phone form.

Open Aithne Wallet

How it works · Privacy