mirror of
https://github.com/matrix-org/matrix-spec
synced 2026-04-20 09:54:10 +02:00
Compare commits
4 commits
80cfd40518
...
6c06c9cf3c
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
6c06c9cf3c | ||
|
|
23ff7f1343 | ||
|
|
69aba13aa7 | ||
|
|
53424874c9 |
|
|
@ -0,0 +1 @@
|
|||
"Public" rooms with respect to call invites are defined through their join rule.
|
||||
|
|
@ -0,0 +1 @@
|
|||
Fix various typos throughout the specification.
|
||||
|
|
@ -202,11 +202,13 @@ specific user, and should be set to the Matrix user ID of that user. Invites
|
|||
without an `invitee` field are defined to be intended for any member of the
|
||||
room other than the sender of the event.
|
||||
|
||||
Clients should consider an incoming call if they see a non-expired invite event where the `invitee` field is either
|
||||
absent or equal to their user's Matrix ID, however they should evaluate whether or not to ring based on their
|
||||
user's trust relationship with the callers and/or where the call was placed. As a starting point, it is
|
||||
suggested that clients ignore call invites from users in public rooms. It is strongly recommended that
|
||||
when clients do not ring for an incoming call invite, they still display the call invite in the room and
|
||||
Clients should consider an incoming call if they see a non-expired invite event
|
||||
where the `invitee` field is either absent or equal to their user's Matrix ID.
|
||||
They should, however, evaluate whether or not to ring based on their user's trust
|
||||
relationship with the callers and/or where the call was placed. As a starting
|
||||
point, it is RECOMMENDED that clients ignore call invites in rooms with a
|
||||
[join rule](#mroomjoin_rules) of `public`. When clients suppress ringing for an
|
||||
incoming call invite, they SHOULD still display the call invite in the room and
|
||||
annotate that it was ignored.
|
||||
|
||||
##### Glare
|
||||
|
|
|
|||
|
|
@ -1337,7 +1337,7 @@ calculated as follows.
|
|||
The *content hash* of an event covers the complete event including the
|
||||
*unredacted* contents. It is calculated as follows.
|
||||
|
||||
First, any existing `unsigned`, `signature`, and `hashes` members are
|
||||
First, any existing `unsigned`, `signatures`, and `hashes` properties are
|
||||
removed. The resulting object is then encoded as [Canonical
|
||||
JSON](/appendices#canonical-json), and the JSON is hashed using
|
||||
SHA-256.
|
||||
|
|
|
|||
Loading…
Reference in a new issue