SimpleX Chat any good?

I was scrolling through F-Droid and came across this app called SimpleX Chat. It claims to be “the first messaging platform that has no user identifiers of any kind”. Anyone heard of it/looked into it at all? I looked into it a bit; it claims to be decentralized, but I’m trying to figure out how it can be neither P2P nor federated and still be decentralized (it’s website seems to indicate it’s different from federation). Maybe someone could shed some light on how that works?

F-Droid link: SimpleX Chat | F-Droid - Free and Open Source Android App Repository

I have not used this, so I’m just reading their website and adding how I interpret it. Sounds like it works like this:

There are a bunch of queues. When you send a message you push it into a queue (a queue that the person you are sending it to can pull from). And when you want to check if you have received any messages, you read from a bunch of queues (one queue per chat).

To talk with someone you must first scan their QR code. This QR code, would, in theory, contain details about one of the user’s public keys (so that you can end-to-end encrypt messages to them) and which queue to use (so you know how to send messages).

So each chat session has associated with it {user-a-to-user-b-queue, user-b-to-user-a-queue, {user-a-public-key, user-a-private-key}, {user-b-public-key, user-b-private-key}}

And from user A’s perspective, they have
{user-a-to-user-b-queue (sending queue), user-b-to-user-a-queue (recieving queue), {user-a-public-key, user-a-private-key}, {user-b-public-key}}

And from user B’s perspective, they have
{user-a-to-user-b-queue (recieving queue), user-b-to-user-a-queue (sending queue), {user-a-public-key}, {user-b-public-key, user-b-private-key}}.


So in a sense, the idea of no user identifiers claim could be true, someone needs to host a server for the queues (but it looks like you can self host), and everything else can be managed locally on each users device.

Of course, whoever controls the server probably could use the IP addresses to associate who is talking to who:
172.4.20.1 pushed to queue A. And then read from queue B.
172.4.20.2 read from queue A. And then pushed to queue B.
The server could probably determine that 172.4.20.1 and 172.4.20.2 are talking to one another using queues A and B (though we still don’t know who these users are beyond an IP address and we can’t read the messages in the queues since they are encrypted with keys we don’t have).

This could be mitigated by each client by using IP obfuscation techniques (like if you ran your traffic through the TOR network), not sure if they are doing this with their client or not.


Ultimately, the concept seems pretty sound to me. But I haven’t done any sort of code review to determine if this is actually how this works, this is just a mix of how their homepage makes it sound like it works + my own ideas for how they could possibly implement their claims.

2 Likes