archive
/
matrix-spec
mirror of https://github.com/matrix-org/matrix-spec
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Consistently spell homeserver as homeserver

Browse Source
pull/977/head
Daniel Wagner-Hall 9 years ago
parent 138c8f88be
commit 2f3a00fe34
39 changed files with 235 additions and 235 deletions
Show Stats Download Patch File Download Diff File

4
api/client-server/administrative_contact.yaml
Unescape Escape View File

@ -25,7 +25,7 @@ paths:
This API endpoint uses the User-Interactive Authentication API. This API endpoint uses the User-Interactive Authentication API.
An access token should be submitted to this endpoint if the client has An access token should be submitted to this endpoint if the client has
an active session. 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. valid access token is provided.
security: security:
- accessToken: [] - accessToken: []
@ -64,7 +64,7 @@ paths:
This is *not* the same as the list of third party identifiers bound to This is *not* the same as the list of third party identifiers bound to
the user's Matrix ID in Identity Servers. 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. identifiers that it will accept to reset the user's account password.
security: security:
- accessToken: [] - accessToken: []

2
api/client-server/login.yaml
Unescape Escape View File

@ -81,7 +81,7 @@ paths:
(optional) A ``refresh_token`` may be exchanged for a new ``access_token`` using the /tokenrefresh API endpoint. (optional) A ``refresh_token`` may be exchanged for a new ``access_token`` using the /tokenrefresh API endpoint.
home_server: home_server:
type: string 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: 400:
description: |- description: |-
Part of the request was invalid. For example, the login type may not be recognised. Part of the request was invalid. For example, the login type may not be recognised.

2
api/client-server/pusher.yaml
Unescape Escape View File

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

4
api/client-server/registration.yaml
Unescape Escape View File

@ -94,7 +94,7 @@ paths:
(optional) A ``refresh_token`` may be exchanged for a new ``access_token`` using the /tokenrefresh API endpoint. (optional) A ``refresh_token`` may be exchanged for a new ``access_token`` using the /tokenrefresh API endpoint.
home_server: home_server:
type: string 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: 400:
description: |- description: |-
Part of the request was invalid. This may include one of the following error codes: 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 including after authentication if the requested user ID was registered
whilst the client was performing authentication. 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 performing `User-Interactive Authentication`_, although they may also return
them after authentication is completed if, for example, the requested user ID them after authentication is completed if, for example, the requested user ID
was registered whilst the client was performing authentication. was registered whilst the client was performing authentication.

2
drafts/ancient_federated_versioning_design_notes.rst
Unescape Escape View File

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

4
drafts/as-http-api.rst
Unescape Escape View File

@ -13,7 +13,7 @@ Application Services HTTP API
.. sectnum:: .. sectnum::
Application Service -> Home Server Application Service -> Homeserver
---------------------------------- ----------------------------------
This contains homeserver APIs which are used by the application service. 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. This contains application service APIs which are used by the homeserver.

10
drafts/model/presence.rst
Unescape Escape View File

@ -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 amount of Internet traffic relating to presence updates. In order to minimise
the impact of such a feature, the following observations can be made: 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. 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 * 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. 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 * 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. exchanging message PDUs or transactions relating to that Room.
* Presence update messages do not need realtime guarantees. It is acceptable to * 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 current state all the time, HSes can rely on their relative stability to only
push updates when required. 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 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 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 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 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 * get/set current presence state
Basic enumeration + ability to set a custom piece of text 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 Server-Server
------------- -------------
Requests that Home Servers make to others Requests that homeservers make to others
* request permission to add a user to presence list * request permission to add a user to presence list

6
drafts/model/profiles.rst
Unescape Escape View File

@ -182,7 +182,7 @@ The data model presented here puts the following requirements on the APIs:
Client-Server 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 * get/set my Display Name
This should return/take a simple "text/plain" field 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 Server-Server
------------- -------------
Requests that Home Servers make to others Requests that homeservers make to others
* get a user's Display Name / Avatar * get a user's Display Name / Avatar
@ -221,7 +221,7 @@ Requests that Home Servers make to others
Room Event PDU Types 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 * user Display Name change

4
drafts/model/rooms.rst
Unescape Escape View File

@ -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 important; instead it should distinguish them on the Display Name of the other
party. 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 chat room, which will then need special handling within the server. It will
create a new room with the following 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 This is called a "glare" situation. There are two possible ideas for how to
resolve this: 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 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 request that the HS thinks there already exists a room for, the invitation to
join can be rejected if: join can be rejected if:

2
drafts/model/third-party-id.rst
Unescape Escape View File

@ -66,7 +66,7 @@ Privacy
A User may publish the association between their phone number and Matrix User ID 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 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 Identity Servers should refrain from publishing reverse mappings and should
take steps, such as rate limiting, to prevent attackers enumerating the space of take steps, such as rate limiting, to prevent attackers enumerating the space of

2
specification/application_service_api.rst
Unescape Escape View File

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

8
specification/client_server_api.rst
Unescape Escape View File

@ -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 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 server supports for an endpoint, a client sends the request with no
authentication. A request to an endpoint that uses User-Interactive 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 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 type. The homeserver returns a response with HTTP status 401 and a JSON object
as follows:: 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 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 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 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> /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 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 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. token is provided.
The body of the POST request is a JSON object containing: 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. On success, an empty JSON object is returned.
The error code M_NOT_FOUND is returned if the user authenticated with a third 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. database.
Adding Account Administrative Contact Information Adding Account Administrative Contact Information

4
specification/intro.rst
Unescape Escape View File

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

2
specification/modules/push.rst
Unescape Escape View File

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

2
specification/server_server_api.rst
Unescape Escape View File

@ -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 millisecond POSIX timestamp in ``valid_until_ts``.
The ``verify_keys`` can be used to sign requests and events made by the server 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 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 it should request that ``key_id`` for the originating server to check whether
the key has expired. the key has expired.

Write Preview
Loading…
Cancel
Save