Consistently spell homeserver as homeserver

api/client-server/administrative_contact.yaml

@@ -25,7 +25,7 @@ paths:
         This API endpoint uses the User-Interactive Authentication API.
         An access token should be submitted to this endpoint if the client has
         an active session.
-        The Home Server may change the flows available depending on whether a
+        The homeserver may change the flows available depending on whether a
         valid access token is provided.
       security:
         - accessToken: []
@@ -64,7 +64,7 @@ paths:
         This is *not* the same as the list of third party identifiers bound to
         the user's Matrix ID in Identity Servers.
 
-        Identifiers in this list may be used by the Home Server as, for example,
+        Identifiers in this list may be used by the homeserver as, for example,
         identifiers that it will accept to reset the user's account password.
       security:
         - accessToken: []

api/client-server/login.yaml

@@ -81,7 +81,7 @@ paths:
                   (optional) A ``refresh_token`` may be exchanged for a new ``access_token`` using the /tokenrefresh API endpoint.
               home_server:
                 type: string
-                description: The hostname of the Home Server on which the account has been registered.
+                description: The hostname of the homeserver on which the account has been registered.
         400:
           description: |-
             Part of the request was invalid. For example, the login type may not be recognised.

api/client-server/pusher.yaml

@@ -114,7 +114,7 @@ paths:
                 description: |-
                   If true, the homeserver should add another pusher with the
                   given pushkey and App ID in addition to any others with
-                  different user IDs. Otherwise, the Home Server must remove any
+                  different user IDs. Otherwise, the homeserver must remove any
                   other pushers with the same App ID and pushkey for different
                   users. The default is ``false``.
             required: ['profile_tag', 'kind', 'app_id', 'app_display_name',

api/client-server/registration.yaml

@@ -94,7 +94,7 @@ paths:
                   (optional) A ``refresh_token`` may be exchanged for a new ``access_token`` using the /tokenrefresh API endpoint.
               home_server:
                 type: string
-                description: The hostname of the Home Server on which the account has been registered.
+                description: The hostname of the homeserver on which the account has been registered.
         400:
           description: |-
             Part of the request was invalid. This may include one of the following error codes:
@@ -107,7 +107,7 @@ paths:
             including after authentication if the requested user ID was registered
             whilst the client was performing authentication.
 
-            Home Servers MUST perform the relevant checks and return these codes before
+            Homeservers MUST perform the relevant checks and return these codes before
             performing `User-Interactive Authentication`_, although they may also return
             them after authentication is completed if, for example, the requested user ID
             was registered whilst the client was performing authentication.

drafts/ancient_federated_versioning_design_notes.rst

@@ -1,4 +1,4 @@
-Versioning is, like, hard for backfilling backwards because of the number of Home Servers involved.
+Versioning is, like, hard for backfilling backwards because of the number of homeservers involved.
 
 The way we solve this is by doing versioning as an acyclic directed graph of PDUs. For backfilling purposes, this is done on a per context basis.
 When we send a PDU we include all PDUs that have been received for that context that hasn't been subsequently listed in a later PDU. The trivial case is a simple list of PDUs, e.g. A <- B <- C. However, if two servers send out a PDU at the same to, both B and C would point at A - a later PDU would then list both B and C.

drafts/as-http-api.rst

@@ -13,7 +13,7 @@ Application Services HTTP API
 
 .. sectnum::
 
-Application Service -> Home Server
+Application Service -> Homeserver
 ----------------------------------
 This contains homeserver APIs which are used by the application service.
 
@@ -122,7 +122,7 @@ API called when:
   }
 
 
-Home Server -> Application Service
+Homeserver -> Application Service
 ----------------------------------
 This contains application service APIs which are used by the homeserver.
 

drafts/model/presence.rst

@@ -5,14 +5,14 @@ A simple implementation of presence messaging has the ability to cause a large
 amount of Internet traffic relating to presence updates. In order to minimise
 the impact of such a feature, the following observations can be made:
 
- * There is no point in a Home Server polling status for peers in a user's
+ * There is no point in a homeserver polling status for peers in a user's
    presence list if the user has no clients connected that care about it.
 
  * It is highly likely that most presence subscriptions will be symmetric - a
    given user watching another is likely to in turn be watched by that user.
 
  * It is likely that most subscription pairings will be between users who share
-   at least one Room in common, and so their Home Servers are actively
+   at least one Room in common, and so their homeservers are actively
    exchanging message PDUs or transactions relating to that Room.
 
  * Presence update messages do not need realtime guarantees. It is acceptable to
@@ -25,7 +25,7 @@ promise to send them when required. Rather than actively polling for the
 current state all the time, HSes can rely on their relative stability to only
 push updates when required.
 
-A Home Server should not rely on the longterm validity of this presence
+A homeserver should not rely on the longterm validity of this presence
 information, however, as this would not cover such cases as a user's server
 crashing and thus failing to inform their peers that users it used to host are
 no longer available online. Therefore, each promise of future updates should
@@ -98,7 +98,7 @@ The data model presented here puts the following requirements on the APIs:
 Client-Server
 -------------
 
-Requests that a client can make to its Home Server
+Requests that a client can make to its homeserver
 
  * get/set current presence state
    Basic enumeration + ability to set a custom piece of text
@@ -128,7 +128,7 @@ Requests that a client can make to its Home Server
 Server-Server
 -------------
 
-Requests that Home Servers make to others
+Requests that homeservers make to others
 
  * request permission to add a user to presence list
 

drafts/model/profiles.rst

@@ -182,7 +182,7 @@ The data model presented here puts the following requirements on the APIs:
 Client-Server
 -------------
 
-Requests that a client can make to its Home Server
+Requests that a client can make to its homeserver
 
  * get/set my Display Name
    This should return/take a simple "text/plain" field
@@ -207,7 +207,7 @@ TODO(paul): At some later stage we should consider the API for:
 Server-Server
 -------------
 
-Requests that Home Servers make to others
+Requests that homeservers make to others
 
  * get a user's Display Name / Avatar
 
@@ -221,7 +221,7 @@ Requests that Home Servers make to others
 Room Event PDU Types
 --------------------
 
-Events that are pushed from Home Servers to other Home Servers or clients.
+Events that are pushed from homeservers to other homeservers or clients.
 
  * user Display Name change
  

drafts/model/rooms.rst

@@ -226,7 +226,7 @@ clients should display these in a special way too as the room name is not
 important; instead it should distinguish them on the Display Name of the other
 party.
 
-Home Servers will need a client-API option to request setting up a new user-user
+Homeservers will need a client-API option to request setting up a new user-user
 chat room, which will then need special handling within the server. It will
 create a new room with the following 
 
@@ -260,7 +260,7 @@ history with each other simultaneously create a room and invite the other to it.
 This is called a "glare" situation. There are two possible ideas for how to
 resolve this:
 
- * Each Home Server should persist the mapping of (user ID pair) to room ID, so
+ * Each homeserver should persist the mapping of (user ID pair) to room ID, so
    that duplicate requests can be suppressed. On receipt of a room creation
    request that the HS thinks there already exists a room for, the invitation to
    join can be rejected if:

drafts/model/third-party-id.rst

@@ -66,7 +66,7 @@ Privacy
 
 A User may publish the association between their phone number and Matrix User ID
 on the Identity Server without publishing the number in their Profile hosted on
-their Home Server.
+their homeserver.
 
 Identity Servers should refrain from publishing reverse mappings and should 
 take steps, such as rate limiting, to prevent attackers enumerating the space of

specification/application_service_api.rst

@@ -89,7 +89,7 @@ traffic to the AS is:
   identify the application service. The homeserver MUST enforce this.
 
 
-Home Server -> Application Service API
+Homeserver -> Application Service API
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Pushing events

specification/client_server_api.rst

@@ -168,7 +168,7 @@ more than one stage to implement n-factor auth. When all stages are complete,
 authentication is complete and the API call succeeds. To establish what flows a
 server supports for an endpoint, a client sends the request with no
 authentication. A request to an endpoint that uses User-Interactive
-Authentication never succeeds without auth. Home Servers may allow requests that
+Authentication never succeeds without auth. Homeservers may allow requests that
 don't require auth by offering a stage with only the ``m.login.dummy`` auth
 type. The homeserver returns a response with HTTP status 401 and a JSON object
 as follows::
@@ -450,7 +450,7 @@ Clients cannot be expected to be able to know how to process every single login
 type. If a client does not know how to handle a given login type, it can direct
 the user to a web browser with the URL of a fallback page which will allow the
 user to complete that login step out-of-band in their web browser. The URL it
-should open is the Home Server base URL plus prefix, plus::
+should open is the homeserver base URL plus prefix, plus::
 
   /auth/<stage type>/fallback/web?session=<session ID>
 
@@ -494,7 +494,7 @@ Request::
 
 This API endpoint uses the User-Interactive Authentication API. An access token
 should be submitted to this endpoint if the client has an active session. The
-Home Server may change the flows available depending on whether a valid access
+homeserver may change the flows available depending on whether a valid access
 token is provided.
 
 The body of the POST request is a JSON object containing:
@@ -505,7 +505,7 @@ new_password
 On success, an empty JSON object is returned.
 
 The error code M_NOT_FOUND is returned if the user authenticated with a third
-party identifier but the Home Server could not find a matching account in its
+party identifier but the homeserver could not find a matching account in its
 database.
 
 Adding Account Administrative Contact Information

specification/intro.rst

@@ -140,7 +140,7 @@ a long-lived GET request.
            |          V                                    |          V
        +------------------+                            +------------------+
        |                  |---------( HTTPS )--------->|                  |
-       |   Home Server    |                            |   Home Server    |
+       |   homeserver    |                            |   homeserver    |
        |                  |<--------( HTTPS )----------|                  |
        +------------------+      Server-Server API     +------------------+
                               History Synchronisation
@@ -227,7 +227,7 @@ They are case-sensitive. The following conceptual diagram shows an
                |                                                 |
                V                                                 |
        +------------------+                          +------------------+
-       |   Home Server    |                          |   Home Server    |
+       |   homeserver    |                          |   homeserver    |
        |   matrix.org     |                          |   domain.com     |
        +------------------+                          +------------------+
                |                                                 ^

specification/modules/push.rst

@@ -11,7 +11,7 @@ Push Notifications
                                    |                    |  |                   |
            +-------------------+   | +----------------+ |  | +---------------+ |
            |                   |   | |                | |  | |               | |
-           | Matrix Home Server+----->  Push Gateway  +------> Push Provider | |
+           | Matrix homeserver+----->  Push Gateway  +------> Push Provider | |
            |                   |   | |                | |  | |               | |
            +-^-----------------+   | +----------------+ |  | +----+----------+ |
              |                     |                    |  |      |            |

specification/server_server_api.rst

@@ -114,7 +114,7 @@ certificate currently in use by the server. These fingerprints are valid until
 the millisecond POSIX timestamp in ``valid_until_ts``.
 
 The ``verify_keys`` can be used to sign requests and events made by the server
-until the millisecond POSIX timestamp in ``valid_until_ts``. If a Home Server
+until the millisecond POSIX timestamp in ``valid_until_ts``. If a homeserver
 receives an event with a ``origin_server_ts`` after the ``valid_until_ts`` then
 it should request that ``key_id`` for the originating server to check whether
 the key has expired.