A Federated Network of Independent Organizations

Each organization runs and controls its own Sover instance. Federation connects it to the partners it approves, for exactly the exchanges its policy allows.

Book a Demo See How It Works

Overview

Separate Instances, One Federated Network

Federation connects independent Sover instances, so organizations can work together while each one controls its own deployment. Communication between them follows partner and access policies that each side sets for itself.

Sover supports open and closed federation. In closed-federation mode, an instance communicates only with the partners on its approved list. Traffic between servers runs over TLS, with audit logging of inter-server traffic.

Inside one organization, workspaces keep teams apart in a single deployment. Federation is for organizations that need to operate independently and still communicate.

Capabilities

What Federation Gives Each Organization

  1. Each organization runs its own Sover instance on its own infrastructure and governs it under its own security policy.

  2. Federate openly, or in closed-federation mode, where an approved-partner list names the instances yours may talk to.

  3. Decide which users and which groups of users in your organization may communicate across the federation.

  4. Each organization limits what crosses to other instances, for example allowing messages and calls while disabling forwarding or contact sharing.

  5. Traffic between federated servers travels over TLS.

    Security and Compliance

  6. Federation includes audit logging of the traffic between instances.

Security Tiers

Security Tiers, for Example

Independent instances can federate in security tiers. Three illustrate the idea; a real federation sets its own.

  1. For example defense, intelligence and national police, each on an instance of its own that opens only the exchanges it approves.

  2. For example state and local governments and enterprises, each running an instance of its own.

  3. Scalable shared instances that a national operator runs on its own infrastructure for citizens and small businesses.

An illustration, not a fixed model: a real federation can have more or fewer tiers, according to its organizations, operating model and security requirements.

How It Works

From Your Own Instance to an Agreed Exchange

  1. Run Your Own Instance

    Each organization deploys Sover on infrastructure it controls, under its own security policy.

  2. Agree the Partners

    Administrators on both sides agree the partner relationship and who may take part. In closed-federation mode, only approved partners connect.

  3. Set What Crosses

    Each side sets its own policies for users and groups, for example allowing messages and calls while disabling forwarding or contact sharing.

  4. Validate, Then Communicate

    Test the restrictions you need on the release you deploy. Then people communicate across instances, with TLS between servers and audit logging.

Included

What Is Included, and Where the Limits Are

Included

  • Open and closed federation. Connect openly, or only with the instances on your approved-partner list.

  • Control of your own instance. Each organization controls its instance and decides what crosses to other instances.

  • Per-user and per-group policies. Set who in your organization may communicate across the federation.

  • Exchange limits. For example, allow messages and calls while disabling forwarding or contact sharing.

  • TLS between servers. Traffic between federated instances runs over TLS.

  • Audit logging. Federation includes audit logging of inter-server traffic.

Stated Limits

  • Tiers are an example. High-security, dedicated and operator-run shared instances illustrate one design; a real federation can have more or fewer tiers.

  • Shared data can reach partners. Information exchanged through federation can reach the other participating instances. Data exchange, local copies, contact information and historical content are assessed as part of the federation design.

  • No secret chats with federated users. Secret chats cannot include a federated user, and the end-to-end encryption claim covers secret chats, not every federated exchange.

  • Restrictions are tested per release. Limits such as those on forwarding or contact sharing are scoped and tested for the participants and clients involved, on the release you deploy.

  • Calling varies by client. Calls across instances differ by platform; test the ones your users need during evaluation.

  • Not a public cloud service. Shared instances are run by a national operator on its own infrastructure; Sover is not offered as public multi-tenant SaaS.

Where It Runs

Federation Where Organizations Must Stay Separate

  1. Government Agencies Ministries and agencies each keep their own instance and work together across closed federation with the partners they approve. Learn More
  2. Law Enforcement A national police force can run a high-security instance of its own and open only the exchanges it approves. Learn More
  3. Sovereign Social Media Shared instances a national operator runs for citizens and small businesses, connected to other instances under the operator’s policies. Learn More
  4. Critical Infrastructure Separately hosted organizations keep their own instances and connect them where they need controlled communication. Learn More

Keep Reading

Questions, or Ready for a Briefing?

Contact Sales

Tell us about your organization and we will arrange a briefing for your team.

The form needs JavaScript. Please enable it and reload the page.

What is federation in Sover?

Federation connects independent Sover instances so organizations can collaborate while each controls its own deployment. It allows cross-organization communication to be governed by partner and access policies.

Can we choose which organizations our instance communicates with?

Sover supports open and closed federation, including approved-partner policies. Define the intended partners and permitted communication when designing the deployment, then validate the required restrictions on the selected release.

Can each organization keep its own communication policies?

Yes. Each organization controls its instance and can set policies for cross-instance communication. Requirements such as restrictions on forwarding or contact sharing should be scoped and tested for the participants and clients involved.

Does federation always use three security tiers?

No. High-security, dedicated, and operator-run shared instances are illustrative examples. A real federation can have more or fewer tiers according to the organizations, operating model, and security requirements.

Does federation mean all data stays on its original server?

Do not assume that federation prevents information from reaching another participating instance. Data exchange, local copies, contact information, and treatment of historical content need to be assessed as part of the federation design.

Are all federated messages end-to-end encrypted?

The approved end-to-end encryption claim is for secret chats, not every federated exchange. Federation uses its own transport and policy controls; the required encryption and information-sharing boundaries must be reviewed for the deployment.