Example: Chat App

Slack-like messaging with subgroups, ReadOnly channels, and cross-context mentions

Group Hierarchy

Org tree for Acme Corp. Subgroups nest under the root; each group owns its own contexts and governance topic.

Acme Corp root
├── Engineering
│ ├── Platform Team
│ └── Frontend Team
├── Marketing
└── Leadership

Membership flows downward: anyone in a parent group is treated as a member of descendant groups (with direct child membership overriding inheritance where applicable).

Admin authority is structural, not access-based. A root admin can create or delete subgroups, manage members at the org level, and perform other governance ops on the tree — but they do not automatically get into Restricted contexts in child groups. Reading private channels still requires allowlist membership managed by that group’s direct admins (or the context creator).

Flows down

Member of Acme Corp is a member of Engineering, Platform Team, and Marketing for eligibility checks (join Open contexts, receive inherited roles).

Stops at Restricted

Allowlists for Restricted contexts are evaluated in the owning group. Parent admins do not get a backdoor into child private channels.

Context Layout

Open contexts: any group member can join. Restricted: only allowlisted keys; no inherited-admin bypass. ReadOnly role: can join allowed contexts and read, but mutations are rejected by the platform — ideal for company-wide announcements and auditors.

Root (Acme Corp)

profiles

Open · auto_join — DMs, @mentions, notification sink

general

Open — public lobby

announcements

Restricted — Leadership = Member; company-wide channel = ReadOnly for everyone else

Engineering

eng-general

Open

incidents

Open

eng-hiring

Restricted — eng leads only (allowlist)

Platform Team

platform

Open

on-call

Restricted — paging roster

Frontend Team

fe-general

Open — design + UI discussion

design-crit

Restricted — invite-only critique

Marketing

campaigns

Open

brand-review

Restricted — brand council

For announcements, post in a Restricted context where Leadership has full write access; grant all other members ReadOnly on that context so the whole org sees updates without chat noise or edits.

Cross-context mentions

When a user types @alice in eng-general, the chat WASM can issue an xcall into the profiles context (same org, Open with auto_join) to increment Alice’s mention_counts counter. Alice’s client subscribes to profiles for notification badges without exposing other Restricted rooms.

WASM State Design

Chat app state is CRDT-backed so offline edits merge cleanly. Types mirror Calimero’s WASM data primitives.

ChatChannel

struct ChatChannel {
    messages: Vector<Message>,
    topic: LwwRegister<String>,
    pinned: UnorderedMap<String, LwwRegister<bool>>,
    reactions: UnorderedMap<String, UnorderedMap<String, Counter>>,
}

Message

struct Message {
    id: String,
    author: String,
    content: String,
    timestamp: u64,
}

UserProfiles (profiles context)

struct UserProfiles {
    profiles: UnorderedMap<String, LwwRegister<String>>,
    status: UnorderedMap<String, LwwRegister<String>>,
    mention_counts: UnorderedMap<String, Counter>,
}

Vector for messages — ordered log; concurrent sends get deterministic merge.
LwwRegister for topic and pinned flags — single winner per key; last writer wins with tie-break.
Counter for reactions and mention_counts — additive; safe concurrent increments from many clients.
UnorderedMap for keyed maps — per-message reaction bags and profile fields merge by key.

Why not a CRDT for message text edits?

This sketch treats each Message as immutable once assigned an id. Edits could be modeled as new tombstone-aware entries or a separate LwwRegister per message id if the product needs Slack-style “edited” labels.

Permission Matrix

How five personas interact with the Acme tree. Structural power ≠ read access to child Restricted contexts.

CEO

Acme Corp Admin — structural control everywhere (subgroups, org members). Cannot read eng-hiring or other child Restricted contexts without explicit allowlist.

VP Engineering

Engineering Admin — full governance under Engineering, Platform Team, Frontend Team; manages eng allowlists.

Senior engineer

Engineering Member + CAN_CREATE_CONTEXT + CAN_INVITE_MEMBERS — can spin up channels and invite, subject to group policy.

External auditor

Acme Corp ReadOnly + CAN_JOIN_OPEN_CONTEXTS — reads Open channels and ReadOnly announcement stream; no writes.

Board observer

Leadership ReadOnly; on allowlist for board-updates only — no automatic access to other Leadership Restricted rooms.

Platform Features Used

Subgroups

Org hierarchy under one root; membership inherited down the tree so engineers automatically exist in Platform / Frontend subgroups.

ReadOnly

Announcements and auditor feeds: join + read without mutating application state.

Capabilities

CAN_CREATE_CONTEXT lets trusted members create new channels without full admin.

Context visibility

Open = public to group members. Restricted = private / DM-style rooms gated by allowlist.

xcall

Cross-context calls to bump mention_counts in profiles when someone is @mentioned from any channel.

CRDTs

Vector messages, Counter reactions & mentions, LwwRegister topic and pins.

Privacy Boundary

The important invariant: the CEO can delete the Engineering subgroup but cannot read eng-hiring. Restricted access is enforced per context; only Engineering’s direct admins (or the context creator) curate that allowlist. Inherited parent admins are intentionally excluded from allowlist management in child groups.

If executive oversight is required, the CEO must be added by an Engineering admin — or policy can require a separate compliance context with its own governance. The platform keeps structural hierarchy and confidentiality orthogonal by design.