add clarifications, examples, etc

proposals/2732-olm-fallback-keys.md

@@ -18,6 +18,30 @@ per key algorithm.  If the user had previously uploaded a fallback key for a
 given algorithm, it is replaced -- the server will only keep one fallback key
 per algorithm for each user.
 
+When uploading fallback keys for algorithms whose key format is a signed JSON
+object, client should include a property named `fallback` with a value of
+`true`.
+
+Example:
+
+`POST /keys/upload`
+
+```json
+{
+  "fallback_keys": {
+    "signed_curve25519:AAAAAA": {
+      "key": "base64+public+key",
+      "fallback": true,
+      "signatures": {
+        "@alice:example.org": {
+          "ed25519:DEVICEID": "base64+signature"
+        }
+      }
+    }
+  }
+}
+```
+
 When Bob calls `/keys/claim` to claim one of Alice's one-time keys, but Alice
 has no one-time keys left, the homeserver will return the fallback key instead,
 if Alice had previously uploaded one.  Unlike with one-time keys, fallback keys
@@ -30,6 +54,24 @@ fallback key for the user.  If the client wants the server to have a fallback
 key for a given key algorithm, but that algorithm is not listed in
 `device_unused_fallback_keys`, the client will upload a new key as above.
 
+The `device_unused_fallback_keys` parameter must be present if the server
+supports fallback keys.  Clients can thus treat this field as an indication
+that the server supports fallback keys, and so only upload fallback keys to
+servers that support them.
+
+Example:
+
+`GET /sync`
+
+Response:
+
+```json
+{
+  // other fields...
+  "device_unused_fallback_keys": ["signed_curve25519"]
+}
+```
+
 ## Security considerations
 
 Using a fallback key rather than a one-time key has security implications.  An
@@ -51,4 +93,5 @@ to detect replays.
 
 ## Unstable prefix
 
-TODO: ...
+The `fallback_key` request parameter and the `device_unused_fallback_keys`
+response parameter will be prefixed by `org.matrix.msc2732.`.