It's actually an "identity server implementing the Identity Service API"

Also add a note about appservices being special.

api/client-server/administrative_contact.yaml

@@ -187,7 +187,7 @@ paths:
     post:
       summary: Begins the validation process for an email address for association with the user's account.
       description: |-
-        Proxies the identity server API ``validate/email/requestToken``, but
+        Proxies the Identity Service API ``validate/email/requestToken``, but
         first checks that the given email address is **not** already associated
         with an account on this homeserver. This API should be used to request
         validation tokens when adding an email address to an account. This API's
@@ -241,7 +241,7 @@ paths:
     post:
       summary: Begins the validation process for a phone number for association with the user's account.
       description: |-
-        Proxies the identity server API ``validate/msisdn/requestToken``, but
+        Proxies the Identity Service API ``validate/msisdn/requestToken``, but
         first checks that the given phone number is **not** already associated
         with an account on this homeserver. This API should be used to request
         validation tokens when adding a phone number to an account. This API's

api/client-server/create_room.yaml

@@ -141,7 +141,7 @@ paths:
                       description: The hostname+port of the identity server which should be used for third party identifier lookups.
                     medium:
                       type: string
-                      # TODO: Link to identity server spec when it eixsts
+                      # TODO: Link to Identity Service spec when it eixsts
                       description: The kind of address being passed in the address field, for example ``email``.
                     address:
                       type: string

api/client-server/registration.yaml

@@ -204,9 +204,9 @@ paths:
     post:
       summary: Begins the validation process for an email to be used during registration.
       description: |-
-        Proxies the identity server API ``validate/email/requestToken``, but
+        Proxies the Identity Service API ``validate/email/requestToken``, but
         first checks that the given email address is not already associated
-        with an account on this homeserver. See the identity server API for
+        with an account on this homeserver. See the Identity Service API for
         further information.
       operationId: requestTokenToRegisterEmail
       parameters:
@@ -264,9 +264,9 @@ paths:
     post:
       summary: Requests a validation token be sent to the given phone number for the purpose of registering an account
       description: |-
-        Proxies the identity server API ``validate/msisdn/requestToken``, but
+        Proxies the Identity Service API ``validate/msisdn/requestToken``, but
         first checks that the given phone number is not already associated
-        with an account on this homeserver. See the identity server API for
+        with an account on this homeserver. See the Identity Service API for
         further information.
       operationId: requestTokenToRegisterMSISDN
       parameters:
@@ -373,7 +373,7 @@ paths:
     post:
       summary: Requests a validation token be sent to the given email address for the purpose of resetting a user's password
       description: |-
-        Proxies the identity server API ``validate/email/requestToken``, but
+        Proxies the Identity Service API ``validate/email/requestToken``, but
         first checks that the given email address **is** associated with an account
         on this homeserver. This API should be used to request
         validation tokens when authenticating for the
@@ -435,7 +435,7 @@ paths:
     post:
       summary: Requests a validation token be sent to the given phone number for the purpose of resetting a user's password.
       description: |-
-        Proxies the identity server API ``validate/msisdn/requestToken``, but
+        Proxies the Identity Service API ``validate/msisdn/requestToken``, but
         first checks that the given phone number **is** associated with an account
         on this homeserver. This API should be used to request
         validation tokens when authenticating for the

api/client-server/third_party_membership.yaml

@@ -101,7 +101,7 @@ paths:
                 description: The hostname+port of the identity server which should be used for third party identifier lookups.
               medium:
                 type: string
-                # TODO: Link to identity server spec when it eixsts
+                # TODO: Link to Identity Service spec when it eixsts
                 description: The kind of address being passed in the address field, for example ``email``.
               address:
                 type: string

api/identity/associations.yaml

@@ -13,7 +13,7 @@
 # limitations under the License.
 swagger: '2.0'
 info:
-  title: "Matrix Identity Server Establishing Associations API"
+  title: "Matrix Identity Service Establishing Associations API"
   version: "1.0.0"
 host: localhost:8090
 schemes:

api/identity/email_associations.yaml

@@ -13,7 +13,7 @@
 # limitations under the License.
 swagger: '2.0'
 info:
-  title: "Matrix Identity Server Email Associations API"
+  title: "Matrix Identity Service Email Associations API"
   version: "1.0.0"
 host: localhost:8090
 schemes:

api/identity/invitation_signing.yaml

@@ -13,7 +13,7 @@
 # limitations under the License.
 swagger: '2.0'
 info:
-  title: "Matrix Identity Server Ephemeral Invitation Signing API"
+  title: "Matrix Identity Service Ephemeral Invitation Signing API"
   version: "1.0.0"
 host: localhost:8090
 schemes:

api/identity/lookup.yaml

@@ -16,7 +16,7 @@
 # limitations under the License.
 swagger: '2.0'
 info:
-  title: "Matrix Identity Server Lookup  API"
+  title: "Matrix Identity Service Lookup  API"
   version: "1.0.0"
 host: localhost:8090
 schemes:

api/identity/phone_associations.yaml

@@ -13,7 +13,7 @@
 # limitations under the License.
 swagger: '2.0'
 info:
-  title: "Matrix Identity Server Phone Number Associations API"
+  title: "Matrix Identity Service Phone Number Associations API"
   version: "1.0.0"
 host: localhost:8090
 schemes:

api/identity/ping.yaml

@@ -15,7 +15,7 @@
 
 swagger: "2.0"
 info:
-  title: "Matrix Identity Server Ping API"
+  title: "Matrix Identity Service Ping API"
   version: "1.0.0"
 host: localhost:8090
 schemes:

api/identity/pubkey.yaml

@@ -13,7 +13,7 @@
 # limitations under the License.
 swagger: '2.0'
 info:
-  title: "Matrix Identity Server Public Key API"
+  title: "Matrix Identity Service Public Key API"
   version: "1.0.0"
 host: localhost:8090
 schemes:

api/identity/store_invite.yaml

@@ -13,7 +13,7 @@
 # limitations under the License.
 swagger: '2.0'
 info:
-  title: "Matrix Identity Server Store Invitations API"
+  title: "Matrix Identity Service Store Invitations API"
   version: "1.0.0"
 host: localhost:8090
 schemes:

changelogs/identity_service/pyproject.toml

@@ -1,5 +1,5 @@
 [tool.towncrier]
-    filename = "../identity_server.rst"
+    filename = "../identity_service.rst"
     directory = "newsfragments"
     issue_format = "`#{issue} <https://github.com/matrix-org/matrix-doc/issues/{issue}>`_"
     title_format = "{version}"

meta/documentation_style.rst

@@ -71,6 +71,10 @@ Prefer British English (colour, -ise) to American English.
 The word "homeserver" is spelt thus (rather than "home server", "Homeserver",
 or (argh) "Home Server"). However, an identity server is two words.
 
+An "identity server" (spelt thus) implements the Identity Service API (also spelt
+thus). However, "Application Services" (spelt thus) implement the Application Service
+API. Application Services should not be called "appservices" in documentation.
+
 .. Rationale: "homeserver" distinguishes from a "home server" which is a server
    you have at home. "identity server" is clear, whereas "identityserver" is
    horrible.

meta/releasing_a_spec.md

@@ -1,7 +1,7 @@
 # How to release a specification
 
 There are several specifications that belong to matrix, such as the client-server
-specification, server-server specification, and identity server specification. Each
+specification, server-server specification, and identity service specification. Each
 of these gets released independently of each other with their own version numbers.
 
 Once a specification is ready for release, a branch should be created to track the

scripts/gendoc.py

@@ -527,7 +527,7 @@ if __name__ == '__main__':
     )
     parser.add_argument(
         "--identity_release", "-i", action="store", default="unstable",
-        help="The identity server release tag to generate, e.g. r1.2"
+        help="The identity service release tag to generate, e.g. r1.2"
     )
     parser.add_argument(
         "--list_targets", action="store_true",

scripts/templating/matrix_templates/sections.py

@@ -37,9 +37,9 @@ class MatrixSections(Sections):
         changelogs = self.units.get("changelogs")
         return changelogs["push_gateway"]
 
-    def render_identity_server_changelog(self):
+    def render_identity_service_changelog(self):
         changelogs = self.units.get("changelogs")
-        return changelogs["identity_server"]
+        return changelogs["identity_service"]
 
     def render_server_server_changelog(self):
         changelogs = self.units.get("changelogs")

scripts/templating/matrix_templates/units.py

@@ -773,7 +773,7 @@ class MatrixUnits(Units):
                 as_ver,
                 "Privileged server plugins",
             ), TypeTableRow(
-                "`Identity Server API <identity_server/"+is_ver+".html>`_",
+                "`Identity Service API <identity_service/"+is_ver+".html>`_",
                 "unstable",
                 "Mapping of third party IDs to Matrix IDs",
             ), TypeTableRow(

specification/identity_service_api.rst

@@ -15,7 +15,7 @@
 .. See the License for the specific language governing permissions and
 .. limitations under the License.
 
-Identity Server API
+Identity Service API
 ====================
 
 {{unstable_warning_block_IDENTITY_RELEASE_LABEL}}
@@ -35,14 +35,14 @@ Changelog
 ---------
 
 .. topic:: Version: %IDENTITY_RELEASE_LABEL%
-{{identity_server_changelog}}
+{{identity_service_changelog}}
 
 This version of the specification is generated from
 `matrix-doc <https://github.com/matrix-org/matrix-doc>`_ as of Git commit
 `{{git_version}} <https://github.com/matrix-org/matrix-doc/tree/{{git_rev}}>`_.
 
 For the full historical changelog, see
-https://github.com/matrix-org/matrix-doc/blob/master/changelogs/identity_server.rst
+https://github.com/matrix-org/matrix-doc/blob/master/changelogs/identity_service.rst
 
 
 Other versions of this specification
@@ -50,7 +50,7 @@ Other versions of this specification
 
 The following other versions are also available, in reverse chronological order:
 
-- `HEAD <https://matrix.org/docs/spec/identity_server/unstable.html>`_: Includes all changes since the latest versioned release.
+- `HEAD <https://matrix.org/docs/spec/identity_service/unstable.html>`_: Includes all changes since the latest versioned release.
 
 General principles
 ------------------

specification/modules/third_party_invites.rst

@@ -215,7 +215,7 @@ H1 MUST verify the request from H3 to ensure the ``signed`` property is correct
 as well as the ``key_validity_url`` as still being valid. This is done by making
 a request to the `identity server /isvalid`_ endpoint, using the provided URL
 rather than constructing a new one. The query string and response for the provided
-URL must match the identity server specification.
+URL must match the identity service specification.
 
 The reason that no other homeserver may reject the event based on checking
 ``key_validity_url`` is that we must ensure event acceptance is deterministic.
@@ -254,4 +254,4 @@ these is left to the implementer's discretion.
 
 
 
-.. _`identity server /isvalid`: ../identity_server/unstable.html#get-matrix-identity-api-v1-pubkey-isvalid
+.. _`identity server /isvalid`: ../identity_service/unstable.html#get-matrix-identity-api-v1-pubkey-isvalid

specification/server_server_api.rst

@@ -845,7 +845,7 @@ ID to invite, they can do so using a third-party identifier (e.g. an e-mail or a
 phone number).
 
 This identifier and its bindings to Matrix IDs are verified by an identity server
-implementing the `identity server API`_.
+implementing the `Identity Service API`_.
 
 Cases where an association exists for a third-party identifier
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -866,7 +866,7 @@ request.
 
 When a third-party identifier with pending invites gets bound to a Matrix ID,
 the identity server will send a POST request to the ID's homeserver as described
-in the `Invitation Storage`_ section of the identity server API.
+in the `Invitation Storage`_ section of the Identity Service API.
 
 The following process applies for each invite sent by the identity server:
 
@@ -1192,8 +1192,8 @@ Example code
 .. |/query/directory| replace:: ``/query/directory``
 .. _/query/directory: #get-matrix-federation-v1-query-directory
 
-.. _`Invitation storage`: ../identity_server/%IDENTITY_RELEASE_LABEL%.html#invitation-storage
-.. _`identity server API`: ../identity_server/%IDENTITY_RELEASE_LABEL%.html
+.. _`Invitation storage`: ../identity_service/%IDENTITY_RELEASE_LABEL%.html#invitation-storage
+.. _`Identity Service API`: ../identity_service/%IDENTITY_RELEASE_LABEL%.html
 .. _`Client-Server API`: ../client_server/%CLIENT_RELEASE_LABEL%.html
 .. _`Inviting to a room`: #inviting-to-a-room
 .. _`Canonical JSON`: ../appendices.html#canonical-json

specification/targets.yaml

@@ -18,9 +18,9 @@ targets:
     files:
       - server_server_api.rst
     version_label: "%SERVER_RELEASE_LABEL%"
-  identity_server:
+  identity_service:
     files:
-      - identity_server_api.rst
+      - identity_service_api.rst
     version_label: "%IDENTITY_RELEASE_LABEL%"
   push_gateway:
     files: