Add a hyphen between third and party when used as an adjective (#1447)
This commit is contained in:
Andrew Morgan
GitHub
parent
9ebcf5f257
commit
c0955a6aee
37 changed files with 190 additions and 187 deletions
|
|
@ -150,15 +150,15 @@ Sent when a threepid given to an API cannot be used because no record
|
|||
matching the threepid was found.
|
||||
|
||||
`M_THREEPID_AUTH_FAILED`
|
||||
Authentication could not be performed on the third party identifier.
|
||||
Authentication could not be performed on the third-party identifier.
|
||||
|
||||
`M_THREEPID_DENIED`
|
||||
The server does not permit this third party identifier. This may happen
|
||||
The server does not permit this third-party identifier. This may happen
|
||||
if the server only permits, for example, email addresses from a
|
||||
particular domain.
|
||||
|
||||
`M_SERVER_NOT_TRUSTED`
|
||||
The client's request used a third party server, e.g. identity server,
|
||||
The client's request used a third-party server, e.g. identity server,
|
||||
that this server does not trust.
|
||||
|
||||
`M_UNSUPPORTED_ROOM_VERSION`
|
||||
|
|
@ -764,8 +764,8 @@ explicitly as follows:
|
|||
"type": "m.login.password",
|
||||
"identifier": {
|
||||
"type": "m.id.thirdparty",
|
||||
"medium": "<The medium of the third party identifier.>",
|
||||
"address": "<The third party address of the user>"
|
||||
"medium": "<The medium of the third-party identifier.>",
|
||||
"address": "<The third-party address of the user>"
|
||||
},
|
||||
"password": "<password>",
|
||||
"session": "<session ID>"
|
||||
|
|
@ -1071,8 +1071,8 @@ ID media.
|
|||
```json
|
||||
"identifier": {
|
||||
"type": "m.id.thirdparty",
|
||||
"medium": "<The medium of the third party identifier>",
|
||||
"address": "<The canonicalised third party address of the user>"
|
||||
"medium": "<The medium of the third-party identifier>",
|
||||
"address": "<The canonicalised third-party address of the user>"
|
||||
}
|
||||
```
|
||||
|
||||
|
|
@ -1132,8 +1132,8 @@ the homeserver using the [`/account/3pid`](#get_matrixclientv3account3pid) API r
|
|||
{
|
||||
"type": "m.login.password",
|
||||
"identifier": {
|
||||
"medium": "<The medium of the third party identifier>",
|
||||
"address": "<The canonicalised third party address of the user>"
|
||||
"medium": "<The medium of the third-party identifier>",
|
||||
"address": "<The canonicalised third-party address of the user>"
|
||||
},
|
||||
"password": "<password>"
|
||||
}
|
||||
|
|
@ -1258,7 +1258,7 @@ can be added and bound at the same time, depending on context.
|
|||
#### Notes on identity servers
|
||||
|
||||
Identity servers in Matrix store bindings (relationships) between a
|
||||
user's third party identifier, typically email or phone number, and
|
||||
user's third-party identifier, typically email or phone number, and
|
||||
their user ID. Once a user has chosen an identity server, that identity
|
||||
server should be used by all clients.
|
||||
|
||||
|
|
@ -2566,7 +2566,7 @@ that profile.
|
|||
| [Room Upgrades](#room-upgrades) | Required | Required | Required | Required | Optional |
|
||||
| [Server Administration](#server-administration) | Optional | Optional | Optional | Optional | Optional |
|
||||
| [Event Context](#event-context) | Optional | Optional | Optional | Optional | Optional |
|
||||
| [Third Party Networks](#third-party-networks) | Optional | Optional | Optional | Optional | Optional |
|
||||
| [Third-party Networks](#third-party-networks) | Optional | Optional | Optional | Optional | Optional |
|
||||
| [Send-to-Device Messaging](#send-to-device-messaging) | Optional | Optional | Optional | Optional | Optional |
|
||||
| [Device Management](#device-management) | Optional | Optional | Optional | Optional | Optional |
|
||||
| [End-to-End Encryption](#end-to-end-encryption) | Optional | Optional | Optional | Optional | Optional |
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
|
||||
### OpenID
|
||||
|
||||
This module allows users to verify their identity with a third party
|
||||
service. The third party service does need to be matrix-aware in that it
|
||||
This module allows users to verify their identity with a third-party
|
||||
service. The third-party service does need to be matrix-aware in that it
|
||||
will need to know to resolve matrix homeservers to exchange the user's
|
||||
token for identity information.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +1,12 @@
|
|||
|
||||
### Third party invites
|
||||
### Third-party invites
|
||||
|
||||
This module adds in support for inviting new members to a room where
|
||||
their Matrix user ID is not known, instead addressing them by a third
|
||||
party identifier such as an email address. There are two flows here; one
|
||||
if a Matrix user ID is known for the third party identifier, and one if
|
||||
their Matrix user ID is not known, instead addressing them by a third-party
|
||||
identifier such as an email address. There are two flows here; one
|
||||
if a Matrix user ID is known for the third-party identifier, and one if
|
||||
not. Either way, the client calls `/invite` with the details of the
|
||||
third party identifier.
|
||||
third-party identifier.
|
||||
|
||||
The homeserver asks the identity server whether a Matrix user ID is
|
||||
known for that identifier:
|
||||
|
|
@ -22,7 +22,7 @@ When the invitee's homeserver receives the notification of the binding,
|
|||
it should insert an `m.room.member` event into the room's graph for that
|
||||
user, with `content.membership` = `invite`, as well as a
|
||||
`content.third_party_invite` property which contains proof that the
|
||||
invitee does indeed own that third party identifier. See the
|
||||
invitee does indeed own that third-party identifier. See the
|
||||
[m.room.member](#mroommember) schema for more information.
|
||||
|
||||
#### Events
|
||||
|
|
@ -31,14 +31,14 @@ invitee does indeed own that third party identifier. See the
|
|||
|
||||
#### Client behaviour
|
||||
|
||||
A client asks a server to invite a user by their third party identifier.
|
||||
A client asks a server to invite a user by their third-party identifier.
|
||||
|
||||
{{% http-api spec="client-server" api="third_party_membership" %}}
|
||||
|
||||
#### Server behaviour
|
||||
|
||||
Upon receipt of an `/invite`, the server is expected to look up the
|
||||
third party identifier with the provided identity server. If the lookup
|
||||
third-party identifier with the provided identity server. If the lookup
|
||||
yields a result for a Matrix User ID then the normal invite process can
|
||||
be initiated. This process ends up looking like this:
|
||||
|
||||
|
|
@ -104,12 +104,12 @@ looking like this:
|
|||
All homeservers MUST verify the signature in the event's
|
||||
`content.third_party_invite.signed` object.
|
||||
|
||||
The third party user will then need to verify their identity, which
|
||||
The third-party user will then need to verify their identity, which
|
||||
results in a call from the identity server to the homeserver that bound
|
||||
the third party identifier to a user. The homeserver then exchanges the
|
||||
the third-party identifier to a user. The homeserver then exchanges the
|
||||
`m.room.third_party_invite` event in the room for a complete
|
||||
`m.room.member` event for `membership: invite` for the user that has
|
||||
bound the third party identifier.
|
||||
bound the third-party identifier.
|
||||
|
||||
If a homeserver is joining a room for the first time because of an
|
||||
`m.room.third_party_invite`, the server which is already participating
|
||||
|
|
@ -123,7 +123,7 @@ view of the room. They may, however, indicate to their clients that a
|
|||
member's membership is questionable.
|
||||
|
||||
For example, given H1, H2, and H3 as homeservers, UserA as a user of H1,
|
||||
and an identity server IS, the full sequence for a third party invite
|
||||
and an identity server IS, the full sequence for a third-party invite
|
||||
would look like the following. This diagram assumes H1 and H2 are
|
||||
residents of the room while H3 is attempting to join.
|
||||
|
||||
|
|
@ -144,7 +144,7 @@ residents of the room while H3 is attempting to join.
|
|||
| | | POST /store-invite | | |
|
||||
| | |---------------------------------------------------------------------------------------------->|
|
||||
| | | | | |
|
||||
| | | | Token, keys, etc for third party invite |
|
||||
| | | | Token, keys, etc for third-party invite |
|
||||
| | |<----------------------------------------------------------------------------------------------|
|
||||
| | | | | |
|
||||
| | | (Federation) Emit m.room.third_party_invite | | |
|
||||
|
|
@ -214,13 +214,13 @@ still be performed, so the attack surface here is minimized.
|
|||
There are a number of privacy and trust implications to this module.
|
||||
|
||||
It is important for user privacy that leaking the mapping between a
|
||||
matrix user ID and a third party identifier is hard. In particular,
|
||||
being able to look up all third party identifiers from a matrix user ID
|
||||
(and accordingly, being able to link each third party identifier) should
|
||||
be avoided wherever possible. To this end, the third party identifier is
|
||||
matrix user ID and a third-party identifier is hard. In particular,
|
||||
being able to look up all third-party identifiers from a matrix user ID
|
||||
(and accordingly, being able to link each third-party identifier) should
|
||||
be avoided wherever possible. To this end, the third-party identifier is
|
||||
not put in any event, rather an opaque display name provided by the
|
||||
identity server is put into the events. Clients should not remember or
|
||||
display third party identifiers from invites, other than for the use of
|
||||
display third-party identifiers from invites, other than for the use of
|
||||
the inviter themself.
|
||||
|
||||
Homeservers are not required to trust any particular identity server(s).
|
||||
|
|
|
|||
|
|
@ -1,18 +1,18 @@
|
|||
|
||||
### Third Party Networks
|
||||
### Third-party Networks
|
||||
|
||||
Application services can provide access to third party networks via
|
||||
Application services can provide access to third-party networks via
|
||||
bridging. This allows Matrix users to communicate with users on other
|
||||
communication platforms, with messages ferried back and forth by the
|
||||
application service. A single application service may bridge multiple
|
||||
third party networks, and many individual locations within those
|
||||
networks. A single third party network location may be bridged to
|
||||
third-party networks, and many individual locations within those
|
||||
networks. A single third-party network location may be bridged to
|
||||
multiple Matrix rooms.
|
||||
|
||||
#### Third Party Lookups
|
||||
#### Third-party Lookups
|
||||
|
||||
A client may wish to provide a rich interface for joining third party
|
||||
locations and connecting with third party users. Information necessary
|
||||
for such an interface is provided by third party lookups.
|
||||
A client may wish to provide a rich interface for joining third-party
|
||||
locations and connecting with third-party users. Information necessary
|
||||
for such an interface is provided by third-party lookups.
|
||||
|
||||
{{% http-api spec="client-server" api="third_party_lookup" %}}
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue