mirror of
https://github.com/matrix-org/matrix-spec
synced 2026-04-02 09:14:10 +02:00
Apply suggestions from code review
Co-Authored-By: David Baker <dbkr@users.noreply.github.com> Co-Authored-By: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com> Co-Authored-By: Erik Johnston <erikj@jki.re>
This commit is contained in:
parent
9aade7291a
commit
9dfca61ae7
|
|
@ -41,7 +41,7 @@ A key with ID `abcdefg` is stored in `m.secret_storage.key.abcdefg`
|
||||||
```json
|
```json
|
||||||
{
|
{
|
||||||
"name": "Some key",
|
"name": "Some key",
|
||||||
"algorihm": "m.secret_storage.v1.curve25519-aes-sha2",
|
"algorithm": "m.secret_storage.v1.curve25519-aes-sha2",
|
||||||
// ... other properties according to algorithm
|
// ... other properties according to algorithm
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
@ -52,7 +52,7 @@ will be encrypted with, and that clients will try to use to decrypt data with,
|
||||||
unless the user specifies otherwise. Only one key can be marked as the default
|
unless the user specifies otherwise. Only one key can be marked as the default
|
||||||
at a time.
|
at a time.
|
||||||
|
|
||||||
Encrypted data is stored in the `account_data` using the `type` defined by the
|
Encrypted data is stored in `account_data` using the `type` defined by the
|
||||||
feature that uses the data. For example, decryption keys for key backups could
|
feature that uses the data. For example, decryption keys for key backups could
|
||||||
be stored under the type `m.megolm_backup.v1.recovery_key`, or the self-signing
|
be stored under the type `m.megolm_backup.v1.recovery_key`, or the self-signing
|
||||||
key for cross-signing could be stored under the type
|
key for cross-signing could be stored under the type
|
||||||
|
|
@ -180,7 +180,7 @@ and the number of iterations given in the `iterations` parameter.
|
||||||
Rather than (or in addition to) storing secrets on the server encrypted by a
|
Rather than (or in addition to) storing secrets on the server encrypted by a
|
||||||
shared key, devices can send secrets to each other, encrypted using olm.
|
shared key, devices can send secrets to each other, encrypted using olm.
|
||||||
|
|
||||||
To request a secret, a client sends a `m.secret.request` event with `action`
|
To request a secret, a client sends a `m.secret.request` device event with `action`
|
||||||
set to `request` to other devices, and `name` set to the name of the secret
|
set to `request` to other devices, and `name` set to the name of the secret
|
||||||
that it wishes to retrieve. A device that wishes to share the secret will
|
that it wishes to retrieve. A device that wishes to share the secret will
|
||||||
reply with a `m.secret.send` event, encrypted using olm. When the original
|
reply with a `m.secret.send` event, encrypted using olm. When the original
|
||||||
|
|
@ -229,8 +229,8 @@ also define a secret key mechanism.
|
||||||
|
|
||||||
## Potential issues
|
## Potential issues
|
||||||
|
|
||||||
Keeping all the data and keys in account data means that it may clutter up the
|
Keeping all the data and keys in account data means that it may clutter up
|
||||||
`/sync`. However, clients can filter out the data that they are not interested
|
`/sync` requests. However, clients can filter out the data that they are not interested
|
||||||
in. One possibility for addressing this would be to add a flag to the account
|
in. One possibility for addressing this would be to add a flag to the account
|
||||||
data to indicate whether it should come down the `/sync` or not.
|
data to indicate whether it should come down the `/sync` or not.
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue