Simplex Chat Review: No Identifiers Architecture Analysis

Simplex Chat is worth it if metadata protection is your top priority. It is the only production messaging app that operates without any persistent user identifiers – no phone numbers, no usernames, no cryptographic keys that serve as stable IDs. This eliminates correlation attacks, social graph harvesting, and account hijacking entirely. The trade-offs are real: initial contact requires out-of-band address exchange, and the user base is small. For journalists, activists, or anyone whose threat model includes communication metadata analysis, Simplex Chat provides architectural guarantees no other network-based messenger can match.

The Identifier Problem

Every conventional messaging platform requires some form of user identification to establish connections. Your phone number links your identity across services. Your username creates a persistent handle. Even cryptographic identities in protocols like Signal still produce stable public keys that serve as permanent identifiers.

This creates several privacy vulnerabilities:

Correlation attacks occur because your phone number or username links conversations across different groups, enabling mass surveillance. Platforms collect and store your contact list, building social graphs through contact harvesting. Email or phone account recovery mechanisms create backdoors to your identity. Servers must know who to deliver messages to, which requires persistent addressing that exposes network-level metadata.

Simplex Chat addresses these issues by eliminating identifiers entirely from the protocol layer.

How Simplex Chat Eliminates Identifiers

Simplex Chat uses a connection model based on temporary, disposable connection addresses rather than persistent user IDs. The protocol operates through a network of SMP (Simple Messaging Protocol) servers, but these servers never learn user identities.

Connection Establishment Process

When two users want to communicate, they exchange connection addresses rather than usernames or IDs:

User A generates: smp://abc123...@server.example.com
User B generates: smp://xyz789...@server.example.com

These addresses are:
- Temporary (can be rotated)
- Server-specific (different addresses for different servers)
- Unlinkable to real identity

The critical innovation is that connection addresses contain no inherent information about the user’s identity. You can generate new addresses for each conversation or rotate them periodically.

Server Architecture

Simplex Chat servers (SMP servers) act as message relays but maintain no user accounts:

Component Traditional Messaging Simplex Chat
User ID Phone number/username None
Account Persistent registration None
Login Credentials required Connection address only
Metadata Full contact graph Minimal, transient

Servers store only:

Protocol Implementation Details

The Simple Messaging Protocol (SMP) handles message delivery without knowledge of recipient identity. Here’s how the protocol works at a technical level:

Message Queue Model

Each connection address corresponds to a message queue on the server:

-- Simplified queue creation (pseudocode)
createQueue :: Server -> ConnectionAddress -> IO QueueId
createQueue server addr = do
  queueId <- generateRandomUUID
  -- Server stores only:
  -- 1. The queue ID (random, unlinked to identity)
  -- 2. Encrypted message blobs
  -- 3. Expiration timestamp
  server.storeQueue(queueId, addr, expiry)
  return queueId

The server never learns:

End-to-End Encryption

Simplex Chat implements double-ratchet encryption ensuring forward secrecy:

// Encryption flow (simplified)
fn send_message(sender_key: &PrivateKey, recipient_queue: &QueueAddress, plaintext: &[u8]) -> Vec<u8> {
    // Generate ephemeral key for this message
    let ephemeral_key = generate_ephemeral_keypair();
    
    // Encrypt message with recipient's known public key
    let ciphertext = encrypt_aead(
        plaintext,
        &ephemeral_key.public,
        &recipient_queue.public_key
    );
    
    // Send to queue - server sees only encrypted blob
    server.push_message(recipient_queue.id, ciphertext);
}

The double-ratchet provides:

Practical Usage Patterns

For developers and power users, Simplex Chat offers several unique operational characteristics:

One-Time Connections

Create connection addresses that expire after use:

# Generate single-use connection address
# (via Simplex Chat CLI or mobile app)
smq new --single-use --expiry 24h

This prevents long-term correlation of your identity across conversations.

Multiple Identities

Run multiple Simplex Chat instances simultaneously, each with completely unlinkable identities:

Instance 1: smp://abc123...@server1.simplex.chat  # Work
Instance 2: smp://def456...@server2.simplex.chat  # Personal
Instance 3: smp://ghi789...@server3.simplex.chat  # Sensitive

Network observers cannot determine these belong to the same person.

Self-Hosted Servers

Deploy your own SMP server for additional privacy:

# docker-compose.yml for self-hosted SMP server
services:
  smp-server:
    image: simplexchat/smp-server
    ports:
      - "5224:5224"
    environment:
      - SMTP_PORT=1025
      - QUEUE_EXPIRY=86400
      - MAX_MESSAGE_SIZE=1048576

Running your own server eliminates even the minimal metadata visible to third-party servers.

Security Analysis

Threat Model Advantages

Simplex Chat’s architecture provides strong protection against:

Without persistent identifiers, there is nothing to correlate in mass surveillance. No address book upload is required, eliminating contact harvesting. Connection addresses don’t reveal relationships, preventing social graph analysis. With no account to hijack, identity theft through account takeover is not possible.

Remaining Considerations

Several limitations warrant awareness:

At least one SMP server must be online for messages to be delivered. Initial contact requires exchanging addresses through some out-of-band channel. While messages are encrypted, servers still see connection metadata such as timing and volume. If you lose your device and all saved addresses, communication cannot be recovered because there is no phone number or account to fall back on.

Metadata Minimization

Compared to other privacy-focused messengers:

Messenger Identifiers Metadata Collected
Signal Phone number Contact graph, timing
Session Session ID Timing, IPs
Simplex Chat None Minimal timing only
Briar None None (mesh only)

Comparison with Alternatives

For developers evaluating privacy messaging options:

The choice depends on your threat model. If phone number confidentiality is critical, Simplex Chat provides the strongest guarantees among network-based messengers.

Developer Integration

Simplex Chat offers a Haskell library for building custom clients:

-- Haskell API example
import Simplex.Messaging

-- Create connection address
addr <- createAddress server

-- Send message
sendMessage addr "Hello, world!"

-- Receive messages
msgs <- pollMessages addr

The protocol specifications are open, enabling verification and custom implementations.

Conclusion

Simplex Chat’s identifier-less design represents genuine innovation in privacy-preserving communication. By eliminating persistent user IDs from the protocol layer, it addresses fundamental privacy vulnerabilities that plague conventional messaging platforms.

The trade-offs are real: initial contact requires out-of-band address exchange, and the network model differs from familiar chat applications. For users with stringent privacy requirements—journalists, activists, or anyone requiring communication metadata protection—Simplex Chat provides architectural guarantees that traditional messenger protocols cannot match.

For developers building privacy-focused applications, the protocol’s Haskell implementation offers a reference architecture worth studying. The identifier-less model demonstrates that practical messaging can function without the identity infrastructure most platforms treat as essential.

Built by theluckystrike — More at zovo.one