wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

RSTify; typos

Browse source
This commit is contained in:
Kegsay 2015-01-14 15:15:40 +00:00
parent b557e71121
commit 540b3a41ff
1 changed files with 129 additions and 132 deletions
Download patch file Download diff file Expand all files Collapse all files

25
drafts/application_services.rst
View file

@ -33,8 +33,7 @@ Example use cases for application services include:
* Exposing existing communication services in Matrix * Exposing existing communication services in Matrix
* Gateways to/from standards-based protocols (SIP, XMPP, IRC, RCS (MSRP), * Gateways to/from standards-based protocols (SIP, XMPP, IRC, RCS (MSRP), SIMPLE, Lync, etc)
SIMPLE, Lync, etc)
* Gateways to/from closed services (e.g. WhatsApp) * Gateways to/from closed services (e.g. WhatsApp)
* Gateways could be architected as: * Gateways could be architected as:
@ -47,18 +46,16 @@ Example use cases for application services include:
* Exposing a non-Matrix client interface listener from the AS * Exposing a non-Matrix client interface listener from the AS
(e.g. listen on port 6667 for IRC clients, or port 5222 for XMPP clients) (e.g. listen on port 6667 for IRC clients, or port 5222 for XMPP clients)
* Bridging existing APIs into Matrix
* Bridging existing APIs into Matrix
* e.g. SMS/MMS aggregator APIs * e.g. SMS/MMS aggregator APIs
* Domain-specific APIs such as SABRE * Domain-specific APIs such as SABRE
* Integrating more exotic content into Matrix * Integrating more exotic content into Matrix
* e.g. MIDI<->Matrix gateway/bridge * e.g. MIDI<->Matrix gateway/bridge
* 3D world <-> Matrix bridge * 3D world <-> Matrix bridge
* Application services: * Application services:
* Search engines (e.g. elasticsearch search indices) * Search engines (e.g. elasticsearch search indices)
* Notification systems (e.g. send custom pushes for various hooks) * Notification systems (e.g. send custom pushes for various hooks)
* VoIP Conference services * VoIP Conference services
@ -103,13 +100,13 @@ On HS handling events to unknown users:
confirms the existence of that user (from its perspective), then the HS confirms the existence of that user (from its perspective), then the HS
creates an account to represent the virtual user. creates an account to represent the virtual user.
* The namespace of virtual user accounts should conform to a structure like * The namespace of virtual user accounts should conform to a structure like
@.irc.freenode.Arathorn:matrix.org. This lets Matrix users communicate with ``@.irc.freenode.Arathorn:matrix.org``. This lets Matrix users communicate with
foreign users who are not yet mapped into Matrix via 3PID mappings or through foreign users who are not yet mapped into Matrix via 3PID mappings or through
an existing non-virtual Matrix user by trying to talk to them via a gateway. an existing non-virtual Matrix user by trying to talk to them via a gateway.
* The AS can alternatively preprovision virtual users using the existing CS API * The AS can alternatively preprovision virtual users using the existing CS API
rather than lazy-loading them in this manner. rather than lazy-loading them in this manner.
* The AS may want to link the matrix ID of the sender through to their 3PID in * The AS may want to link the matrix ID of the sender through to their 3PID in
the remote ecosystem. E.g. a message sent from @matthew:matrix.org may wish the remote ecosystem. E.g. a message sent from ``@matthew:matrix.org`` may wish
to originate from Arathorn on irc.freenode.net in the case of an IRC bridge. to originate from Arathorn on irc.freenode.net in the case of an IRC bridge.
It's left as an AS implementation detail as to how the user should authorise It's left as an AS implementation detail as to how the user should authorise
the AS to act on its behalf. the AS to act on its behalf.
@ -123,7 +120,7 @@ On HS handling events to unknown rooms:
* The initial state of the room may be populated by the AS by querying an * The initial state of the room may be populated by the AS by querying an
initialSync API (probably a subset of the CS initialSync API, to reuse the initialSync API (probably a subset of the CS initialSync API, to reuse the
same pattern for the equivalent function). As messages have to be signed same pattern for the equivalent function). As messages have to be signed
from the point of m.room.create, we will not be able to back-populate from the point of ``m.room.create``, we will not be able to back-populate
arbitrary history for rooms which are lazy-created in this manner, and instead arbitrary history for rooms which are lazy-created in this manner, and instead
have to chose the amount of history to be synchronised into the AS as a one-off. have to chose the amount of history to be synchronised into the AS as a one-off.
* If exposing arbitrary history is required, then: * If exposing arbitrary history is required, then:
@ -157,7 +154,7 @@ On HS handling events to existing users and rooms:
from Matrix, it should implement the federation API rather than the AS API from Matrix, it should implement the federation API rather than the AS API
instead. instead.
* HS->AS event pushes are retried for reliability with sequence numbers * HS->AS event pushes are retried for reliability with sequence numbers
(or logical timestamping?) to presereve the linearisation order and ensure (or logical timestamping?) to preserve the linearisation order and ensure
a reliable event stream. a reliable event stream.
* Clustered HSes must linearise just as they do for the CS API. Clustered * Clustered HSes must linearise just as they do for the CS API. Clustered
ASes must loadbalance the inbound stream across the cluster as required. ASes must loadbalance the inbound stream across the cluster as required.
@ -173,9 +170,9 @@ On AS relaying events from unknown-to-HS users:
explicitly specified, as it cannot be inferred from the access_token, which explicitly specified, as it cannot be inferred from the access_token, which
will be the same for all AS requests. will be the same for all AS requests.
* TODO: or do we maintain a separate access_token mapping? It seems like * TODO: or do we maintain a separate ``access_token`` mapping? It seems like
unnecessary overhead for the AS developer; easier to just use a single unnecessary overhead for the AS developer; easier to just use a single
privileged access_token and just track which userid is emitting events? privileged ``access_token`` and just track which ``user_id`` is emitting events?
* If the AS is spoofing the identity of a real (not virtual) matrix user, * If the AS is spoofing the identity of a real (not virtual) matrix user,
we should actually let them log themselves in via OAuth2 to give permission we should actually let them log themselves in via OAuth2 to give permission
to the AS to act on their behalf. to the AS to act on their behalf.
@ -192,7 +189,7 @@ On AS publishing aliases for virtual rooms:
* AS uses the normal alias management API to preemptively create/delete public * AS uses the normal alias management API to preemptively create/delete public
directory entries for aliases for virtual rooms provided by the AS. directory entries for aliases for virtual rooms provided by the AS.
* In order to create these aliases, the underlying room ID must also exist, so * In order to create these aliases, the underlying room ID must also exist, so
at least the m.room.create of that room must also be prepopulated. It seems at least the ``m.room.create`` of that room must also be prepopulated. It seems
sensible to prepopulate the required initial state and history of the room to sensible to prepopulate the required initial state and history of the room to
avoid a two-phase prepopulation process. avoid a two-phase prepopulation process.
@ -228,6 +225,6 @@ Extensions to CS API
* Ability to assert the identity of the virtual user for all methods. * Ability to assert the identity of the virtual user for all methods.
* Ability to massage timestamps when prepopulating historical state and * Ability to massage timestamps when prepopulating historical state and
messages of virtual rooms (either by overriding origin_server_ts (preferred) or messages of virtual rooms (either by overriding ``origin_server_ts`` (preferred) or
adding an as_ts which we expect clients to honour) adding an ``as_ts`` which we expect clients to honour)
* Ability to delete aliases (including from the directory) as well as create them. * Ability to delete aliases (including from the directory) as well as create them.