Voice & Video Sovereignty Ranking — Final Scoring

A maximally adversarial scoring and ranking of seven voice/video stacks under a sovereignty-first, privacy-maximal, FOSS-maximal, anti-capture lens. Scores assume competent deployment (self-hosted where possible; minimized external dependencies) and are comparative rather than absolute.

Scope: voice/video (and associated comms posture) Tools: SimpleX · XMPP/Jingle · Element Call/MatrixRTC · Nextcloud Talk · Jitsi · 0xchat · HiveTalk Scale reality: 1:1 purity vs group conferencing trade-offs

Method & weighting

All criteria are scored 0–100 and combined by a fixed weighting scheme: Composite = Σ(scoreᵢ × weightᵢ). Weights intentionally de-emphasize convenience and emphasize topology, crypto, metadata, alignment, and anti-capture.

Deployment assumption: “Sovereign ceiling” is prioritized over default public instances. Self-hosted infra, private relays/homeservers, and hardened configs define the scoring ceiling. Where a protocol structurally leaks metadata (e.g., relay-visible event graphs), that is penalized even under best-case hosting.

TSS — Topology & Self-Hosting Sovereignty (18%)

Self-hosting ease for server/signalling/media path; avoidance of central SaaS choke points; SFU/mesh/P2P properties; Tor-friendliness.

weight0.18

CEC — Call Encryption & Cryptography (18%)

True end-to-end encryption for voice/video (1:1 and group), modern primitives (ratchets, MLS, SFrame/insertable streams), forward secrecy.

weight0.18

IMP — Identity & Metadata Privacy (18%)

Global identifiers vs local; social-graph visibility; relay/server knowledge of who communicates with whom and when; structural metadata leakage.

weight0.18

FLO — FOSS Openness & Licensing (10%)

Fully FOSS stack; forkability; long-term independence from proprietary components and gating.

weight0.10

SSA — Sovereign Stack Alignment (16%)

Native or clean integration with Bitcoin/Lightning/Cashu/Nostr/Tor and composability with self-hosted sovereign infra.

weight0.16

PRU — Practical Reliability & UX (8%)

Field maturity and stability across platforms; performance under real conditions; minimized friction. Weighted lower on purpose.

weight0.08

ACR — Anti-Capture & Governance Risk (12%)

Protocol vs product governance; corporate/VC/compliance capture risk; ability to fork and route around hostile stewardship.

weight0.12

Composite

Weighted sum across all criteria. Higher is better under this lens.

Σ(weights)1.00

Final ranking

Composite scores reflect the fixed weights above. The ordering is stable under hyper-adversarial re-audits.

  1. 1

    SimpleX Chat

    1:1 sovereign comms purity; no global IDs; maximal metadata minimization; E2EE WebRTC calls (no group calls).

    86.5
  2. 2

    XMPP + Jingle/WebRTC

    Durable protocol primitive; highest self-host sovereignty; strong E2EE ceiling via modern clients; server-visible graph remains.

    84.4
  3. 3

    Element Call (MatrixRTC)

    E2EE group conferencing at scale via MatrixRTC; heavy but powerful ecosystem; homeserver-visible identity/room metadata.

    83.8
  4. 4

    0xchat (Nostr)

    Highest BTC/Nostr alignment; E2EE content posture; structurally leaky metadata due to Nostr relay event model.

    80.3
  5. 5

    Nextcloud Talk

    Sovereign org-suite calls; E2EE calls exist; chat messages not E2EE; group calls at scale rely on HPB (SFU path ambiguity).

    78.6
  6. 6

    Jitsi Meet

    Battle-tested SFU conferencing; optional E2EE via insertable streams with limitations; strong usability, weaker purity.

    78.3
  7. 7

    HiveTalk (Nostr + Lightning SFU)

    Nostr/LN conferencing shell atop SFU; SRTP-in-transit rather than true E2EE vs server; added identity surface (e.g. gravatar/email).

    76.3

Key posture distinctions

This lens treats topology + metadata as first-class security properties, not secondary concerns.

1:1 purity vs group conferencing

The top of the ranking splits by call topology: SimpleX dominates 1:1 privacy/metadata minimization (and documents that group calls are not supported), while Element Call dominates E2EE at scale for group calls via MatrixRTC. XMPP sits between: high sovereignty and mature, with an E2EE ceiling that depends on client selection (e.g., DinoX). (SimpleX calls, Element E2EE calls, DinoX)

Structural metadata penalty

Nostr’s relay-based architecture makes robust metadata hiding difficult; even with strong payload encryption (e.g., NIP-44), relay-visible event graphs remain a constraint. (NIP-44 limitations)

“Encrypted in transit” is not E2EE

SFU stacks typically provide SRTP encryption on the wire but do not automatically provide end-to-end encryption against the SFU/operator. HiveTalk’s public material emphasizes SRTP for streams, which is not the same as E2EE. (HiveTalk SRTP claim, MiroTalk SFU)

Interpretation rule: When a tool “supports E2EE,” the scoring distinguishes between (a) documented, default-capable E2EE at scale, (b) optional E2EE with client limitations, and (c) transport encryption only (SRTP/TLS) where the server can still access media.

Score table

Per-criterion scores (0–100) and final composite. Higher is better under this lens.

Rank Tool TSS CEC IMP FLO SSA PRU ACR Composite
1
SimpleX Chat ID-free routing + E2EE 1:1 WebRTC calls; group calls not supported.
91
87
97
96
65
77
90
 86.5
2
XMPP + Jingle/WebRTC Protocol primitive; client-dependent E2EE ceiling; server-visible contact graph.
95
82
78
92
70
88
92
 84.4
3
Element Call (MatrixRTC) E2EE group conferencing at scale; heavier metadata on homeservers.
90
90
78
90
75
84
80
 83.8
4
0xchat (Nostr) Highest BTC/Nostr alignment; payload E2EE; relay-visible metadata constraints.
82
85
55
90
97
78
80
 80.3
5
Nextcloud Talk Self-hosted org suite; E2EE calls exist; chat messages not E2EE; HPB adds complexity.
88
74
72
90
68
80
85
 78.6
6
Jitsi Meet Battle-tested SFU; optional E2EE via insertable streams; strong UX, weaker purity ceiling.
88
70
78
87
68
90
75
 78.3
7
HiveTalk (Nostr + Lightning SFU) Nostr/LN shell on SFU; SRTP in transit; added identity surface; not true E2EE vs server by default.
85
60
55
93
90
80
85
 76.3
Linking rule: every substantive claim below is accompanied by direct links to official docs, repos, or protocol specifications at point-of-use. No link dump is deferred to an appendix.

Tool analyses

Each entry includes: role, rationale, trade-offs, per-criterion scores, and integrated source links.

1) SimpleX Chat

Role: 1:1 comms purity with maximal metadata minimization; no global user identifiers; E2EE WebRTC calls; explicit non-support for group calls. (audio/video calls, protocol spec)

86.5
composite

Why it ranks #1

  • E2EE 1:1 audio/video calls via WebRTC, with calls negotiated through a dedicated sub-protocol for key agreement and signalling. (calls guide, call sub-protocol)
  • ID-free architecture (no phone/email, no global username) and routing that minimizes durable contact-graph observability. (GitHub, Whonix profile)
  • Explicit constraint: group calls are not supported; the scope is intentionally narrow and sovereign. (“Group calls are not supported”)

Key links

Scores

TSS91
CEC87
IMP97
FLO96
SSA65
PRU77
ACR90

Trade-offs and constraints

  • Not a group conferencing system (explicitly not supported).
  • Not Bitcoin/Nostr-native; alignment is via privacy posture and self-hosting capability rather than crypto-economic integrations.

2) XMPP + Jingle/WebRTC

Role: long-horizon protocol primitive; maximal self-host sovereignty; E2EE ceiling depends on client selection. Example of a high-security client with calls and MUJI group video: DinoX. (XMPP software ecosystem, DinoX repo)

84.4
composite

Why it ranks #2

  • Highest topology sovereignty: run a server, federate selectively, or remain private; no single vendor gatekeeper. (XMPP software list)
  • Strong E2EE ceiling in best-case client setups: DinoX advertises OMEMO 1+2, Tor/obfs4 integration, WebRTC calls, and decentralized MUJI group video calls. (DinoX features, DinoX site)
  • Anti-capture posture is high because the protocol and ecosystem are plural: multiple servers/clients and a long-lived standard.
  • Structural limitation: server-visible social graph and presence metadata remain, even when self-hosted.

Key links

Scores

TSS95
CEC82
IMP78
FLO92
SSA70
PRU88
ACR92

Trade-offs and constraints

  • Metadata is concentrated on the chosen server (self-hosting changes who can see it, not whether it exists).
  • Call crypto quality depends on client maturity and configuration; “ceiling” is strong, “default” varies.

3) Element Call (MatrixRTC)

Role: E2EE group conferencing at scale, leveraging MatrixRTC and a LiveKit SFU stack while preserving end-to-end encryption semantics. (Element E2EE calls, MatrixRTC overview)

83.8
composite

Why it ranks #3

  • Documented E2EE voice/video calling at scale for self-hosted/federated setups. (Element blog)
  • MatrixRTC provides a standardized way to establish large-scale end-to-end encrypted group calls, with multiple media-stack options. (Matrix 2.0 / MatrixRTC)
  • Element Call codebase explicitly advertises E2EE and standalone/widget mode. (Element Call README)
  • LiveKit itself documents built-in E2EE support (useful context for the SFU-backed approach). (LiveKit encryption, LiveKit self-hosting)
  • Structural penalty: Matrix homeservers still see user IDs, membership, and significant room-level metadata.

Key links

Scores

TSS90
CEC90
IMP78
FLO90
SSA75
PRU84
ACR80

Trade-offs and constraints

  • Protocol and deployment are heavier than XMPP/SimpleX; more moving parts increase maintenance surface.
  • Homeserver-visible room and identity metadata is non-trivial, even when content is E2EE.

4) 0xchat (Nostr)

Role: BTC/Nostr-native messenger with voice/video calls and payments; strong encrypted payload posture but penalized for relay-visible metadata constraints. (0xchat site, GitHub org)

80.3
composite

Why it ranks #4

  • Highest sovereign-stack alignment: Nostr foundation plus Lightning/Cashu primitives. (features, 0xchat-core)
  • E2EE private chats, groups, and voice/video calls are core product claims. (0xchat.com, release notes)
  • Structural metadata penalty is anchored in Nostr protocol realities: NIP-44 explicitly notes that relay architecture makes metadata hiding difficult. (NIP-44 limitations, NIP-17)

Key links

Scores

TSS82
CEC85
IMP55
FLO90
SSA97
PRU78
ACR80

Trade-offs and constraints

  • Relay-visible event metadata remains a structural constraint; payload encryption does not automatically imply metadata concealment. (NIP-44 limitations)
  • Best results assume curated relay sets rather than broad public-relay broadcast.

5) Nextcloud Talk

Role: self-hosted organizational collaboration and conferencing within the Nextcloud suite; E2EE calls exist, but chat messages are not E2EE and HPB adds SFU complexity. (Nextcloud Talk, HPB installation)

78.6
composite

Why it ranks #5

  • Strong self-host fit for sovereign org stacks: integrated files, identity, and comms. (Talk overview)
  • End-to-end encrypted calls are a documented product feature (especially meaningful for “sensitive communication”). (E2EE calls claim)
  • High-Performance Backend (HPB) architecture is explicitly SFU-like: signalling server + WebRTC gateway. (HPB architecture)
  • Hard privacy penalty: Talk chat messages are not E2EE (stored plaintext in DB; server hardening is required). (community confirmation)
  • Field reality: enabling E2EE call settings can have platform friction/bugs (example: Android issue report). (talk-android issue)

Key links

Scores

TSS88
CEC74
IMP72
FLO90
SSA68
PRU80
ACR85

Trade-offs and constraints

  • Messages are not end-to-end encrypted; server compromise reveals chat content. (reference)
  • Scaling via HPB introduces additional components and an SFU/media gateway path that complicates strict E2EE assurances at scale. (HPB design)

6) Jitsi Meet

Role: battle-tested SFU conferencing stack with optional E2EE via insertable streams; strong usability and scale, weaker default purity. (Jitsi security, E2EE implementation doc)

78.3
composite

Why it ranks #6

  • Strong practical maturity and SFU performance for large calls and “it works” deployments.
  • E2EE exists but is constrained: supported endpoints are browsers with insertable streams (Chromium-based) and the Electron client. (Jitsi security page, lib-jitsi-meet E2EE doc)
  • E2EE is optional and can be disabled/configured; deployments often trade it away for features like recording or dial-in. (handbook config options)
  • Deep technical description of E2EE architecture is available (PDF). (E2EE in Jitsi Meet (PDF))

Key links

Scores

TSS88
CEC70
IMP78
FLO87
SSA68
PRU90
ACR75

Trade-offs and constraints

  • E2EE depends on specific endpoint support and is not uniformly “always on.” (reference)
  • SFU-centric topology means metadata and operational visibility remain significant when E2EE is off.

7) HiveTalk (Nostr + Lightning SFU)

Role: Nostr/LN-friendly conferencing shell built as a fork of MiroTalk SFU. Strong alignment, weaker crypto hardness vs server and heavier identity surface. (HiveTalk repo, FAQ)

76.3
composite

Why it ranks #7

  • HiveTalk is explicitly a fork of MiroTalk SFU with Nostr + Lightning enhancements. (GitHub, MiroTalk SFU repo)
  • Public messaging emphasizes SRTP encryption (encrypted media streams in transit), which is not equivalent to end-to-end encryption vs the SFU/operator. (SRTP claim)
  • Identity surface expands beyond anon: FAQ allows anon, name, or gravatar email; Nostr/LN features become active when logging in with those credentials. (HiveTalk FAQ)

Key links

Scores

TSS85
CEC60
IMP55
FLO93
SSA90
PRU80
ACR85

Trade-offs and constraints

  • Default SFU model implies server visibility into media unless an additional E2EE layer is explicitly implemented.
  • Identity options (e.g. gravatar/email) increase linkability and are misaligned with strict metadata minimization. (reference)

Cluster summary

The final ordering groups naturally into functional roles and threat-model fit.

Pure 1:1 sovereignty

Maximal metadata minimization; no global identifiers; narrow scope preferred over feature sprawl.

  • SimpleX Chat — E2EE 1:1 WebRTC calls; group calls explicitly not supported.

Protocol primitives (durable + self-host maximal)

Long-lived standards with multiple implementations; strong anti-capture posture.

E2EE group conferencing at scale

SFU-backed conferencing with documented end-to-end encryption semantics; heavier protocol/infra.

BTC/Nostr-native comms and conferencing

Highest sovereign-stack alignment; penalized when protocols structurally leak metadata or SFUs terminate media.

  • 0xchat — strong encrypted payload posture; metadata-hiding is difficult in relay architecture (NIP-44).
  • HiveTalk — Nostr/LN conferencing shell atop SFU; SRTP-in-transit does not equal E2EE.

Org-suite stacks

Strong sovereign “office layer” integration; crypto and metadata posture are mixed.

  • Nextcloud Talk — E2EE calls exist; messages not E2EE; HPB adds media-path complexity.

Generic FOSS conferencing workhorse

Very mature and widely deployed; optional E2EE with endpoint limitations; strong usability focus.

  • Jitsi Meet — E2EE via insertable streams is documented but not universally available/used.
Meta verdict: The top of the table is defined by topology and metadata philosophy, not by feature count. The bottom of the table is largely explained by SFU termination and identity surface expansion.
Back to top ↑