Keychat's avatar
Keychat 4 months ago
—the lack of participation privacy If you understand that in Keychat ID are decoupled from sending/receiving addresses and addresses are continuously rotated, you’ll realize it’s almost impossible for a message relay to identify the participants in a group.
Keychat's avatar Keychat
Evolution of Receiving Addresses in Signal, Simplex Chat, and Keychat A receiving address is indispensable to any chat application—just as an envelope needs only the recipient’s address. Because this address is exposed plaintext metadata, its design determines how much metadata privacy the user enjoys. Signal each user has a single receiving address that is also their ID. For Bob and Carl alike, Alice’s address is always the same—simply A—and it never changes. Simplex Chat Here, the receiving address (smp://<queueKey>@<relay-host>/<queueId>) is different for every contact. Alice has one fixed address for Bob, A(b), and another for Carl, A(c). Having separate—but constant—addresses for each contact is already a significant improvement over Signal’s single, global address. Keychat Keychat goes a step further: the address not only differs per contact but also rotates over time. Alice begins with A(b1)for Bob and A(c1) for Carl; after she replies, they become A(b2) and A(c2), and so on. Each time Alice responds to Bob, her address is refreshed. This dynamic, per-contact rotation provides even stronger privacy than Simplex’s static per-contact addresses.
View quoted note →

Replies (1)

This has the same problem that was drawing criticism with early design of SimpleX network - while there is no persistent/observable identity on the protocol level, there is a fixed transport identity - relays can see which IP addresses communicate with which IP addresses. So it would require a similar solution to what we did with SimpleX network to mitigate it.