Clarifications and spelling (#2417)

* remove confusing redundant clause

Signed-off-by: HarHarLinks <2803622+HarHarLinks@users.noreply.github.com>

* clarify the class of relation disallowed in threads

Signed-off-by: HarHarLinks <2803622+HarHarLinks@users.noreply.github.com>

* spelling

Signed-off-by: HarHarLinks <2803622+HarHarLinks@users.noreply.github.com>

* add newsfragment

Signed-off-by: HarHarLinks <2803622+HarHarLinks@users.noreply.github.com>

---------

Signed-off-by: HarHarLinks <2803622+HarHarLinks@users.noreply.github.com>
This commit is contained in:
Kim Brose 2026-07-14 22:05:35 +00:00 committed by GitHub
parent 68994d7fcd
commit 97fcfd93d9
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
4 changed files with 4 additions and 3 deletions

View file

@ -0,0 +1 @@
Wording improvements and spelling fixes. Contributed by @HarHarLinks.

View file

@ -3660,7 +3660,7 @@ The actual aggregation format depends on the `rel_type`.
When an event is served to the client through the APIs listed below, a
`m.relations` property is included under `unsigned` if the event has child
events which can be aggregated and point at it. The `m.relations` property is
events which can be aggregated. The `m.relations` property is
an object keyed by `rel_type` and value being the type-specific aggregated
format for that `rel_type`. This `m.relations` property is known as a "bundled
aggregation".

View file

@ -1940,7 +1940,7 @@ As of `v1.3`, the `sender_key` and `device_id` keys are **deprecated**. They
SHOULD continue to be sent, however they MUST NOT be used to verify the
message's source.
Clients MUST NOT store or lookup sessions using the `sender_key` or `device_id`.
Clients MUST NOT store or look up sessions using the `sender_key` or `device_id`.
In a future version of the specification the keys can be removed completely,
including for sending new messages.

View file

@ -191,7 +191,7 @@ Note that, as in the example above, child events of the `latest_event` should
themselves be aggregated and included under `m.relations` for that event. The
server should be careful to avoid loops, though loops are not currently
possible due to `m.thread` not being permitted to target an event with an
`m.relates_to` property.
`m.relates_to` property with a `rel_type`.
`count` is simply the number of events using `m.thread` as a `rel_type` pointing to the target event.
It does not include events sent by [ignored users](#ignoring-users).