What I mean is that Nostr relays can track which IP addresses read messages from which group IDs, creating an association with transport level identities of the users. While it's indeed mitigated to some extent by Tor/VPN, which was SimpleX design defence early on, the valid criticism of this argument that either Tor should be built into the clients (which wasn't and won't be the case with SimpleX, and is not the case with Nostr clients), as most users won't use Tor, and will assume that declared security properties hold without any additional measures. What's worse is that even with Tor or VPN, Nostr relays can associate the list of group IDs with client sessions that read them, and observing sessions over time they would be able to statistically "recognise" users by the list of groups they get messages from. To mitigate this risk clients have to use different connections (and Tor circuits) when reading from different groups, and it's neither practical nor part of the spec. SimpleX clients offered this feature (transport isolation) as opt in. So the response of SimpleX network design that addressed this criticism was using two independent relays in the message routing path, where the first one can see client session and transport address, but cannot see destination message queue address. And the second relay can see destination queue address, but has no information that could identify the transport session of the client. And the clients are programmed to choose relays operated by different parties to mitigate collusion risks. What I was saying about our future chat relays design is that they are the usual messaging clients under the hood, just high volume, and won't have any network connection to the group members, even an indirect one, as they will be communicating via the existing messaging network.

@JeffG Wonder if a bloom filter for ID's could help mitigate per connection fingerprinting?

@Amethyst (a NOSTR client) has used built-in TOR for almost a year