Add a hyphen between third and party when used as an adjective (matri…

…x-org#1447)

attic/drafts/model/rooms.rst

@@ -246,7 +246,7 @@ anyway.
 In this arrangement there is now a room with both users may join but neither has
 the power to invite any others. Both users now have the confidence that (at
 least within the messaging system itself) their messages remain private and
-cannot later be provably leaked to a third party. They can freely set the topic
+cannot later be provably leaked to a third-party. They can freely set the topic
 or name if they choose and add or edit any other state of the room. The update
 powerlevel of each of these fixed properties should be 1, to lock out the users
 from being able to alter them.

attic/drafts/model/third-party-id.rst

@@ -1,9 +1,9 @@
 ======================
-Third Party Identities
+Third-party Identities
 ======================
 
-A description of how email addresses, mobile phone numbers and other third
-party identifiers can be used to authenticate and discover users in Matrix.
+A description of how email addresses, mobile phone numbers and other third-party
+identifiers can be used to authenticate and discover users in Matrix.
 
 
 Overview
@@ -15,16 +15,16 @@ and phone numbers for contacts in their address book. They want to communicate
 with those contacts in Matrix without manually exchanging a Matrix User ID with 
 them.
 
-Third Party IDs
+Third-party IDs
 ---------------
 
 [[TODO(markjh): Describe the format of a 3PID]]
 
 
-Third Party ID Associations
+Third-party ID Associations
 ---------------------------
 
-An Associaton is a binding between a Matrix User ID and a Third Party ID (3PID).
+An Associaton is a binding between a Matrix User ID and a Third-party ID (3PID).
 Each 3PID can be associated with one Matrix User ID at a time.
 
 [[TODO(markjh): JSON format of the association.]]

changelogs/application_service/newsfragments/1447.clarification

@@ -0,0 +1 @@
+Fix various typos throughout the specification.

changelogs/client_server/newsfragments/1447.clarification

@@ -0,0 +1 @@
+Fix various typos throughout the specification.

changelogs/legacy/application_service.rst

@@ -22,5 +22,5 @@ r0.1.0
 
 This is the first release of the Application Service specification. It
 includes support for application services being able to interact with
-homeservers and bridge third party networks, such as IRC, over to Matrix
+homeservers and bridge third-party networks, such as IRC, over to Matrix
 in a standard and accessible way.

changelogs/legacy/client_server.rst

@@ -211,7 +211,7 @@ Backwards Compatible Changes
 - Add a common standard for user, room, and group mentions in messages. (`#1547 <https://github.com/matrix-org/matrix-doc/issues/1547>`_)
 - Add server ACLs as an option for controlling federation in a room. (`#1550 <https://github.com/matrix-org/matrix-doc/issues/1550>`_)
 - Add new push rules for encrypted events and ``@room`` notifications. (`#1551 <https://github.com/matrix-org/matrix-doc/issues/1551>`_)
-- Add third party network room directories, as provided by application services. (`#1554 <https://github.com/matrix-org/matrix-doc/issues/1554>`_)
+- Add third-party network room directories, as provided by application services. (`#1554 <https://github.com/matrix-org/matrix-doc/issues/1554>`_)
 - Document the ``validated_at`` and ``added_at`` fields on ``GET /acount/3pid``. (`#1567 <https://github.com/matrix-org/matrix-doc/issues/1567>`_)
 - Add an ``inhibit_login`` registration option. (`#1589 <https://github.com/matrix-org/matrix-doc/issues/1589>`_)
 - Recommend that servers set a Content Security Policy for the content repository. (`#1600 <https://github.com/matrix-org/matrix-doc/issues/1600>`_)
@@ -554,7 +554,7 @@ Since the draft stage, the following major changes have been made:
   - Push notification
   - History visibility
   - Search
-  - Invites based on third party identifiers
+  - Invites based on third-party identifiers
   - Room tagging
   - Guest access
   - Client config

changelogs/legacy/identity_service.rst

@@ -48,7 +48,7 @@ r0.1.0
 ======
 
 This is the first release of the Identity Service API. With this API, clients and
-homeservers can store bindings between third party identifiers such as email addresses
+homeservers can store bindings between third-party identifiers such as email addresses
 and phone numbers, associating them with Matrix user IDs. Additionally, identity
-servers offer the ability to invite third party users to Matrix rooms by storing
+servers offer the ability to invite third-party users to Matrix rooms by storing
 the invite until the identifier is bound.

changelogs/server_server/newsfragments/1447.clarification

@@ -0,0 +1 @@
+Fix various typos throughout the specification.

content/_index.md

@@ -372,7 +372,7 @@ servers that are in the room that can be used to join via.
 Users in Matrix are identified via their Matrix user ID. However,
 existing 3rd party ID namespaces can also be used in order to identify
 Matrix users. A Matrix "Identity" describes both the user ID and any
-other existing IDs from third party namespaces *linked* to their
+other existing IDs from third-party namespaces *linked* to their
 account. Matrix users can *link* third-party IDs (3PIDs) such as email
 addresses, social network accounts and phone numbers to their user ID.
 Linking 3PIDs creates a mapping from a 3PID to a user ID. This mapping

content/appendices.md

@@ -892,7 +892,7 @@ unique servers based on the following criteria:
 
 ## 3PID Types
 
-Third Party Identifiers (3PIDs) represent identifiers on other
+Third-party Identifiers (3PIDs) represent identifiers on other
 namespaces that might be associated with a particular person. They
 comprise a tuple of `medium` which is a string that identifies the
 namespace in which the identifier exists, and an `address`: a string

content/application-service-api.md

@@ -232,18 +232,18 @@ mappings.
 
 {{% http-api spec="application-service" api="query_room" %}}
 
-#### Third party networks
+#### Third-party networks
 
 Application services may declare which protocols they support via their
 registration configuration for the homeserver. These networks are
-generally for third party services such as IRC that the application
+generally for third-party services such as IRC that the application
 service is managing. Application services may populate a Matrix room
 directory for their registered protocols, as defined in the
 Client-Server API Extensions.
 
-Each protocol may have several "locations" (also known as "third party
+Each protocol may have several "locations" (also known as "third-party
 locations" or "3PLs"). A location within a protocol is a place in the
-third party network, such as an IRC channel. Users of the third party
+third-party network, such as an IRC channel. Users of the third-party
 network may also be represented by the application service.
 
 Locations and users can be searched by fields defined by the application
@@ -399,13 +399,13 @@ the user implied by `sender_localpart`.
 #### Application service room directories
 
 Application services can maintain their own room directories for their
-defined third party protocols. These room directories may be accessed by
+defined third-party protocols. These room directories may be accessed by
 clients through additional parameters on the `/publicRooms`
 client-server endpoint.
 
 {{% http-api spec="client-server" api="appservice_room_directory" %}}
 
-### Referencing messages from a third party network
+### Referencing messages from a third-party network
 
 Application services should include an `external_url` in the `content`
 of events it emits to indicate where the message came from. This

content/client-server-api/_index.md

@@ -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 |

content/client-server-api/modules/openid.md

@@ -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.
 

content/client-server-api/modules/third_party_invites.md

@@ -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).

content/client-server-api/modules/third_party_networks.md

@@ -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" %}}

content/identity-service-api.md

@@ -98,11 +98,11 @@ There was an error sending an email. Typically seen when attempting to
 verify ownership of a given email address.
 
 `M_INVALID_ADDRESS`
-The provided third party address was not valid.
+The provided third-party address was not valid.
 
 `M_SEND_ERROR`
 There was an error sending a notification. Typically seen when
-attempting to verify ownership of a given third party address.
+attempting to verify ownership of a given third-party address.
 
 `M_UNRECOGNIZED`
 The request contained an unrecognised value, such as an unknown token or
@@ -114,9 +114,9 @@ not implemented or a 405 HTTP status code if the endpoint is implemented, but
 the incorrect HTTP method is used.
 
 `M_THREEPID_IN_USE`
-The third party identifier is already in use by another user. Typically
+The third-party identifier is already in use by another user. Typically
 this error will have an additional `mxid` property to indicate who owns
-the third party identifier.
+the third-party identifier.
 
 `M_UNKNOWN`
 An unknown error has occurred.
@@ -369,7 +369,7 @@ To start a session, the client makes a request to the appropriate
 token to the user, and the user provides the token to the client. The
 client then provides the token to the appropriate `/submitToken`
 endpoint, completing the session. At this point, the client should
-`/bind` the third party identifier or leave it for another entity to
+`/bind` the third-party identifier or leave it for another entity to
 bind.
 
 ### Format of a validation token