Support Ticket Anonymity

When a Visitor contacts a Malet's support team through uChat, the platform shields their real identity behind a pseudo-anonymous alias. The Malet Owner sees a stable, deterministic alias (e.g., Customer-A7x3B) instead of the Visitor's name, email, or phone number. If the Visitor needs more hands-on help — a refund, delivery correction, or callback — they can explicitly share their real contact info on a per-conversation basis via a one-way door mechanism.

This architecture ensures Malet Owners can track support history across conversations without mining real consumer identities.

Architecture Overview

The system consists of three entities in the nodes subgraph:

┌─────────────────────────────────────┐
│         SupportAlias Entity         │
│                                     │
│  userId ──────── real consumer ID   │
│  subjectId ───── Malet/Org scope    │
│  alias ───────── Customer-XXXXX     │
│                                     │
│  Unique index: (userId, subjectId)  │
└─────────────────────────────────────┘

┌─────────────────────────────────────┐
│     SupportContactShare Entity      │
│                                     │
│  userId ──────── consumer ID        │
│  issueId ──────  conversation ID    │
│  sharedAt ────── timestamp          │
│                                     │
│  Unique index: (userId, issueId)    │
└─────────────────────────────────────┘

Key Properties

• Deterministic: Same consumer always appears as the same alias on a given Malet (stable across sessions).
• Scoped: Aliases are per (userId, subjectId) pair — a Visitor has different aliases on different Malets.
• Idempotent: getOrCreateAlias handles race conditions via unique index + catch-and-retry.
• One-way door: Once contact info is shared on a conversation, it cannot be revoked.

GraphQL API

Queries

# List all support aliases for the authenticated user
query MySupportAliases {
  mySupportAliases {
    userId
    subjectId
    alias
    createdAt
  }
}

Federated ResolveFields on User

The SupportProxyResolver extends the User type with federated fields that enforce privacy gates:

# Get alias for a specific Malet (creates if needed)
type User {
  supportAlias(subjectId: ID!): String

  # Real email — only if consumer shared contact on this issue
  supportContactEmail(issueId: ID!): String

  # Real phone — only if consumer shared contact on this issue
  supportContactPhone(issueId: ID!): String
}

Mutations

# One-way door: share real contact info on a support conversation
mutation ShareSupportContact($issueId: ID!) {
  shareSupportContact(issueId: $issueId) {
    isNewShare
    issueId
  }
}

The issueId for the shareSupportContact mutation maps to the uChat conversation ID. When a Visitor opens a SUPPORT type conversation in uChat, that conversation's id is passed as the issueId.

Frontend Integration

Query Module

All GraphQL operations are defined in src/lib/queries/supportAlias.ts:

import {
  MY_SUPPORT_ALIASES,
  SHARE_SUPPORT_CONTACT,
  type SupportAlias,
  type MySupportAliasesResponse,
  type ShareSupportContactResponse
} from '$lib/queries/supportAlias';

Settings → Privacy Panel

The SupportAliasSection.svelte component renders in Settings → Privacy & Security, between Content Visibility and Two-Factor Authentication. It shows:

1. Info card explaining the anonymity system in plain language
2. Alias table (expandable) listing all aliases with Malet scope and creation date
3. Empty state for users with no support interactions yet

uChat Support Banner

When a Visitor opens a SUPPORT conversation in uChat, a banner appears between the header and the message area:

• 🛡️ "You're anonymous in this conversation" — explains that the Malet Owner sees their alias
• "Share my contact info" button — triggers shareSupportContact with the conversation ID
• Browser confirm() dialog warns this is a one-way door
• After sharing, the button is replaced with a green "✓ Contact shared" badge

Privacy Gate Flow

Visitor opens SUPPORT conversation
    │
    ▼
Banner shows: "You're anonymous"
    │
    ├── Visitor sends messages → Owner sees "Customer-A7x3B"
    │
    ├── Visitor clicks "Share my contact info"
    │       │
    │       ▼
    │   confirm() dialog warns of one-way door
    │       │
    │       ▼
    │   shareSupportContact(issueId: conversationId)
    │       │
    │       ▼
    │   Owner can now query supportContactEmail / supportContactPhone
    │
    └── Visitor does nothing → Owner never sees real identity

Backend Implementation

Alias Generation

Aliases use nanoid with a 5-character alphanumeric suffix:

const ALIAS_PREFIX = 'Customer';
const nanoid = customAlphabet(
  'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789',
  5
);
// Result: "Customer-A7x3B"

Race Condition Handling

The getOrCreateAlias method handles concurrent requests gracefully:

1. Try findOne for existing alias
2. If not found, create with the generated alias
3. If a 11000 (duplicate key) error fires, another request won the race — fetch the winning record

File Map

Related

• Privacy & Security APIs — Content visibility matrix, profile privacy toggles, and GDPR data controls
• uChat Client SDK — E2EE messaging infrastructure, conversation types, and SUPPORT conversation flow
• User Identity Resolution — Shared profileResolver.ts that prevents raw UUID exposure across UI surfaces
• Handle System & Sigil Taxonomy — Pipe sigil taxonomy (v|handle) used for user identification