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 to access contexts in a child subgroup, they must be a member of that subgroup. Private channels are placed in dedicated subgroups with restricted membership.

Flows down

Member of Acme Corp is a member of Engineering, Platform Team, and Marketing. With auto_join (default), all contexts in those groups are accessible.

Restricting access

Private channels live in dedicated subgroups with restricted membership. Only members explicitly added to the subgroup can access its contexts.

Context Layout

Any group member can join contexts in that group. ReadOnly role: can join contexts and read, but mutations are rejected by the platform — ideal for company-wide announcements and auditors. Private channels are placed in dedicated subgroups with restricted membership.

Root (Acme Corp)

profiles

auto_join — DMs, @mentions, notification sink

general

Group context — public lobby

announcements

Owned by Leadership subgroup; company-wide ReadOnly access granted at root level

Engineering

eng-general

Group context

incidents

Group context

eng-hiring

In a dedicated subgroup — eng leads only (subgroup membership)

Platform Team

platform

Group context

on-call

In a dedicated subgroup — paging roster

Frontend Team

fe-general

Group context — design + UI discussion

design-crit

In a dedicated subgroup — invite-only critique

Marketing

campaigns

Group context

brand-review

In a dedicated subgroup — brand council

For announcements, the context lives in the Leadership subgroup where members have full write access. The root group grants ReadOnly role 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 access eng-hiring or other private subgroup contexts without being added to those subgroups.

VP Engineering

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

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 — reads channels in groups they belong to; no writes.

Board observer

Leadership ReadOnly; added to specific subgroups for board-updates only — no automatic access to other Leadership channels.

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.

Subgroup access control

Private channels live in dedicated subgroups with controlled membership. Group membership = context access.

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 access eng-hiring contexts. Access is enforced by subgroup membership; the CEO must be explicitly added to the eng-hiring subgroup to access its contexts.

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