> The idea is that you can send a message to a complete stranger. How do you know you didn’t send it to the wrong stranger?

Are you talking about the directory server in isolation or how it's going to be integrated into the E2EE for the Fediverse proposal? It's not clear for your comment which use case you're imagining.

The thing is: With the E2EE proposal, you don't just encrypt something to a complete stranger based on the Directory Server's contents. Instead:

1. You poke their instance for their user ID, and which directory servers they use.

You can have further client-side checks, gossip protocols about username<->ID mapping, etc. to keep the instance honest about which ID maps to which user. I just don't want to deal with GDPR's "right to be forgotten" and usernames (which may be PII) at this layer.

2. You poke the directory server for the public keys, and proofs of inclusion in the SigSum ecosystem; including co-witness signatures.

3. Your software verifies these proofs, automatically, client-side. It refuses to move forward if anything is amiss.

4. Now that you have an Ed25519 (or post-quantum) signing key, you then query the instance for one of their SignedPreKey bundles.

5. You verify the signature on the SignedPreKey bundle, then use that to establish an untrusted comunciation with the user in question.

After step 5, if you want to verify their identity, something like Signal's safety number for user trust can be implemented to allow out-of-band verification.

It's important to take a step back and think about what the instance admins can and cannot do to mess with this process.

Scenario A. A new user wants to enroll in E2EE messaging. The instance admin can pretend to be them and push an AddKey on behalf of the user, thereby locking them out of enrolling. Evidence of this becomes immutable and public, and the user can mitigate this by getting the hell off that instance.

Scenario B. A malicious admin wants to snoop on the private messages of a user that has previously enrolled. The protocol forbids AddKey messages from being published by anyone but the user that possesses an incumbent signing key, which the instance admin does not have. They are thwarted by this policy.

Scenario C. A malicious admin remaps the user's ID and enrolls a new AddKey, and selectively reveals one ID to some users and another to other users. This would be a challenge to pull off in a useful way, since the API to get a user's ID from the instance to lookup in the Directory server will not necessarily reveal who's asking for it.

Third parties that publicly map User IDs and broadcast them on Fedi can mitigate this issue by alerting users to a difference. Although this would be annoying to integrate with a transparency log, having a watchdog service that your client software polls to ensure others see the same ID. Even as simple as automatically posting "user@instance is now at <random id here>" every time it changes would make this sort of misuse easily discoverable.

This is out of the scope of the Directory Server design, but worth considering for the overall E2EE system. Since the blog post was focused on the Directory Server design, I didn't feel like speculating when I wrote it.

Scenario D. A malicious admin remaps the user's ID and enrolls a new AddKey, but instead of selectively revealing one at a time, replaces them for all future DMs for everyone. Client software can easily detect this attack by noticing that the user's ID has changed, but the user didn't publish a MoveIdentity to their new ID.

Scenario E. A user loses all of their secret keys and wants to start the enrollment over again. The user asks the admin to perform the exact same steps as a malicious admin from Scenario D, but for legitimately honest reasons (i.e. the AddKey for the new identity actually came from the user).

Ultimately, distinguishing Scenario D and E is a social problem, not a technology problem. Detecting the behavior doesn't necessarily mean malice.