9
9
10
10
## Client considerations
11
11
12
- Clients should no longer depend on the ` creator ` property in the ` content ` of
13
- [ ` m.room.create ` ] ( /client-server-api#mroomcreate ) events. In all room versions,
14
- clients can rely on ` sender ` instead to determine a room creator.
15
-
16
- Clients should note that the format of [ ` m.room.redaction ` ] ( /client-server-api#mroomredaction )
17
- events has been modified and look for the ` redacts ` key under ` content ` instead
18
- of a top-level event property.
19
-
20
- Clients should note that the ` third_party_invite ` key of [ ` m.room.member ` ] ( /client-server-api#mroommember )
21
- events is no longer redacted, * but* will only contain the ` signed ` key after redaction.
22
-
23
12
### Redactions
24
13
25
14
{{% added-in this=true %}} The top-level ` origin ` , ` membership ` , and ` prev_state ` properties
@@ -33,6 +22,19 @@ The full redaction algorithm follows.
33
22
34
23
{{% rver-fragment name="v11-redactions" withVersioning="true" %}}
35
24
25
+ ### Event format
26
+
27
+ Clients should no longer depend on the ` creator ` property in the ` content ` of
28
+ [ ` m.room.create ` ] ( /client-server-api#mroomcreate ) events. In all room versions,
29
+ clients can rely on ` sender ` instead to determine a room creator.
30
+
31
+ The format of [ ` m.room.redaction ` ] ( /client-server-api#mroomredaction )
32
+ events has been modified. Client should look for the ` redacts ` key under ` content `
33
+ instead of a top-level event property.
34
+
35
+ The ` third_party_invite ` key of [ ` m.room.member ` ] ( /client-server-api#mroommember )
36
+ events is no longer redacted, * but* will only contain the ` signed ` key after redaction.
37
+
36
38
## Server implementation components
37
39
38
40
{{% boxes/warning %}}
0 commit comments