[pre-MSC] rooms-as-discovery-services with zero-knowledge-proofs

(Forgive me if my knowledge on ZKPs is incomplete or "plain wrong" :sweat_smile:)

Original ramble on this begins [here](https://matrix.to/#/!NasysSDfxKxZBzJJoE:matrix.org/$IiTETpv7DbfvA3mKMs55lJeYk_9b34-uS4uXlZGf1aI?via=matrix.org&via=vector.modular.im&via=amorgan.xyz), if anyone's interested.

### Proposal

Room-based identity services, basically a full replacement for server-based identity services, instead replacing it with a room-based variant that lets all of the magic happen automatically.

#### Discovery

The idea is simple; you join a room, you have other 3PIDs in your "address book", and others might have you in their address book.

This "first stage" is discovery, finding those people in this room, this happens by broadcasting EDUs that give some information that others might use to verify a. you are in their address book, and b. you're looking for them, and vice versa.

The hard part is doing this without giving away some information that can be scraped and "cracked" (such as hashes).

I *think* Zero-Knowledge Proofs could be used here to assert that a. "I am looking for you(r 3PID)" and b. "I am this 3PID", without revealing this to 3rd parties.

#### Verification

Once 2 users/clients find themselves searching for eachother, a "verification session" might be triggered.

This session is similar to SAS, with one crucial component; the users are verified through the 3PID in question.

The data relayed/fetched through that 3rd party is called "out of band", OOB, here.

The data relayed through matrix/to_device is called "in-band", IB, here.

For this, there are 2 variants of verification:

- Passive Verification; each party only has to look at a publicly-displayable resource on that 3rd party's server (or something with an otherwise verifiable resource origin that it is *from* that 3rd party), and compare something on that resource that becomes a cryptographic component able to be verified with the IB half.
- (think tweets, websites, gists, etc. as keybase does, currently)
- Active verification; each party has to actively "send" something to the other party, containing the same cryptographic component, only now scoped to the session.
- (think email, SMS, etc. other "underground" non-publicly-persistent messaging methods)

#### Privacy

This method of discovery can be "rough", and may reveal more than a user might want to share at any one time, in any room.

Thus, for privacy and behavioural options, there must be 3 preference settings, being able to be scoped to those individual discovery rooms;

Discovery behaviour:
- Automatic: Automatically act on matches when discovering other users in this room, and accept sessions from other users.
- Manual - Prompt: Prompt the user when matches are found, to either ignore or go ahead with them.
- Manual - Silent: Don't prompt the user when matches are found, but display them in a secluded list (optionally with "number badges" and whatnot)

Discovery broadcasting:
- On: Broadcast into the room, to discover other users.
- Off: Don't broadcast, only listen to other users.

*I don't know if with ZKP it is possible to "only listen" and gain some matches*

Active verification behaviour:
- Automatic: Automatically send assertions over OOB channels (email, SMS, etc.)
- Prompt: Prompt the user to send assertions over OOB channels (approve/disapprove).
- List: Same as above, but show it in a secluded list that a user's attention is needed to approve active verification.
- Don't: Don't do active verification (to users discovered via 'this' room).

#### Problems

Verifying through SMS has it's own problems (where authenticity comes into question), but for now that is not entirely in-scope to this MSC.

Active verification can be costly, and annoying to the users (who might get "random" notifications of received SMSes or emails from unknown sources), this is why it might be wise to keep active verification on "Prompt" by default, and when a user displays "automatic", show a little educative prompt that explains what might happen "randomly" when this happens.

For active verification, clients need active (write) access to SMS or Email services, this might either not be possible, or invasive, for some situations.

### Variants / Alternatives / Extensions

Discovery: Originally i used truncated hashes to be compared, but that caused all sorts of problems (still scrapable, brute-forcing)

One alternative is a "sentinel" user that the user verifies with one-time, and then that sentinel user knows the full 3PID that the user has verified with them, users in a particular room trust the sentinel. The sentinel provides "verified" matches of 3PIDs looked after, and 3PIDs that users have. This is a point of centralization, but it might be preferable in a controlled setting (over a somewhat-costly/wonky active verification process)

Start with the linked Matrix discussion, then read the Proposal sections on Discovery, Verification, Privacy, and Variants/Alternatives/Extensions. This is a pre-MSC design proposal with no files or tests named; completion would require an agreed, concrete specification direction rather than a localized code change.

Written by the indexing model from the issue text.