When establishing an X3DH communication channel, the
initiating device will need a onetime prekey, while the receiving
device will only need identity keys and prekeys. This change
is to allow for the prekey-only request to not also request
one-time keys.
Details
Details
N/A, this is mostly for design
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
Naming question
| shared/protos/identity_client.proto | ||
|---|---|---|
| 42–46 ↗ | (On Diff #23913) | I don't find the naming / comments here very clear... One is called "InitializationKeys" and the other is called "DeviceKeys". These aren't a clear dichotomy. Can you identify a naming scheme that reflects a clear dichotomy? For instance, incoming / outgoing, sending / receiving, etc. Separately, my understanding is that both of these calls are for all devices (vs. for the keyserver). Is that correct? If so, we should avoid having "Device" in one of them but not the other, as it implies that the other call might be a keyserver call (for instance). |
| 240 ↗ | (On Diff #23913) | Typo |
| shared/protos/identity_client.proto | ||
|---|---|---|
| 42–46 ↗ | (On Diff #23913) | Used Sender / Receiver instead of Initialization / Device. Expanded comment |
| shared/protos/identity_client.proto | ||
|---|---|---|
| 45 ↗ | (On Diff #23995) | I'm not sure what you're referring to in the whitepaper... the request here is for a user rather than a specific client, see ReceiverKeysForUserRequest |
| 254 ↗ | (On Diff #23995) | Not sure if this is a good idea for the long-term, but we could dedup with ReceiverKeysForUserRequest and name it eg. UserRequest or KeysForUserRequest |
| shared/protos/identity_client.proto | ||
|---|---|---|
| 45 ↗ | (On Diff #23995) | nvm i was confused |
| shared/protos/identity_client.proto | ||
|---|---|---|
| 66 ↗ | (On Diff #23995) | I don't think that adds much additional value, as protobuf is already used to hold data. Most material on X3DH seems to treat the prekey and it's signature as two sides of the same coin. |
| 254 ↗ | (On Diff #23995) | If you feel those things will always be aligned, then it makes sense to converge the two. I'm curious if userID would be even better if we will have users select the user and the app will likely already know the userID of that user. |