various clarifications
@@ -45,7 +45,8 @@ On receipt of encryption keys (1st time):
1. if yes:
1. generate new key pair
2. create new backup version: `POST /room_keys/version`
- 3. display private key to user to save
+ 3. display private key to user to save TODO: specify how the key is
+ displayed
2. if no, exit and remember decision (user can change their mind later)
3. while prompting, continue to poll `GET /room_keys/versions`, as
another device may have created a backup. If so, go to 1.2.
@@ -76,7 +77,7 @@ On receipt of undecryptable message:
the user wants to request keys from other devices.)
2. if yes, prompt for private key, and get keys: `GET /room_keys/keys`
-Users can also set up or disable backups, or restore from backup via user
+Users can also set up, disable, or rotate backups, or restore from backup via user
settings.
### API
@@ -201,7 +202,7 @@ Returns the same as `PUT
#### Key format
-Session keys are encoded as a JSON object with the properties:
+Each session key is encoded as a JSON object with the properties:
- `algorithm` (string): `m.megolm.v1.aes-sha2`
- `sender_key` (string): base64-encoded device curve25519 key
@@ -211,6 +212,8 @@ Session keys are encoded as a JSON object with the properties:
devices who forwarded the session key
- `session_key` (string): base64-encoded session key
+...
+
Tradeoffs
---------
@@ -227,8 +230,11 @@ with users before sending keys to a new backup version.
Other Issues
------------
-Since many clients will receive encryption keys at around the same time,
-clients should randomly offset their requests ...
+Since many clients will receive encryption keys at around the same time, they
+will all want to back up their copies of the keys at around the same time,
+which may increase load on the server if this happens in a big room. (TODO:
+how much of an issue is this?) For this reason, clients should offset their
+backup requests randomly.
Conclusion
----------
