wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Fully specify room versions (#3432)

Browse source 
* Fully specify room versions

* Misc typo clarifications

* Try to clarify redactions a bit

* Update content/client-server-api/_index.md

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>

* Update content/rooms/v6.md

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>

* Update content/rooms/v6.md

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>

* Better describe client considerations

* Doc template params

* Move redaction "new stuff" to v3

* Remove unhelpful sentences about "here follows unchanged stuff"

* Simplify event signing text

* Clean up handling redactions sections

* Move v4's event schema to unchanged section

* Update content/rooms/v4.md

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
This commit is contained in:
Travis Ralston 2021-11-01 08:49:15 -06:00 • committed by GitHub
parent b873ba984c
commit 241e01c332
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
19 changed files with 1082 additions and 439 deletions
Download patch file Download diff file Expand all files Collapse all files

51
content/rooms/v5.md
View file

@ -9,9 +9,9 @@ key validity periods for events.
## Client considerations
There are no specific requirements for clients in this room version.
Clients should be aware of event ID changes in [room version
4](/rooms/v4), however.
There are no client considerations introduced in this room version. Clients
which implement the redaction algorithm locally should refer to the
[redactions](#redactions) section below for a full overview of the algorithm.
## Server implementation components
@ -28,18 +28,35 @@ Room version 5 uses the same algorithms defined in [room version
### Signing key validity period
When validating event signatures, servers MUST enforce the
`valid_until_ts` property from a key request is at least as large as the
`origin_server_ts` for the event being validated. Servers missing a copy
of the signing key MUST try to obtain one via the [GET
/\_matrix/key/v2/server](/server-server-api#get_matrixkeyv2serverkeyid)
or [POST
/\_matrix/key/v2/query](/server-server-api#post_matrixkeyv2query)
APIs. When using the `/query` endpoint, servers MUST set the
`minimum_valid_until_ts` property to prompt the notary server to attempt
to refresh the key if appropriate.
{{% rver-fragment name="v5-signing-requirements" %}}
Servers MUST use the lesser of `valid_until_ts` and 7 days into the
future when determining if a key is valid. This is to avoid a situation
where an attacker publishes a key which is valid for a significant
amount of time without a way for the homeserver owner to revoke it.
## Unchanged from v4
The following sections have not been modified since v4, but are included for
completeness.
### State resolution
{{% rver-fragment name="v2-state-res" %}}
### Authorization rules
{{% rver-fragment name="v3-auth-rules" %}}
### Handling redactions
{{% rver-fragment name="v3-handling-redactions" %}}
### Event format
{{% rver-fragment name="v4-event-explainer" %}}
{{% definition path="api/server-server/definitions/pdu_v4" %}}
### Canonical JSON
{{% rver-fragment name="v1-canonical-json" %}}
### Redactions
{{% rver-fragment name="v1-redactions" %}}