Cross-Organisation Federation: Collaborate Without Compromise

Note: This article describes Mandraki’s architecture and design. Some features discussed are being rolled out progressively and may not yet be available in all plans.

Enterprise collaboration does not happen in isolation. Organisations work with partners, clients, regulators, contractors, and industry consortia. The people you need to communicate with are often outside your organisation, and frequently outside your collaboration platform.

The traditional solutions to this problem are unsatisfying. You can invite external users as guests into your platform, which blurs security boundaries and creates administrative overhead. You can maintain accounts on multiple platforms, which fragments your communications. Or you can fall back to email, which provides none of the real-time collaboration features that modern work demands.

Mandraki’s cross-organisation federation offers a better approach: two organisations can collaborate in shared channels and calls while each maintaining full sovereignty over their own data, security policies, and administrative control.

How federation works

Federation in Mandraki is a bilateral, consent-based relationship between two organisations. Neither side can impose federation on the other. The process begins when one organisation sends a federation request to another.

The request specifies which collaboration capabilities the requesting organisation wishes to enable: messaging, calls, file sharing, and shared channels. The target organisation reviews the request and can approve it with its own set of permissions. Both sides must agree, and either side can modify or revoke the relationship at any time.

Once a federation relationship is established, users from both organisations can participate in shared channels and calls. The experience is seamless — a shared channel appears alongside the organisation’s internal channels, and users from the federated organisation are clearly identified with an “External” badge.

Data ownership in shared channels

A shared channel in Mandraki has a single owning organisation. The owning organisation’s policies govern the channel’s encryption settings, retention policies, and AI feature availability. Other organisations participate in the channel but do not control its configuration.

Critically, every message in a shared channel carries an originOrgId that identifies which organisation the sender belongs to. This ensures traceability: each organisation can see which messages originated from their members and which came from external participants.

For compliance purposes, each organisation retains access to the messages sent by their own members. If one organisation leaves a federation, they retain their own messages while losing access to messages from the other organisation. Data ownership follows the organisation boundary, not the channel boundary.

Governance and policy controls

Federation in Mandraki is governed by granular policy controls at the organisation level.

Cross-org policy. Administrators set the organisation’s federation stance: disabled (no federation allowed), federated only (federation with approved organisations only), or open (federation requests accepted by default, subject to individual approval).

Allow list. Organisations can maintain an explicit list of approved federation partners. Only organisations on the list can establish federation relationships.

Approval requirement. When enabled, all federation requests require explicit administrator approval, even if the requesting organisation is on the allow list.

Per-feature permissions. Federation relationships have granular feature toggles. An organisation might allow messaging with a partner but not file sharing, or allow calls but not shared channels. These permissions can be adjusted at any time.

These controls reflect the reality that different organisations have different risk appetites and regulatory requirements. A financial institution might federate with its auditor for messaging only, with no file sharing. A government department might federate with an industry body for shared channels but require approval for each new participant.

Security boundaries

Federation does not merge two organisations’ security domains. Each organisation maintains its own encryption keys, its own user management, its own access controls, and its own audit logs. The SFU and API server enforce organisation boundaries at every layer.

When a message is sent in a shared channel, it is encrypted with the channel’s encryption context (which belongs to the owning organisation). Users from federated organisations who have been granted access can decrypt and read the message. But the federation relationship does not grant access to any other data within the owning organisation — internal channels, direct messages, or organisational settings remain completely isolated.

For calls in federated contexts, the same principle applies. Participants from both organisations join the call through the standard WebRTC signalling flow, authenticated against their respective organisations. The SFU routes media between participants without regard to which organisation they belong to, but the API enforces that only participants with valid federation permissions can join.

Installation identity and inter-installation federation

Mandraki’s federation model extends beyond organisations within a single installation to support communication between separate Mandraki deployments — what we call inter-installation federation.

Each Mandraki installation has a unique identity, including an Ed25519 keypair for cryptographic authentication. Installations publish a well-known descriptor at /.well-known/eurocom-server that includes their public key, capabilities, and version.

When two installations communicate, all payloads are signed with the sending installation’s private key and verified with the receiving installation’s public key. This prevents impersonation and ensures that federation messages are authentic.

Inter-installation federation is particularly relevant for organisations with data residency requirements. A Mandraki installation in Germany can federate with an installation in France, allowing cross-border collaboration while each installation maintains data residency within its respective jurisdiction.

The external user experience

We paid careful attention to how federated users appear in the interface. External users are always visually distinguished with a clear “External” badge. This is not optional or configurable — it is enforced by the platform to prevent confusion about who is in a conversation.

When composing a message in a shared channel, the compose area reminds the user that external participants can see their messages. When starting a call in a federated context, participants see a clear indication of which organisations are represented.

These design decisions reflect a principle: federation should make cross-organisation collaboration easy, but it should never make it invisible. Users should always know when they are communicating across organisational boundaries.

The case for federation over guest accounts

Many collaboration platforms address cross-organisation communication through guest accounts — external users are given limited accounts within the host organisation’s workspace. This approach has several drawbacks that federation avoids.

Guest accounts create administrative burden: someone must create, manage, and eventually deactivate each guest. Guest accounts blur security boundaries: the guest exists within the host’s security domain, which may not align with the guest’s own organisation’s security policies. Guest accounts fragment communication: the guest must maintain separate identities and contexts for each organisation they collaborate with.

Federation keeps each user within their own organisation’s domain. They authenticate with their own credentials, see their own organisation’s channels alongside shared ones, and are governed by their own organisation’s policies. No guest accounts to manage, no blurred boundaries, no fragmented identity.

For European organisations that need to collaborate across borders while maintaining sovereignty, federation is the architecture that makes this possible without compromise.