From 9243f0c5e3ead3ed8d58d86698f7999466417595 Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Fri, 5 Sep 2014 17:42:54 +0100 Subject: [PATCH 001/106] Add docs on how to sign json --- docs/server-server/signing.rst | 103 +++++++++++++++++++++++++++++++++ 1 file changed, 103 insertions(+) create mode 100644 docs/server-server/signing.rst diff --git a/docs/server-server/signing.rst b/docs/server-server/signing.rst new file mode 100644 index 0000000000..35a4224f56 --- /dev/null +++ b/docs/server-server/signing.rst @@ -0,0 +1,103 @@ +Signing JSON +============ + +JSON is signed by encoding the JSON object without ``signatures`` or ``meta`` +keys using a canonical encoding. The JSON bytes are then signed using the +signature algorithm and the signature encoded using base64 with the padding +striped. The resulting base64 signature is added to an object under the +*signing key identifier* which is added to the ``signatures`` object under the +name of the server signing it which is added back to the original JSON object +along with the ``meta`` object. + +The *signing key identifier* is the concatenation of the *signing algorithm* +and a *key version*. The *signing algorithm* identifies the algorithm used to +sign the JSON. The currently support value for *signing algorithm* is +``ed25519`` as implemented by NACL (http://nacl.cr.yp.to/). The *key version* +is used to distinguish between different signing keys used by the same entity. + +The ``meta`` object and the ``signatures`` object are not covered by the +signature. Therefore intermediate servers can add metadata such as time stamps +and additional signatures. + + +:: + + { + "name": "example.org", + "signing_keys": { + "ed25519:1": "XSl0kuyvrXNj6A+7/tkrB9sxSbRi08Of5uRhxOqZtEQ" + }, + "meta": { + "retrieved_ts_ms": 922834800000 + }, + "signatures": { + "example.org": { + "ed25519:1": "s76RUgajp8w172am0zQb/iPTHsRnb4SkrzGoeCOSFfcBY2V/1c8QfrmdXHpvnc2jK5BD1WiJIxiMW95fMjK7Bw" + } + } + } + +:: + + def sign_json(value, signing_key, signing_name): + signatures = value.pop("signatures", {}) + signatures_for_name = signatures.pop(signing_name, {}) + meta = value.pop("meta", None) + signature = signing_key.sign(canonical_json(value)) + key_identifier = "%s:%s" % (signing_key.algorithm, signing_key.version) + signatures_for_name[key_identifier] = encode_base64(signature.signature) + signatures[signing_name] = signatures_for_name + value["signatures"] = signatures + if meta is not None: + value["meta"] = meta + return value + +Canonical JSON +-------------- + +The canonical JSON encoding for a value is the shortest UTF-8 JSON encoding +with dictionary keys lexicographically sorted by unicode codepoint. Numbers in +the JSON value must be integers in the range [-(2**53)+1, (2**53)-1]. + +:: + + import json + + def canonical_json(value): + return json.dumps( + value, + ensure_ascii=False, + separators=(',',':'), + sort_keys=True, + ).encode("UTF-8") + +Grammar ++++++++ + +Adapted from the grammar in http://tools.ietf.org/html/rfc7159 removing +insignificant whitespace, fractions, exponents and redundant character escapes + +:: + + value = false / null / true / object / array / number / string + false = %x66.61.6c.73.65 + null = %x6e.75.6c.6c + true = %x74.72.75.65 + object = %x7B [ member *( %x2C member ) ] %7D + member = string %x3A value + array = %x5B [ value *( %x2C value ) ] %5B + number = [ %x2D ] int + int = %x30 / ( %x31-39 *digit ) + digit = %x30-39 + string = %x22 *char %x22 + char = unescaped / %x5C escaped + unescaped = %x20-21 / %x23-5B / %x5D-10FFFF + escaped = %x22 ; " quotation mark U+0022 + / %x5C ; \ reverse solidus U+005C + / %x62 ; b backspace U+0008 + / %x66 ; f form feed U+000C + / %x6E ; n line feed U+000A + / %x72 ; r carriage return U+000D + / %x74 ; t tab U+0009 + / %x75.30.30.30 (%x30-37 / %x62 / %x65-66) ; u000X + / %x75.30.30.31 (%x30-39 / %x61-66) ; u001X From e0fa4cf8743f80264995de502c0d4e98a5500a2b Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Fri, 5 Sep 2014 18:22:24 +0100 Subject: [PATCH 002/106] Spelling --- docs/server-server/signing.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/server-server/signing.rst b/docs/server-server/signing.rst index 35a4224f56..bf85443dfa 100644 --- a/docs/server-server/signing.rst +++ b/docs/server-server/signing.rst @@ -4,7 +4,7 @@ Signing JSON JSON is signed by encoding the JSON object without ``signatures`` or ``meta`` keys using a canonical encoding. The JSON bytes are then signed using the signature algorithm and the signature encoded using base64 with the padding -striped. The resulting base64 signature is added to an object under the +stripped. The resulting base64 signature is added to an object under the *signing key identifier* which is added to the ``signatures`` object under the name of the server signing it which is added back to the original JSON object along with the ``meta`` object. From fceb5f7b22c6255515abafc69924c6f9ec38d993 Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Thu, 18 Sep 2014 18:14:53 +0100 Subject: [PATCH 003/106] SYN-39: Add documentation explaining how to check a signature --- docs/server-server/signing.rst | 44 +++++++++++++++++++++++++--------- 1 file changed, 33 insertions(+), 11 deletions(-) diff --git a/docs/server-server/signing.rst b/docs/server-server/signing.rst index bf85443dfa..bcb89a79a0 100644 --- a/docs/server-server/signing.rst +++ b/docs/server-server/signing.rst @@ -39,18 +39,40 @@ and additional signatures. :: - def sign_json(value, signing_key, signing_name): - signatures = value.pop("signatures", {}) - signatures_for_name = signatures.pop(signing_name, {}) - meta = value.pop("meta", None) - signature = signing_key.sign(canonical_json(value)) - key_identifier = "%s:%s" % (signing_key.algorithm, signing_key.version) - signatures_for_name[key_identifier] = encode_base64(signature.signature) - signatures[signing_name] = signatures_for_name - value["signatures"] = signatures + def sign_json(json_object, signing_key, signing_name): + signatures = json_object.pop("signatures", {}) + meta = json_object.pop("meta", None) + + signed = signing_key.sign(encode_canonical_json(json_object)) + signature_base64 = encode_base64(signed.signature) + + key_id = "%s:%s" % (signing_key.alg, signing_key.version) + signatures.setdefault(sigature_name, {})[key_id] = signature_base64 + + json_object["signatures"] = signatures if meta is not None: - value["meta"] = meta - return value + json_object["meta"] = meta + + return json_object + +Checking for a Signature +------------------------ + +To check if an entity has signed a JSON object a server does the following + +1. Checks if the ``signatures`` object contains an entry with the name of the + entity. If the entry is missing then the check fails. +2. Removes any *signing key identifiers* from the entry with algrothims it + doesn't understand. If there are no *signing key identifiers* left then the + check fails. +3. Looks up *verification keys* for the remaining *signing key identifiers* + either from a local cache or by consulting a trusted key server. If it + cannot find a *verification key* then the check fails. +4. Decodes the base64 encoded signature bytes. If base64 decoding fails then + the check fails. +5. Checks the signature bytes using the *verification key*. If this fails then + the check fails. Otherwise the check succeeds. + Canonical JSON -------------- From 107e7d5d91feab203dbbe22527f0b4f027199775 Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Mon, 22 Sep 2014 19:42:07 +0100 Subject: [PATCH 004/106] Add section to explain how to sign events such that we can redact message contents --- docs/server-server/signing.rst | 28 +++++++++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/docs/server-server/signing.rst b/docs/server-server/signing.rst index bcb89a79a0..2489f36b0a 100644 --- a/docs/server-server/signing.rst +++ b/docs/server-server/signing.rst @@ -73,7 +73,6 @@ To check if an entity has signed a JSON object a server does the following 5. Checks the signature bytes using the *verification key*. If this fails then the check fails. Otherwise the check succeeds. - Canonical JSON -------------- @@ -123,3 +122,30 @@ insignificant whitespace, fractions, exponents and redundant character escapes / %x74 ; t tab U+0009 / %x75.30.30.30 (%x30-37 / %x62 / %x65-66) ; u000X / %x75.30.30.31 (%x30-39 / %x61-66) ; u001X + +Signing Events +============== + +Signing events is a more complicated process since servers can choose to redact +non-essential event contents. Before signing the event it is encoded as +Canonical JSON and hashed using SHA-256. The resulting hash is then stored +in the event JSON in a ``hash`` object under a ``sha256`` key. Then all +non-essential keys are striped from the event object and the resulting object +which included the ``hash`` key is signed using the JSON signing algorithm. + +Servers can then transmit the entire event or the event with the non-essential +keys removed. Recieving servers can then check the entire event if it is +present by computing the SHA-256 of the event excluding the ``hash`` object or +by using the ``hash`` object including in the event if keys have been redacted. + +New hash functions can be introduced by adding additional keys to the ``hash`` +object. Since the ``hash`` object cannot be redacted a server shouldn't allow +too many hashes to be listed, otherwise a server might embed illict data within +the ``hash`` object. For similar reasons a server shouldn't allow hash values +that are too long. + +[[TODO(markjh): We might want to specify a maximum number of keys for the +``hash`` and we might want to specify the maximum output size of a hash]] + +[[TODO(markjh) We might want to allow the server to omit the output of well +known hash functions like SHA-256 when none of the keys have been redacted]] From 6876b1a25b140076fa58e889ffbd7283f81fcf2d Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Mon, 22 Sep 2014 21:45:50 +0100 Subject: [PATCH 005/106] fix grammatics --- docs/server-server/signing.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/server-server/signing.rst b/docs/server-server/signing.rst index 2489f36b0a..a592f48c35 100644 --- a/docs/server-server/signing.rst +++ b/docs/server-server/signing.rst @@ -130,13 +130,13 @@ Signing events is a more complicated process since servers can choose to redact non-essential event contents. Before signing the event it is encoded as Canonical JSON and hashed using SHA-256. The resulting hash is then stored in the event JSON in a ``hash`` object under a ``sha256`` key. Then all -non-essential keys are striped from the event object and the resulting object +non-essential keys are stripped from the event object, and the resulting object which included the ``hash`` key is signed using the JSON signing algorithm. Servers can then transmit the entire event or the event with the non-essential -keys removed. Recieving servers can then check the entire event if it is -present by computing the SHA-256 of the event excluding the ``hash`` object or -by using the ``hash`` object including in the event if keys have been redacted. +keys removed. Receiving servers can then check the entire event if it is +present by computing the SHA-256 of the event excluding the ``hash`` object, or +by using the ``hash`` object included in the event if keys have been redacted. New hash functions can be introduced by adding additional keys to the ``hash`` object. Since the ``hash`` object cannot be redacted a server shouldn't allow From c6a8e7d9b96b1a5302a82cc29ca57a97ce74b652 Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Tue, 23 Sep 2014 16:18:21 +0100 Subject: [PATCH 006/106] Read signing keys using methods from syutil. convert keys that are in the wrong format --- synapse/config/server.py | 39 ++++++++++++++++++++++++++++++--------- 1 file changed, 30 insertions(+), 9 deletions(-) diff --git a/synapse/config/server.py b/synapse/config/server.py index 516e4cf882..d9d8d0e14e 100644 --- a/synapse/config/server.py +++ b/synapse/config/server.py @@ -13,10 +13,9 @@ # See the License for the specific language governing permissions and # limitations under the License. -import nacl.signing import os -from ._base import Config -from syutil.base64util import encode_base64, decode_base64 +from ._base import Config, ConfigError +import syutil.crypto.signing_key class ServerConfig(Config): @@ -70,9 +69,16 @@ class ServerConfig(Config): "content repository") def read_signing_key(self, signing_key_path): - signing_key_base64 = self.read_file(signing_key_path, "signing_key") - signing_key_bytes = decode_base64(signing_key_base64) - return nacl.signing.SigningKey(signing_key_bytes) + signing_keys = self.read_file(signing_key_path, "signing_key") + try: + return syutil.crypto.signing_key.read_signing_keys( + signing_keys.splitlines(True) + ) + except Exception as e: + raise ConfigError( + "Error reading signing_key." + " Try running again with --generate-config" + ) @classmethod def generate_config(cls, args, config_dir_path): @@ -86,6 +92,21 @@ class ServerConfig(Config): if not os.path.exists(args.signing_key_path): with open(args.signing_key_path, "w") as signing_key_file: - key = nacl.signing.SigningKey.generate() - signing_key_file.write(encode_base64(key.encode())) - + syutil.crypto.signing_key.write_signing_keys( + signing_key_file, + (syutil.crypto.SigningKey.generate("auto"),), + ) + else: + signing_keys = cls.read_file(args.signing_key_path, "signing_key") + if len(signing_keys.split("\n")[0].split()) == 1: + # handle keys in the old format. + key = syutil.crypto.signing_key.decode_signing_key_base64( + syutil.crypto.signing_key.NACL_ED25519, + "auto", + signing_keys.split("\n")[0] + ) + with open(args.signing_key_path, "w") as signing_key_file: + syutil.crypto.signing_key.write_signing_keys( + signing_key_file, + (key,), + ) From e3117a2a236220f89eb73f0355d00b3b3e83ce35 Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Tue, 23 Sep 2014 18:40:59 +0100 Subject: [PATCH 007/106] Add a _matrix/key/v1 resource with the verification keys of the local server --- synapse/api/urls.py | 3 +- synapse/app/homeserver.py | 10 +- synapse/crypto/resource/key.py | 161 ---------------------------- synapse/http/server_key_resource.py | 93 ++++++++++++++++ synapse/server.py | 1 + 5 files changed, 104 insertions(+), 164 deletions(-) delete mode 100644 synapse/crypto/resource/key.py create mode 100644 synapse/http/server_key_resource.py diff --git a/synapse/api/urls.py b/synapse/api/urls.py index 6314f31f7a..6dc19305b7 100644 --- a/synapse/api/urls.py +++ b/synapse/api/urls.py @@ -18,4 +18,5 @@ CLIENT_PREFIX = "/_matrix/client/api/v1" FEDERATION_PREFIX = "/_matrix/federation/v1" WEB_CLIENT_PREFIX = "/_matrix/client" -CONTENT_REPO_PREFIX = "/_matrix/content" \ No newline at end of file +CONTENT_REPO_PREFIX = "/_matrix/content" +SERVER_KEY_PREFIX = "/_matrix/key/v1" diff --git a/synapse/app/homeserver.py b/synapse/app/homeserver.py index 2f1b954902..a77f137b4e 100755 --- a/synapse/app/homeserver.py +++ b/synapse/app/homeserver.py @@ -26,8 +26,10 @@ from twisted.web.server import Site from synapse.http.server import JsonResource, RootRedirect from synapse.http.content_repository import ContentRepoResource from synapse.http.client import TwistedHttpClient +from synapse.http.server_key_resource import LocalKey from synapse.api.urls import ( - CLIENT_PREFIX, FEDERATION_PREFIX, WEB_CLIENT_PREFIX, CONTENT_REPO_PREFIX + CLIENT_PREFIX, FEDERATION_PREFIX, WEB_CLIENT_PREFIX, CONTENT_REPO_PREFIX, + SERVER_KEY_PREFIX, ) from synapse.config.homeserver import HomeServerConfig from synapse.crypto import context_factory @@ -63,6 +65,9 @@ class SynapseHomeServer(HomeServer): self, self.upload_dir, self.auth, self.content_addr ) + def build_resource_for_server_key(self): + return LocalKey(self) + def build_db_pool(self): return adbapi.ConnectionPool( "sqlite3", self.get_db_name(), @@ -88,7 +93,8 @@ class SynapseHomeServer(HomeServer): desired_tree = [ (CLIENT_PREFIX, self.get_resource_for_client()), (FEDERATION_PREFIX, self.get_resource_for_federation()), - (CONTENT_REPO_PREFIX, self.get_resource_for_content_repo()) + (CONTENT_REPO_PREFIX, self.get_resource_for_content_repo()), + (SERVER_KEY_PREFIX, self.get_resource_for_server_key()), ] if web_client: logger.info("Adding the web client.") diff --git a/synapse/crypto/resource/key.py b/synapse/crypto/resource/key.py deleted file mode 100644 index 48d14b9f4a..0000000000 --- a/synapse/crypto/resource/key.py +++ /dev/null @@ -1,161 +0,0 @@ -# -*- coding: utf-8 -*- -# Copyright 2014 OpenMarket Ltd -# -# Licensed under the Apache License, Version 2.0 (the "License"); -# you may not use this file except in compliance with the License. -# You may obtain a copy of the License at -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, -# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -# See the License for the specific language governing permissions and -# limitations under the License. - - -from twisted.web.resource import Resource -from twisted.web.server import NOT_DONE_YET -from twisted.internet import defer -from synapse.http.server import respond_with_json_bytes -from synapse.crypto.keyclient import fetch_server_key -from syutil.crypto.jsonsign import sign_json, verify_signed_json -from syutil.base64util import encode_base64, decode_base64 -from syutil.jsonutil import encode_canonical_json -from OpenSSL import crypto -from nacl.signing import VerifyKey -import logging - - -logger = logging.getLogger(__name__) - - -class LocalKey(Resource): - """HTTP resource containing encoding the TLS X.509 certificate and NACL - signature verification keys for this server:: - - GET /key HTTP/1.1 - - HTTP/1.1 200 OK - Content-Type: application/json - { - "server_name": "this.server.example.com" - "signature_verify_key": # base64 encoded NACL verification key. - "tls_certificate": # base64 ASN.1 DER encoded X.509 tls cert. - "signatures": { - "this.server.example.com": # NACL signature for this server. - } - } - """ - - def __init__(self, key_server): - self.key_server = key_server - self.response_body = encode_canonical_json( - self.response_json_object(key_server) - ) - Resource.__init__(self) - - @staticmethod - def response_json_object(key_server): - verify_key_bytes = key_server.signing_key.verify_key.encode() - x509_certificate_bytes = crypto.dump_certificate( - crypto.FILETYPE_ASN1, - key_server.tls_certificate - ) - json_object = { - u"server_name": key_server.server_name, - u"signature_verify_key": encode_base64(verify_key_bytes), - u"tls_certificate": encode_base64(x509_certificate_bytes) - } - signed_json = sign_json( - json_object, - key_server.server_name, - key_server.signing_key - ) - return signed_json - - def getChild(self, name, request): - logger.info("getChild %s %s", name, request) - if name == '': - return self - else: - return RemoteKey(name, self.key_server) - - def render_GET(self, request): - return respond_with_json_bytes(request, 200, self.response_body) - - -class RemoteKey(Resource): - """HTTP resource for retreiving the TLS certificate and NACL signature - verification keys for a another server. Checks that the reported X.509 TLS - certificate matches the one used in the HTTPS connection. Checks that the - NACL signature for the remote server is valid. Returns JSON signed by both - the remote server and by this server. - - GET /key/remote.server.example.com HTTP/1.1 - - HTTP/1.1 200 OK - Content-Type: application/json - { - "server_name": "remote.server.example.com" - "signature_verify_key": # base64 encoded NACL verification key. - "tls_certificate": # base64 ASN.1 DER encoded X.509 tls cert. - "signatures": { - "remote.server.example.com": # NACL signature for remote server. - "this.server.example.com": # NACL signature for this server. - } - } - """ - - isLeaf = True - - def __init__(self, server_name, key_server): - self.server_name = server_name - self.key_server = key_server - Resource.__init__(self) - - def render_GET(self, request): - self._async_render_GET(request) - return NOT_DONE_YET - - @defer.inlineCallbacks - def _async_render_GET(self, request): - try: - server_keys, certificate = yield fetch_server_key( - self.server_name, - self.key_server.ssl_context_factory - ) - - resp_server_name = server_keys[u"server_name"] - verify_key_b64 = server_keys[u"signature_verify_key"] - tls_certificate_b64 = server_keys[u"tls_certificate"] - verify_key = VerifyKey(decode_base64(verify_key_b64)) - - if resp_server_name != self.server_name: - raise ValueError("Wrong server name '%s' != '%s'" % - (resp_server_name, self.server_name)) - - x509_certificate_bytes = crypto.dump_certificate( - crypto.FILETYPE_ASN1, - certificate - ) - - if encode_base64(x509_certificate_bytes) != tls_certificate_b64: - raise ValueError("TLS certificate doesn't match") - - verify_signed_json(server_keys, self.server_name, verify_key) - - signed_json = sign_json( - server_keys, - self.key_server.server_name, - self.key_server.signing_key - ) - - json_bytes = encode_canonical_json(signed_json) - respond_with_json_bytes(request, 200, json_bytes) - - except Exception as e: - json_bytes = encode_canonical_json({ - u"error": {u"code": 502, u"message": e.message} - }) - respond_with_json_bytes(request, 502, json_bytes) diff --git a/synapse/http/server_key_resource.py b/synapse/http/server_key_resource.py new file mode 100644 index 0000000000..8022f9a5ae --- /dev/null +++ b/synapse/http/server_key_resource.py @@ -0,0 +1,93 @@ +# -*- coding: utf-8 -*- +# Copyright 2014 OpenMarket Ltd +# +# Licensed under the Apache License, Version 2.0 (the "License"); +# you may not use this file except in compliance with the License. +# You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. + + +from twisted.web.resource import Resource +from twisted.web.server import NOT_DONE_YET +from twisted.internet import defer +from synapse.http.server import respond_with_json_bytes +from synapse.crypto.keyclient import fetch_server_key +from syutil.crypto.jsonsign import sign_json +from syutil.base64util import encode_base64, decode_base64 +from syutil.jsonutil import encode_canonical_json +from OpenSSL import crypto +from nacl.signing import VerifyKey +import logging + + +logger = logging.getLogger(__name__) + + +class LocalKey(Resource): + """HTTP resource containing encoding the TLS X.509 certificate and NACL + signature verification keys for this server:: + + GET /key HTTP/1.1 + + HTTP/1.1 200 OK + Content-Type: application/json + { + "server_name": "this.server.example.com" + "verify_keys": { + "algorithm:version": # base64 encoded NACL verification key. + }, + "tls_certificate": # base64 ASN.1 DER encoded X.509 tls cert. + "signatures": { + "this.server.example.com": { + "algorithm:version": # NACL signature for this server. + } + } + } + """ + + def __init__(self, hs): + self.hs = hs + self.response_body = encode_canonical_json( + self.response_json_object(hs.config) + ) + Resource.__init__(self) + + @staticmethod + def response_json_object(server_config): + verify_keys = {} + for key in server_config.signing_key: + verify_key_bytes = key.verify_key.encode() + key_id = "%s:%s" % (key.alg, key.version) + verify_keys[key_id] = encode_base64(verify_key_bytes) + + x509_certificate_bytes = crypto.dump_certificate( + crypto.FILETYPE_ASN1, + server_config.tls_certificate + ) + json_object = { + u"server_name": server_config.server_name, + u"verify_keys": verify_keys, + u"tls_certificate": encode_base64(x509_certificate_bytes) + } + for key in server_config.signing_key: + json_object = sign_json( + json_object, + server_config.server_name, + key, + ) + + return json_object + + def render_GET(self, request): + return respond_with_json_bytes(request, 200, self.response_body) + + def getChild(self, name, request): + if name == '': + return self diff --git a/synapse/server.py b/synapse/server.py index cdea49e6ab..529500d595 100644 --- a/synapse/server.py +++ b/synapse/server.py @@ -75,6 +75,7 @@ class BaseHomeServer(object): 'resource_for_federation', 'resource_for_web_client', 'resource_for_content_repo', + 'resource_for_server_key', 'event_sources', 'ratelimiter', ] From bf4b224fcfe4870b056a6fa903170f5e0bf77869 Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Tue, 23 Sep 2014 18:43:18 +0100 Subject: [PATCH 008/106] Fix a few pyflakes errors in the server_key_resource --- synapse/http/server_key_resource.py | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/synapse/http/server_key_resource.py b/synapse/http/server_key_resource.py index 8022f9a5ae..b30ecead27 100644 --- a/synapse/http/server_key_resource.py +++ b/synapse/http/server_key_resource.py @@ -15,15 +15,11 @@ from twisted.web.resource import Resource -from twisted.web.server import NOT_DONE_YET -from twisted.internet import defer from synapse.http.server import respond_with_json_bytes -from synapse.crypto.keyclient import fetch_server_key from syutil.crypto.jsonsign import sign_json -from syutil.base64util import encode_base64, decode_base64 +from syutil.base64util import encode_base64 from syutil.jsonutil import encode_canonical_json from OpenSSL import crypto -from nacl.signing import VerifyKey import logging From 52ca8676700368098ca0689c424f972ac54ac780 Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Wed, 24 Sep 2014 17:25:41 +0100 Subject: [PATCH 009/106] Sign federation transactions --- synapse/federation/replication.py | 9 ++++++++- tests/federation/test_federation.py | 5 ++++- tests/handlers/test_federation.py | 7 ++++++- tests/handlers/test_presence.py | 21 +++++++++++++++++++-- tests/handlers/test_room.py | 5 ++++- tests/handlers/test_typing.py | 6 +++++- tests/rest/test_presence.py | 15 ++++++++++++--- tests/utils.py | 15 +++++++++++++++ 8 files changed, 73 insertions(+), 10 deletions(-) diff --git a/synapse/federation/replication.py b/synapse/federation/replication.py index 96b82f00cb..84977e7e57 100644 --- a/synapse/federation/replication.py +++ b/synapse/federation/replication.py @@ -25,6 +25,8 @@ from .persistence import PduActions, TransactionActions from synapse.util.logutils import log_function +from syutil.crypto.jsonsign import sign_json + import logging @@ -489,7 +491,7 @@ class _TransactionQueue(object): """ def __init__(self, hs, transaction_actions, transport_layer): - + self.signing_key = hs.config.signing_key[0] self.server_name = hs.hostname self.transaction_actions = transaction_actions self.transport_layer = transport_layer @@ -604,6 +606,9 @@ class _TransactionQueue(object): # Actually send the transaction + server_name = self.server_name + signing_key = self.signing_key + # FIXME (erikj): This is a bit of a hack to make the Pdu age # keys work def cb(transaction): @@ -613,6 +618,8 @@ class _TransactionQueue(object): if "age_ts" in p: p["age"] = now - int(p["age_ts"]) + transaction = sign_json(transaction, server_name, signing_key) + return transaction code, response = yield self.transport_layer.send_transaction( diff --git a/tests/federation/test_federation.py b/tests/federation/test_federation.py index bb17e9aafe..eafc7879e0 100644 --- a/tests/federation/test_federation.py +++ b/tests/federation/test_federation.py @@ -19,7 +19,7 @@ from tests import unittest # python imports from mock import Mock, ANY -from ..utils import MockHttpResource, MockClock +from ..utils import MockHttpResource, MockClock, MockKey from synapse.server import HomeServer from synapse.federation import initialize_http_replication @@ -64,6 +64,8 @@ class FederationTestCase(unittest.TestCase): self.mock_persistence.get_received_txn_response.return_value = ( defer.succeed(None) ) + self.mock_config = Mock() + self.mock_config.signing_key = [MockKey()] self.clock = MockClock() hs = HomeServer("test", resource_for_federation=self.mock_resource, @@ -71,6 +73,7 @@ class FederationTestCase(unittest.TestCase): db_pool=None, datastore=self.mock_persistence, clock=self.clock, + config=self.mock_config, ) self.federation = initialize_http_replication(hs) self.distributor = hs.get_distributor() diff --git a/tests/handlers/test_federation.py b/tests/handlers/test_federation.py index eb6b7c22ef..5c69997273 100644 --- a/tests/handlers/test_federation.py +++ b/tests/handlers/test_federation.py @@ -26,12 +26,16 @@ from synapse.federation.units import Pdu from mock import NonCallableMock, ANY -from ..utils import get_mock_call_args +from ..utils import get_mock_call_args, MockKey class FederationTestCase(unittest.TestCase): def setUp(self): + + self.mock_config = NonCallableMock() + self.mock_config.signing_key = [MockKey()] + self.hostname = "test" hs = HomeServer( self.hostname, @@ -48,6 +52,7 @@ class FederationTestCase(unittest.TestCase): "room_member_handler", "federation_handler", ]), + config=self.mock_config, ) self.datastore = hs.get_datastore() diff --git a/tests/handlers/test_presence.py b/tests/handlers/test_presence.py index 765929d204..fe4b892ffb 100644 --- a/tests/handlers/test_presence.py +++ b/tests/handlers/test_presence.py @@ -17,11 +17,12 @@ from tests import unittest from twisted.internet import defer, reactor -from mock import Mock, call, ANY +from mock import Mock, call, ANY, NonCallableMock import json from tests.utils import ( - MockHttpResource, MockClock, DeferredMockCallable, SQLiteMemoryDbPool + MockHttpResource, MockClock, DeferredMockCallable, SQLiteMemoryDbPool, + MockKey ) from synapse.server import HomeServer @@ -67,12 +68,16 @@ class PresenceStateTestCase(unittest.TestCase): db_pool = SQLiteMemoryDbPool() yield db_pool.prepare() + self.mock_config = NonCallableMock() + self.mock_config.signing_key = [MockKey()] + hs = HomeServer("test", clock=MockClock(), db_pool=db_pool, handlers=None, resource_for_federation=Mock(), http_client=None, + config=self.mock_config, ) hs.handlers = JustPresenceHandlers(hs) @@ -214,6 +219,9 @@ class PresenceInvitesTestCase(unittest.TestCase): db_pool = SQLiteMemoryDbPool() yield db_pool.prepare() + self.mock_config = NonCallableMock() + self.mock_config.signing_key = [MockKey()] + hs = HomeServer("test", clock=MockClock(), db_pool=db_pool, @@ -221,6 +229,7 @@ class PresenceInvitesTestCase(unittest.TestCase): resource_for_client=Mock(), resource_for_federation=self.mock_federation_resource, http_client=self.mock_http_client, + config=self.mock_config, ) hs.handlers = JustPresenceHandlers(hs) @@ -503,6 +512,9 @@ class PresencePushTestCase(unittest.TestCase): self.mock_federation_resource = MockHttpResource() + self.mock_config = NonCallableMock() + self.mock_config.signing_key = [MockKey()] + hs = HomeServer("test", clock=self.clock, db_pool=None, @@ -520,6 +532,7 @@ class PresencePushTestCase(unittest.TestCase): resource_for_client=Mock(), resource_for_federation=self.mock_federation_resource, http_client=self.mock_http_client, + config=self.mock_config, ) hs.handlers = JustPresenceHandlers(hs) @@ -995,6 +1008,9 @@ class PresencePollingTestCase(unittest.TestCase): self.mock_federation_resource = MockHttpResource() + self.mock_config = NonCallableMock() + self.mock_config.signing_key = [MockKey()] + hs = HomeServer("test", clock=MockClock(), db_pool=None, @@ -1009,6 +1025,7 @@ class PresencePollingTestCase(unittest.TestCase): resource_for_client=Mock(), resource_for_federation=self.mock_federation_resource, http_client=self.mock_http_client, + config = self.mock_config, ) hs.handlers = JustPresenceHandlers(hs) diff --git a/tests/handlers/test_room.py b/tests/handlers/test_room.py index a1a2e80492..c88d1c8840 100644 --- a/tests/handlers/test_room.py +++ b/tests/handlers/test_room.py @@ -24,6 +24,7 @@ from synapse.api.constants import Membership from synapse.handlers.room import RoomMemberHandler, RoomCreationHandler from synapse.handlers.profile import ProfileHandler from synapse.server import HomeServer +from ..utils import MockKey from mock import Mock, NonCallableMock @@ -31,6 +32,8 @@ from mock import Mock, NonCallableMock class RoomMemberHandlerTestCase(unittest.TestCase): def setUp(self): + self.mock_config = NonCallableMock() + self.mock_config.signing_key = [MockKey()] self.hostname = "red" hs = HomeServer( self.hostname, @@ -38,7 +41,6 @@ class RoomMemberHandlerTestCase(unittest.TestCase): ratelimiter=NonCallableMock(spec_set=[ "send_message", ]), - config=NonCallableMock(), datastore=NonCallableMock(spec_set=[ "persist_event", "get_joined_hosts_for_room", @@ -57,6 +59,7 @@ class RoomMemberHandlerTestCase(unittest.TestCase): ]), auth=NonCallableMock(spec_set=["check"]), state_handler=NonCallableMock(spec_set=["handle_new_event"]), + config=self.mock_config, ) self.federation = NonCallableMock(spec_set=[ diff --git a/tests/handlers/test_typing.py b/tests/handlers/test_typing.py index a66f208abf..0ab829b9ad 100644 --- a/tests/handlers/test_typing.py +++ b/tests/handlers/test_typing.py @@ -20,7 +20,7 @@ from twisted.internet import defer from mock import Mock, call, ANY import json -from ..utils import MockHttpResource, MockClock, DeferredMockCallable +from ..utils import MockHttpResource, MockClock, DeferredMockCallable, MockKey from synapse.server import HomeServer from synapse.handlers.typing import TypingNotificationHandler @@ -61,6 +61,9 @@ class TypingNotificationsTestCase(unittest.TestCase): self.mock_federation_resource = MockHttpResource() + self.mock_config = Mock() + self.mock_config.signing_key = [MockKey()] + hs = HomeServer("test", clock=self.clock, db_pool=None, @@ -75,6 +78,7 @@ class TypingNotificationsTestCase(unittest.TestCase): resource_for_client=Mock(), resource_for_federation=self.mock_federation_resource, http_client=self.mock_http_client, + config=self.mock_config, ) hs.handlers = JustTypingNotificationHandlers(hs) diff --git a/tests/rest/test_presence.py b/tests/rest/test_presence.py index ea3478ac5d..20fd179003 100644 --- a/tests/rest/test_presence.py +++ b/tests/rest/test_presence.py @@ -20,7 +20,7 @@ from twisted.internet import defer from mock import Mock -from ..utils import MockHttpResource +from ..utils import MockHttpResource, MockKey from synapse.api.constants import PresenceState from synapse.handlers.presence import PresenceHandler @@ -45,7 +45,8 @@ class PresenceStateTestCase(unittest.TestCase): def setUp(self): self.mock_resource = MockHttpResource(prefix=PATH_PREFIX) - + self.mock_config = Mock() + self.mock_config.signing_key = [MockKey()] hs = HomeServer("test", db_pool=None, datastore=Mock(spec=[ @@ -55,6 +56,7 @@ class PresenceStateTestCase(unittest.TestCase): http_client=None, resource_for_client=self.mock_resource, resource_for_federation=self.mock_resource, + config=self.mock_config, ) hs.handlers = JustPresenceHandlers(hs) @@ -119,6 +121,8 @@ class PresenceListTestCase(unittest.TestCase): def setUp(self): self.mock_resource = MockHttpResource(prefix=PATH_PREFIX) + self.mock_config = Mock() + self.mock_config.signing_key = [MockKey()] hs = HomeServer("test", db_pool=None, @@ -134,7 +138,8 @@ class PresenceListTestCase(unittest.TestCase): ]), http_client=None, resource_for_client=self.mock_resource, - resource_for_federation=self.mock_resource + resource_for_federation=self.mock_resource, + config=self.mock_config, ) hs.handlers = JustPresenceHandlers(hs) @@ -225,6 +230,9 @@ class PresenceEventStreamTestCase(unittest.TestCase): def setUp(self): self.mock_resource = MockHttpResource(prefix=PATH_PREFIX) + self.mock_config = Mock() + self.mock_config.signing_key = [MockKey()] + # HIDEOUS HACKERY # TODO(paul): This should be injected in via the HomeServer DI system from synapse.streams.events import ( @@ -255,6 +263,7 @@ class PresenceEventStreamTestCase(unittest.TestCase): "cancel_call_later", "time_msec", ]), + config=self.mock_config, ) hs.get_clock().time_msec.return_value = 1000000 diff --git a/tests/utils.py b/tests/utils.py index bc5d35e56b..beb2aef084 100644 --- a/tests/utils.py +++ b/tests/utils.py @@ -108,6 +108,21 @@ class MockHttpResource(HttpServer): self.callbacks.append((method, path_pattern, callback)) +class MockKey(object): + alg = "mock_alg" + version = "mock_version" + + @property + def verify_key(self): + return self + + def sign(self, message): + return b"\x9a\x87$" + + def verify(self, message, sig): + assert sig == b"\x9a\x87$" + + class MockClock(object): now = 1000 From 0fdf3088743b25e9fcc39b7b3b4c7f6e8332e26c Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Fri, 26 Sep 2014 16:36:24 +0100 Subject: [PATCH 010/106] Track the IP users connect with. Add an admin column to users table. --- synapse/api/auth.py | 10 +++++++++- synapse/rest/register.py | 8 +------- synapse/server.py | 12 ++++++++++++ synapse/storage/__init__.py | 12 +++++++++++- synapse/storage/schema/delta/v5.sql | 13 +++++++++++++ synapse/storage/schema/users.sql | 11 +++++++++++ tests/rest/test_presence.py | 6 +++++- tests/rest/test_profile.py | 4 ++-- tests/utils.py | 3 +++ 9 files changed, 67 insertions(+), 12 deletions(-) create mode 100644 synapse/storage/schema/delta/v5.sql diff --git a/synapse/api/auth.py b/synapse/api/auth.py index 9bfd25c86e..6f8146ec3a 100644 --- a/synapse/api/auth.py +++ b/synapse/api/auth.py @@ -206,6 +206,7 @@ class Auth(object): defer.returnValue(True) + @defer.inlineCallbacks def get_user_by_req(self, request): """ Get a registered user's ID. @@ -218,7 +219,14 @@ class Auth(object): """ # Can optionally look elsewhere in the request (e.g. headers) try: - return self.get_user_by_token(request.args["access_token"][0]) + access_token = request.args["access_token"][0] + user = yield self.get_user_by_token(access_token) + + ip_addr = self.hs.get_ip_from_request(request) + if user and access_token and ip_addr: + self.store.insert_client_ip(user, access_token, ip_addr) + + defer.returnValue(user) except KeyError: raise AuthError(403, "Missing access token.") diff --git a/synapse/rest/register.py b/synapse/rest/register.py index 4935e323d9..804117ee09 100644 --- a/synapse/rest/register.py +++ b/synapse/rest/register.py @@ -195,13 +195,7 @@ class RegisterRestServlet(RestServlet): raise SynapseError(400, "Captcha response is required", errcode=Codes.CAPTCHA_NEEDED) - # May be an X-Forwarding-For header depending on config - ip_addr = request.getClientIP() - if self.hs.config.captcha_ip_origin_is_x_forwarded: - # use the header - if request.requestHeaders.hasHeader("X-Forwarded-For"): - ip_addr = request.requestHeaders.getRawHeaders( - "X-Forwarded-For")[0] + ip_addr = self.hs.get_ip_from_request(request) handler = self.handlers.registration_handler yield handler.check_recaptcha( diff --git a/synapse/server.py b/synapse/server.py index cdea49e6ab..e5b048ede0 100644 --- a/synapse/server.py +++ b/synapse/server.py @@ -143,6 +143,18 @@ class BaseHomeServer(object): def serialize_event(self, e): return serialize_event(self, e) + def get_ip_from_request(self, request): + # May be an X-Forwarding-For header depending on config + ip_addr = request.getClientIP() + if self.config.captcha_ip_origin_is_x_forwarded: + # use the header + if request.requestHeaders.hasHeader("X-Forwarded-For"): + ip_addr = request.requestHeaders.getRawHeaders( + "X-Forwarded-For" + )[0] + + return ip_addr + # Build magic accessors for every dependency for depname in BaseHomeServer.DEPENDENCIES: BaseHomeServer._make_dependency_method(depname) diff --git a/synapse/storage/__init__.py b/synapse/storage/__init__.py index 15919eb580..d53c090a91 100644 --- a/synapse/storage/__init__.py +++ b/synapse/storage/__init__.py @@ -63,7 +63,7 @@ SCHEMAS = [ # Remember to update this number every time an incompatible change is made to # database schema files, so the users will be informed on server restarts. -SCHEMA_VERSION = 4 +SCHEMA_VERSION = 5 class _RollbackButIsFineException(Exception): @@ -294,6 +294,16 @@ class DataStore(RoomMemberStore, RoomStore, defer.returnValue(self.min_token) + def insert_client_ip(self, user, access_token, ip): + return self._simple_insert( + "user_ips", + { + "user": user.to_string(), + "access_token": access_token, + "ip": ip + } + ) + def snapshot_room(self, room_id, user_id, state_type=None, state_key=None): """Snapshot the room for an update by a user Args: diff --git a/synapse/storage/schema/delta/v5.sql b/synapse/storage/schema/delta/v5.sql new file mode 100644 index 0000000000..380eec6f35 --- /dev/null +++ b/synapse/storage/schema/delta/v5.sql @@ -0,0 +1,13 @@ + +CREATE TABLE IF NOT EXISTS user_ips ( + user TEXT NOT NULL, + access_token TEXT NOT NULL, + ip TEXT NOT NULL, + CONSTRAINT user_ip UNIQUE (user, access_token, ip) ON CONFLICT IGNORE +); + +CREATE INDEX IF NOT EXISTS user_ips_user ON user_ips(user); + +ALTER TABLE users ADD COLUMN admin BOOL DEFAULT 0 NOT NULL; + +PRAGMA user_version = 5; diff --git a/synapse/storage/schema/users.sql b/synapse/storage/schema/users.sql index 2519702971..89eab8babe 100644 --- a/synapse/storage/schema/users.sql +++ b/synapse/storage/schema/users.sql @@ -17,6 +17,7 @@ CREATE TABLE IF NOT EXISTS users( name TEXT, password_hash TEXT, creation_ts INTEGER, + admin BOOL DEFAULT 0 NOT NULL, UNIQUE(name) ON CONFLICT ROLLBACK ); @@ -29,3 +30,13 @@ CREATE TABLE IF NOT EXISTS access_tokens( FOREIGN KEY(user_id) REFERENCES users(id), UNIQUE(token) ON CONFLICT ROLLBACK ); + +CREATE TABLE IF NOT EXISTS user_ips ( + user TEXT NOT NULL, + access_token TEXT NOT NULL, + ip TEXT NOT NULL, + CONSTRAINT user_ip UNIQUE (user, access_token, ip) ON CONFLICT IGNORE +); + +CREATE INDEX IF NOT EXISTS user_ips_user ON user_ips(user); + diff --git a/tests/rest/test_presence.py b/tests/rest/test_presence.py index ea3478ac5d..1b3e6759c2 100644 --- a/tests/rest/test_presence.py +++ b/tests/rest/test_presence.py @@ -51,10 +51,12 @@ class PresenceStateTestCase(unittest.TestCase): datastore=Mock(spec=[ "get_presence_state", "set_presence_state", + "insert_client_ip", ]), http_client=None, resource_for_client=self.mock_resource, resource_for_federation=self.mock_resource, + config=Mock(), ) hs.handlers = JustPresenceHandlers(hs) @@ -131,10 +133,12 @@ class PresenceListTestCase(unittest.TestCase): "set_presence_list_accepted", "del_presence_list", "get_presence_list", + "insert_client_ip", ]), http_client=None, resource_for_client=self.mock_resource, - resource_for_federation=self.mock_resource + resource_for_federation=self.mock_resource, + config=Mock(), ) hs.handlers = JustPresenceHandlers(hs) diff --git a/tests/rest/test_profile.py b/tests/rest/test_profile.py index e6e51f6dd0..b0f48e7fd8 100644 --- a/tests/rest/test_profile.py +++ b/tests/rest/test_profile.py @@ -50,10 +50,10 @@ class ProfileTestCase(unittest.TestCase): datastore=None, ) - def _get_user_by_token(token=None): + def _get_user_by_req(request=None): return hs.parse_userid(myid) - hs.get_auth().get_user_by_token = _get_user_by_token + hs.get_auth().get_user_by_req = _get_user_by_req hs.get_handlers().profile_handler = self.mock_handler diff --git a/tests/utils.py b/tests/utils.py index bb8e9964dd..ae97621147 100644 --- a/tests/utils.py +++ b/tests/utils.py @@ -264,6 +264,9 @@ class MemoryDataStore(object): def get_ops_levels(self, room_id): return defer.succeed((5, 5, 5)) + def insert_client_ip(self, user, access_token, ip_addr): + return defer.succeed(None) + def _format_call(args, kwargs): return ", ".join( From f7d80930f21190355733da9ba7ab5068ce0702a8 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Mon, 29 Sep 2014 13:35:15 +0100 Subject: [PATCH 011/106] SYN-48: Track User-Agents as well as IPs for client devices. --- synapse/api/auth.py | 11 ++++++++++- synapse/storage/__init__.py | 6 ++++-- synapse/storage/schema/delta/v5.sql | 4 +++- synapse/storage/schema/users.sql | 4 +++- 4 files changed, 20 insertions(+), 5 deletions(-) diff --git a/synapse/api/auth.py b/synapse/api/auth.py index 6f8146ec3a..739f77afd4 100644 --- a/synapse/api/auth.py +++ b/synapse/api/auth.py @@ -223,8 +223,17 @@ class Auth(object): user = yield self.get_user_by_token(access_token) ip_addr = self.hs.get_ip_from_request(request) + user_agent = request.requestHeaders.getRawHeaders( + "User-Agent", + default=[""] + )[0] if user and access_token and ip_addr: - self.store.insert_client_ip(user, access_token, ip_addr) + self.store.insert_client_ip( + user, + access_token, + ip_addr, + user_agent + ) defer.returnValue(user) except KeyError: diff --git a/synapse/storage/__init__.py b/synapse/storage/__init__.py index d53c090a91..169a80dce4 100644 --- a/synapse/storage/__init__.py +++ b/synapse/storage/__init__.py @@ -294,13 +294,15 @@ class DataStore(RoomMemberStore, RoomStore, defer.returnValue(self.min_token) - def insert_client_ip(self, user, access_token, ip): + def insert_client_ip(self, user, access_token, ip, user_agent): return self._simple_insert( "user_ips", { "user": user.to_string(), "access_token": access_token, - "ip": ip + "ip": ip, + "user_agent": user_agent, + "last_used": int(self._clock.time()), } ) diff --git a/synapse/storage/schema/delta/v5.sql b/synapse/storage/schema/delta/v5.sql index 380eec6f35..f5a667a250 100644 --- a/synapse/storage/schema/delta/v5.sql +++ b/synapse/storage/schema/delta/v5.sql @@ -3,7 +3,9 @@ CREATE TABLE IF NOT EXISTS user_ips ( user TEXT NOT NULL, access_token TEXT NOT NULL, ip TEXT NOT NULL, - CONSTRAINT user_ip UNIQUE (user, access_token, ip) ON CONFLICT IGNORE + user_agent TEXT NOT NULL, + last_used INTEGER NOT NULL, + CONSTRAINT user_ip UNIQUE (user, access_token, ip, user_agent) ON CONFLICT REPLACE ); CREATE INDEX IF NOT EXISTS user_ips_user ON user_ips(user); diff --git a/synapse/storage/schema/users.sql b/synapse/storage/schema/users.sql index 89eab8babe..d96dd9f075 100644 --- a/synapse/storage/schema/users.sql +++ b/synapse/storage/schema/users.sql @@ -35,7 +35,9 @@ CREATE TABLE IF NOT EXISTS user_ips ( user TEXT NOT NULL, access_token TEXT NOT NULL, ip TEXT NOT NULL, - CONSTRAINT user_ip UNIQUE (user, access_token, ip) ON CONFLICT IGNORE + user_agent TEXT NOT NULL, + last_used INTEGER NOT NULL, + CONSTRAINT user_ip UNIQUE (user, access_token, ip, user_agent) ON CONFLICT REPLACE ); CREATE INDEX IF NOT EXISTS user_ips_user ON user_ips(user); From c65306f8779d480a10b6ce318e73b458538e1eef Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Mon, 29 Sep 2014 13:35:38 +0100 Subject: [PATCH 012/106] Add auth check to test if a user is an admin or not. --- synapse/api/auth.py | 3 +++ synapse/storage/registration.py | 8 ++++++++ 2 files changed, 11 insertions(+) diff --git a/synapse/api/auth.py b/synapse/api/auth.py index 739f77afd4..5e3ea5b8c5 100644 --- a/synapse/api/auth.py +++ b/synapse/api/auth.py @@ -259,6 +259,9 @@ class Auth(object): raise AuthError(403, "Unrecognised access token.", errcode=Codes.UNKNOWN_TOKEN) + def is_server_admin(self, user): + return self.store.is_server_admin(user) + @defer.inlineCallbacks @log_function def _can_send_event(self, event): diff --git a/synapse/storage/registration.py b/synapse/storage/registration.py index db20b1daa0..f32b000cb6 100644 --- a/synapse/storage/registration.py +++ b/synapse/storage/registration.py @@ -103,6 +103,14 @@ class RegistrationStore(SQLBaseStore): token) defer.returnValue(user_id) + @defer.inlineCallbacks + def is_server_admin(self, user): + return self._simple_select_one_onecol( + table="users", + keyvalues={"name": user.to_string()}, + retcol="admin", + ) + def _query_for_auth(self, txn, token): txn.execute("SELECT users.name FROM access_tokens LEFT JOIN users" + " ON users.id = access_tokens.user_id WHERE token = ?", From 472ef191004beaf0102fc7940f1040f9de895935 Mon Sep 17 00:00:00 2001 From: "Paul \"LeoNerd\" Evans" Date: Mon, 29 Sep 2014 14:22:21 +0100 Subject: [PATCH 013/106] No longer need the Freenode verification key file --- docs/freenode.txt | 1 - 1 file changed, 1 deletion(-) delete mode 100644 docs/freenode.txt diff --git a/docs/freenode.txt b/docs/freenode.txt deleted file mode 100644 index 84fdf6d523..0000000000 --- a/docs/freenode.txt +++ /dev/null @@ -1 +0,0 @@ -NCjcRSEG From 3ccb17ce592d7e75e0bd0237c347d64f63d5eb10 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Mon, 29 Sep 2014 14:59:52 +0100 Subject: [PATCH 014/106] SYN-48: Implement WHOIS rest servlet --- synapse/api/auth.py | 28 ++++++++----- synapse/handlers/__init__.py | 2 + synapse/handlers/admin.py | 62 +++++++++++++++++++++++++++++ synapse/rest/__init__.py | 4 +- synapse/rest/admin.py | 47 ++++++++++++++++++++++ synapse/storage/__init__.py | 40 ++++++++++++++++++- synapse/storage/registration.py | 26 +++++++----- synapse/storage/schema/delta/v5.sql | 3 +- synapse/storage/schema/users.sql | 3 +- 9 files changed, 190 insertions(+), 25 deletions(-) create mode 100644 synapse/handlers/admin.py create mode 100644 synapse/rest/admin.py diff --git a/synapse/api/auth.py b/synapse/api/auth.py index 5e3ea5b8c5..8f7982c7fa 100644 --- a/synapse/api/auth.py +++ b/synapse/api/auth.py @@ -220,7 +220,8 @@ class Auth(object): # Can optionally look elsewhere in the request (e.g. headers) try: access_token = request.args["access_token"][0] - user = yield self.get_user_by_token(access_token) + user_info = yield self.get_user_by_token(access_token) + user = user_info["user"] ip_addr = self.hs.get_ip_from_request(request) user_agent = request.requestHeaders.getRawHeaders( @@ -229,10 +230,11 @@ class Auth(object): )[0] if user and access_token and ip_addr: self.store.insert_client_ip( - user, - access_token, - ip_addr, - user_agent + user=user, + access_token=access_token, + device_id=user_info["device_id"], + ip=ip_addr, + user_agent=user_agent ) defer.returnValue(user) @@ -246,15 +248,23 @@ class Auth(object): Args: token (str)- The access token to get the user by. Returns: - UserID : User ID object of the user who has that access token. + dict : dict that includes the user, device_id, and whether the + user is a server admin. Raises: AuthError if no user by that token exists or the token is invalid. """ try: - user_id = yield self.store.get_user_by_token(token=token) - if not user_id: + ret = yield self.store.get_user_by_token(token=token) + if not ret: raise StoreError() - defer.returnValue(self.hs.parse_userid(user_id)) + + user_info = { + "admin": bool(ret.get("admin", False)), + "device_id": ret.get("device_id"), + "user": self.hs.parse_userid(ret.get("name")), + } + + defer.returnValue(user_info) except StoreError: raise AuthError(403, "Unrecognised access token.", errcode=Codes.UNKNOWN_TOKEN) diff --git a/synapse/handlers/__init__.py b/synapse/handlers/__init__.py index 5308e2c8e1..d5df3c630b 100644 --- a/synapse/handlers/__init__.py +++ b/synapse/handlers/__init__.py @@ -25,6 +25,7 @@ from .profile import ProfileHandler from .presence import PresenceHandler from .directory import DirectoryHandler from .typing import TypingNotificationHandler +from .admin import AdminHandler class Handlers(object): @@ -49,3 +50,4 @@ class Handlers(object): self.login_handler = LoginHandler(hs) self.directory_handler = DirectoryHandler(hs) self.typing_notification_handler = TypingNotificationHandler(hs) + self.admin_handler = AdminHandler(hs) diff --git a/synapse/handlers/admin.py b/synapse/handlers/admin.py new file mode 100644 index 0000000000..687b343a1d --- /dev/null +++ b/synapse/handlers/admin.py @@ -0,0 +1,62 @@ +# -*- coding: utf-8 -*- +# Copyright 2014 OpenMarket Ltd +# +# Licensed under the Apache License, Version 2.0 (the "License"); +# you may not use this file except in compliance with the License. +# You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. + +from twisted.internet import defer + +from ._base import BaseHandler + +import logging + + +logger = logging.getLogger(__name__) + + +class AdminHandler(BaseHandler): + + def __init__(self, hs): + super(AdminHandler, self).__init__(hs) + + @defer.inlineCallbacks + def get_whois(self, user): + res = yield self.store.get_user_ip_and_agents(user) + + d = {} + for r in res: + device = d.setdefault(r["device_id"], {}) + session = device.setdefault(r["access_token"], []) + session.append({ + "ip": r["ip"], + "user_agent": r["user_agent"], + "last_seen": r["last_seen"], + }) + + ret = { + "user_id": user.to_string(), + "devices": [ + { + "device_id": k, + "sessions": [ + { + # "access_token": x, TODO (erikj) + "connections": y, + } + for x, y in v.items() + ] + } + for k, v in d.items() + ], + } + + defer.returnValue(ret) diff --git a/synapse/rest/__init__.py b/synapse/rest/__init__.py index 3b9aa59733..e391e5678d 100644 --- a/synapse/rest/__init__.py +++ b/synapse/rest/__init__.py @@ -15,7 +15,8 @@ from . import ( - room, events, register, login, profile, presence, initial_sync, directory, voip + room, events, register, login, profile, presence, initial_sync, directory, + voip, admin, ) @@ -43,3 +44,4 @@ class RestServletFactory(object): initial_sync.register_servlets(hs, client_resource) directory.register_servlets(hs, client_resource) voip.register_servlets(hs, client_resource) + admin.register_servlets(hs, client_resource) diff --git a/synapse/rest/admin.py b/synapse/rest/admin.py new file mode 100644 index 0000000000..97eb1954e0 --- /dev/null +++ b/synapse/rest/admin.py @@ -0,0 +1,47 @@ +# -*- coding: utf-8 -*- +# Copyright 2014 OpenMarket Ltd +# +# Licensed under the Apache License, Version 2.0 (the "License"); +# you may not use this file except in compliance with the License. +# You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. + +from twisted.internet import defer + +from synapse.api.errors import AuthError, SynapseError +from base import RestServlet, client_path_pattern + +import logging + +logger = logging.getLogger(__name__) + + +class WhoisRestServlet(RestServlet): + PATTERN = client_path_pattern("/admin/whois/(?P[^/]*)") + + @defer.inlineCallbacks + def on_GET(self, request, user_id): + target_user = self.hs.parse_userid(user_id) + auth_user = yield self.auth.get_user_by_req(request) + is_admin = yield self.auth.is_server_admin(auth_user) + + if not is_admin and target_user != auth_user: + raise AuthError(403, "You are not a server admin") + + if not target_user.is_mine: + raise SynapseError(400, "Can only whois a local user") + + ret = yield self.handlers.admin_handler.get_whois(auth_user) + + defer.returnValue((200, ret)) + + +def register_servlets(hs, http_server): + WhoisRestServlet(hs).register(http_server) diff --git a/synapse/storage/__init__.py b/synapse/storage/__init__.py index 169a80dce4..749347d5a8 100644 --- a/synapse/storage/__init__.py +++ b/synapse/storage/__init__.py @@ -294,18 +294,54 @@ class DataStore(RoomMemberStore, RoomStore, defer.returnValue(self.min_token) - def insert_client_ip(self, user, access_token, ip, user_agent): + def insert_client_ip(self, user, access_token, device_id, ip, user_agent): return self._simple_insert( "user_ips", { "user": user.to_string(), "access_token": access_token, + "device_id": device_id, "ip": ip, "user_agent": user_agent, - "last_used": int(self._clock.time()), + "last_seen": int(self._clock.time_msec()), } ) + def get_user_ip_and_agents(self, user): + return self._simple_select_list( + table="user_ips", + keyvalues={"user": user.to_string()}, + retcols=[ + "device_id", "access_token", "ip", "user_agent", "last_seen" + ], + ) + + d = {} + for r in res: + device = d.setdefault(r["device_id"], {}) + session = device.setdefault(r["access_token"], []) + session.append({ + "ip": r["ip"], + "user_agent": r["user_agent"], + "last_seen": r["last_seen"], + }) + + defer.returnValue( + [ + { + "device_id": k, + "sessions": [ + { + "access_token": x, + "connections": y, + } + for x, y in v.items() + ] + } + for k, v in d.items() + ] + ) + def snapshot_room(self, room_id, user_id, state_type=None, state_key=None): """Snapshot the room for an update by a user Args: diff --git a/synapse/storage/registration.py b/synapse/storage/registration.py index f32b000cb6..cf43209367 100644 --- a/synapse/storage/registration.py +++ b/synapse/storage/registration.py @@ -88,7 +88,6 @@ class RegistrationStore(SQLBaseStore): query, user_id ) - @defer.inlineCallbacks def get_user_by_token(self, token): """Get a user from the given access token. @@ -99,11 +98,11 @@ class RegistrationStore(SQLBaseStore): Raises: StoreError if no user was found. """ - user_id = yield self.runInteraction(self._query_for_auth, - token) - defer.returnValue(user_id) + return self.runInteraction( + self._query_for_auth, + token + ) - @defer.inlineCallbacks def is_server_admin(self, user): return self._simple_select_one_onecol( table="users", @@ -112,11 +111,16 @@ class RegistrationStore(SQLBaseStore): ) def _query_for_auth(self, txn, token): - txn.execute("SELECT users.name FROM access_tokens LEFT JOIN users" + - " ON users.id = access_tokens.user_id WHERE token = ?", - [token]) - row = txn.fetchone() - if row: - return row[0] + sql = ( + "SELECT users.name, users.admin, access_tokens.device_id " + "FROM users " + "INNER JOIN access_tokens on users.id = access_tokens.user_id " + "WHERE token = ?" + ) + + cursor = txn.execute(sql, (token,)) + rows = self.cursor_to_dict(cursor) + if rows: + return rows[0] raise StoreError(404, "Token not found.") diff --git a/synapse/storage/schema/delta/v5.sql b/synapse/storage/schema/delta/v5.sql index f5a667a250..af9df11aa9 100644 --- a/synapse/storage/schema/delta/v5.sql +++ b/synapse/storage/schema/delta/v5.sql @@ -2,9 +2,10 @@ CREATE TABLE IF NOT EXISTS user_ips ( user TEXT NOT NULL, access_token TEXT NOT NULL, + device_id TEXT, ip TEXT NOT NULL, user_agent TEXT NOT NULL, - last_used INTEGER NOT NULL, + last_seen INTEGER NOT NULL, CONSTRAINT user_ip UNIQUE (user, access_token, ip, user_agent) ON CONFLICT REPLACE ); diff --git a/synapse/storage/schema/users.sql b/synapse/storage/schema/users.sql index d96dd9f075..8244f733bd 100644 --- a/synapse/storage/schema/users.sql +++ b/synapse/storage/schema/users.sql @@ -34,9 +34,10 @@ CREATE TABLE IF NOT EXISTS access_tokens( CREATE TABLE IF NOT EXISTS user_ips ( user TEXT NOT NULL, access_token TEXT NOT NULL, + device_id TEXT, ip TEXT NOT NULL, user_agent TEXT NOT NULL, - last_used INTEGER NOT NULL, + last_seen INTEGER NOT NULL, CONSTRAINT user_ip UNIQUE (user, access_token, ip, user_agent) ON CONFLICT REPLACE ); From 1132663cc7d2b168b32b0b48f65bbdf161d090f4 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Mon, 29 Sep 2014 15:04:04 +0100 Subject: [PATCH 015/106] SYN-48: Fix typo. Get the whois for requested user rather tahan the requester --- synapse/rest/admin.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/synapse/rest/admin.py b/synapse/rest/admin.py index 97eb1954e0..ed9b484623 100644 --- a/synapse/rest/admin.py +++ b/synapse/rest/admin.py @@ -38,7 +38,7 @@ class WhoisRestServlet(RestServlet): if not target_user.is_mine: raise SynapseError(400, "Can only whois a local user") - ret = yield self.handlers.admin_handler.get_whois(auth_user) + ret = yield self.handlers.admin_handler.get_whois(target_user) defer.returnValue((200, ret)) From 1550ab9e2f8288722ec7c3daa992b33945c2f4f5 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Mon, 29 Sep 2014 15:04:47 +0100 Subject: [PATCH 016/106] SYN-48: Delete dead code --- synapse/storage/__init__.py | 26 -------------------------- 1 file changed, 26 deletions(-) diff --git a/synapse/storage/__init__.py b/synapse/storage/__init__.py index 749347d5a8..1ebbeab2e7 100644 --- a/synapse/storage/__init__.py +++ b/synapse/storage/__init__.py @@ -316,32 +316,6 @@ class DataStore(RoomMemberStore, RoomStore, ], ) - d = {} - for r in res: - device = d.setdefault(r["device_id"], {}) - session = device.setdefault(r["access_token"], []) - session.append({ - "ip": r["ip"], - "user_agent": r["user_agent"], - "last_seen": r["last_seen"], - }) - - defer.returnValue( - [ - { - "device_id": k, - "sessions": [ - { - "access_token": x, - "connections": y, - } - for x, y in v.items() - ] - } - for k, v in d.items() - ] - ) - def snapshot_room(self, room_id, user_id, state_type=None, state_key=None): """Snapshot the room for an update by a user Args: From 7151615260d50c40341fb168bfe804be0d94ec24 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Mon, 29 Sep 2014 15:35:54 +0100 Subject: [PATCH 017/106] Update docstring --- synapse/api/auth.py | 2 +- synapse/storage/registration.py | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/synapse/api/auth.py b/synapse/api/auth.py index 8f7982c7fa..e1b1823cd7 100644 --- a/synapse/api/auth.py +++ b/synapse/api/auth.py @@ -246,7 +246,7 @@ class Auth(object): """ Get a registered user's ID. Args: - token (str)- The access token to get the user by. + token (str): The access token to get the user by. Returns: dict : dict that includes the user, device_id, and whether the user is a server admin. diff --git a/synapse/storage/registration.py b/synapse/storage/registration.py index cf43209367..719806f82b 100644 --- a/synapse/storage/registration.py +++ b/synapse/storage/registration.py @@ -94,7 +94,8 @@ class RegistrationStore(SQLBaseStore): Args: token (str): The access token of a user. Returns: - str: The user ID of the user. + dict: Including the name (user_id), device_id and whether they are + an admin. Raises: StoreError if no user was found. """ From d96cb61f26fa5ed3f0aab9b4c461e9656d986194 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Mon, 29 Sep 2014 15:35:57 +0100 Subject: [PATCH 018/106] Unbreak tests after changing storage API --- tests/rest/test_presence.py | 12 +++++++-- tests/rest/test_rooms.py | 41 +++++++++++++++++++++++++----- tests/storage/test_registration.py | 4 +-- tests/utils.py | 8 ++++-- 4 files changed, 53 insertions(+), 12 deletions(-) diff --git a/tests/rest/test_presence.py b/tests/rest/test_presence.py index 1b3e6759c2..e2dc3dec81 100644 --- a/tests/rest/test_presence.py +++ b/tests/rest/test_presence.py @@ -67,7 +67,11 @@ class PresenceStateTestCase(unittest.TestCase): self.datastore.get_presence_list = get_presence_list def _get_user_by_token(token=None): - return hs.parse_userid(myid) + return { + "user": hs.parse_userid(myid), + "admin": False, + "device_id": None, + } hs.get_auth().get_user_by_token = _get_user_by_token @@ -151,7 +155,11 @@ class PresenceListTestCase(unittest.TestCase): self.datastore.has_presence_state = has_presence_state def _get_user_by_token(token=None): - return hs.parse_userid(myid) + return { + "user": hs.parse_userid(myid), + "admin": False, + "device_id": None, + } room_member_handler = hs.handlers.room_member_handler = Mock( spec=[ diff --git a/tests/rest/test_rooms.py b/tests/rest/test_rooms.py index 4ea5828d4f..1ce9b8a83d 100644 --- a/tests/rest/test_rooms.py +++ b/tests/rest/test_rooms.py @@ -69,7 +69,11 @@ class RoomPermissionsTestCase(RestTestCase): hs.get_handlers().federation_handler = Mock() def _get_user_by_token(token=None): - return hs.parse_userid(self.auth_user_id) + return { + "user": hs.parse_userid(self.auth_user_id), + "admin": False, + "device_id": None, + } hs.get_auth().get_user_by_token = _get_user_by_token self.auth_user_id = self.rmcreator_id @@ -425,7 +429,11 @@ class RoomsMemberListTestCase(RestTestCase): self.auth_user_id = self.user_id def _get_user_by_token(token=None): - return hs.parse_userid(self.auth_user_id) + return { + "user": hs.parse_userid(self.auth_user_id), + "admin": False, + "device_id": None, + } hs.get_auth().get_user_by_token = _get_user_by_token synapse.rest.room.register_servlets(hs, self.mock_resource) @@ -508,7 +516,11 @@ class RoomsCreateTestCase(RestTestCase): hs.get_handlers().federation_handler = Mock() def _get_user_by_token(token=None): - return hs.parse_userid(self.auth_user_id) + return { + "user": hs.parse_userid(self.auth_user_id), + "admin": False, + "device_id": None, + } hs.get_auth().get_user_by_token = _get_user_by_token synapse.rest.room.register_servlets(hs, self.mock_resource) @@ -605,7 +617,11 @@ class RoomTopicTestCase(RestTestCase): hs.get_handlers().federation_handler = Mock() def _get_user_by_token(token=None): - return hs.parse_userid(self.auth_user_id) + return { + "user": hs.parse_userid(self.auth_user_id), + "admin": False, + "device_id": None, + } hs.get_auth().get_user_by_token = _get_user_by_token synapse.rest.room.register_servlets(hs, self.mock_resource) @@ -715,7 +731,16 @@ class RoomMemberStateTestCase(RestTestCase): hs.get_handlers().federation_handler = Mock() def _get_user_by_token(token=None): - return hs.parse_userid(self.auth_user_id) + return { + "user": hs.parse_userid(self.auth_user_id), + "admin": False, + "device_id": None, + } + return { + "user": hs.parse_userid(self.auth_user_id), + "admin": False, + "device_id": None, + } hs.get_auth().get_user_by_token = _get_user_by_token synapse.rest.room.register_servlets(hs, self.mock_resource) @@ -847,7 +872,11 @@ class RoomMessagesTestCase(RestTestCase): hs.get_handlers().federation_handler = Mock() def _get_user_by_token(token=None): - return hs.parse_userid(self.auth_user_id) + return { + "user": hs.parse_userid(self.auth_user_id), + "admin": False, + "device_id": None, + } hs.get_auth().get_user_by_token = _get_user_by_token synapse.rest.room.register_servlets(hs, self.mock_resource) diff --git a/tests/storage/test_registration.py b/tests/storage/test_registration.py index 91e221d53e..84bfde7568 100644 --- a/tests/storage/test_registration.py +++ b/tests/storage/test_registration.py @@ -53,7 +53,7 @@ class RegistrationStoreTestCase(unittest.TestCase): ) self.assertEquals( - self.user_id, + {"admin": 0, "device_id": None, "name": self.user_id}, (yield self.store.get_user_by_token(self.tokens[0])) ) @@ -63,7 +63,7 @@ class RegistrationStoreTestCase(unittest.TestCase): yield self.store.add_access_token_to_user(self.user_id, self.tokens[1]) self.assertEquals( - self.user_id, + {"admin": 0, "device_id": None, "name": self.user_id}, (yield self.store.get_user_by_token(self.tokens[1])) ) diff --git a/tests/utils.py b/tests/utils.py index ae97621147..e7c4bc4cad 100644 --- a/tests/utils.py +++ b/tests/utils.py @@ -167,7 +167,11 @@ class MemoryDataStore(object): def get_user_by_token(self, token): try: - return self.tokens_to_users[token] + return { + "name": self.tokens_to_users[token], + "admin": 0, + "device_id": None, + } except: raise StoreError(400, "User does not exist.") @@ -264,7 +268,7 @@ class MemoryDataStore(object): def get_ops_levels(self, room_id): return defer.succeed((5, 5, 5)) - def insert_client_ip(self, user, access_token, ip_addr): + def insert_client_ip(self, user, device_id, access_token, ip, user_agent): return defer.succeed(None) From 3656eb4740afd245028f34b0b56cb684a00269b5 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Mon, 29 Sep 2014 16:39:08 +0100 Subject: [PATCH 019/106] Add m.room.redacted in events list --- docs/specification.rst | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/docs/specification.rst b/docs/specification.rst index 370e238e00..a44c7c4882 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -968,6 +968,22 @@ prefixed with ``m.`` ``read`` (sent when the event has been observed by the end-user). The ``target_event_id`` should reference the ``m.room.message`` event being acknowledged. +``m.room.redaction`` + Summary: + Indicates a previous event has been redacted. + Type: + Non-state event + JSON format: + ``{ "reason": "string" }`` + Description: + Events can be redacted by either room or server admins. Redacting an event means that + all keys not required by the protocol are stripped off, allowing admins to remove + offensive or illegal content that may have been attached to any event. This cannot be + undone, allowing server owners to physically delete the offending data. + There is also a concept of a moderator hiding a non-state event, which can be undone, + but cannot be applied to state events. + The event that has been redacted is specified in the ``redacts`` event level key. + m.room.message msgtypes ----------------------- Each ``m.room.message`` MUST have a ``msgtype`` key which identifies the type of From 389285585d71711ba9124f64db18ad8e97e14f1a Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Mon, 29 Sep 2014 17:19:45 +0100 Subject: [PATCH 020/106] Add a 'Redactions' section. --- docs/specification.rst | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/docs/specification.rst b/docs/specification.rst index a44c7c4882..23e385688e 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -778,6 +778,23 @@ There are several APIs provided to ``GET`` events for a room: Example: TODO +Redactions +---------- +Since events are extensible it is possible for malicious users and/or servers to add +keys that are, for example offensive or illegal. Since some events cannot be simply +deleted, e.g. membership events, we instead 'redact' events. This involves removing +all keys from an event that are not required by the protocol. This stripped down +event is thereafter returned anytime a client or remote server requests it. + +Events that have been redacted include a ``redacted_because`` key whose value is the +event that caused it to be redacted, which may include a reason. + +Redacting an event cannot be undone, allowing server owners to delete the offending +content from the databases. + +Currently, only room admins can redact events by sending a ``m.room.redacted`` event, +but server admins also need to be able to redact events by a similar mechanism. + Room Events =========== From d5bf2109986190ad16bd1b48b57eff81b81b7370 Mon Sep 17 00:00:00 2001 From: "Paul \"LeoNerd\" Evans" Date: Mon, 29 Sep 2014 14:22:21 +0100 Subject: [PATCH 021/106] No longer need the Freenode verification key file --- docs/freenode.txt | 1 - 1 file changed, 1 deletion(-) delete mode 100644 docs/freenode.txt diff --git a/docs/freenode.txt b/docs/freenode.txt deleted file mode 100644 index 84fdf6d523..0000000000 --- a/docs/freenode.txt +++ /dev/null @@ -1 +0,0 @@ -NCjcRSEG From ae953b08849826331ba48297aa8e34051799cb18 Mon Sep 17 00:00:00 2001 From: "Paul \"LeoNerd\" Evans" Date: Mon, 29 Sep 2014 15:26:43 +0100 Subject: [PATCH 022/106] Huge whitespace hackery - reflow all (content) paragraphs at tw=80 --- docs/specification.rst | 818 ++++++++++++++++++++++------------------- 1 file changed, 432 insertions(+), 386 deletions(-) diff --git a/docs/specification.rst b/docs/specification.rst index 370e238e00..3686ea8366 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -86,8 +86,8 @@ persistently pushed from A to B in an interoperable and federated manner. Architecture ============ -Clients transmit data to other clients through home servers (HSes). Clients do not communicate with each -other directly. +Clients transmit data to other clients through home servers (HSes). Clients do +not communicate with each other directly. :: @@ -104,45 +104,51 @@ other directly. | |<--------( HTTP )-----------| | +------------------+ Federation +------------------+ -A "Client" typically represents a human using a web application or mobile app. Clients use the -"Client-to-Server" (C-S) API to communicate with their home server, which stores their profile data and -their record of the conversations in which they participate. Each client is associated with a user account -(and may optionally support multiple user accounts). A user account is represented by a unique "User ID". This -ID is namespaced to the home server which allocated the account and looks like:: +A "Client" typically represents a human using a web application or mobile app. +Clients use the "Client-to-Server" (C-S) API to communicate with their home +server, which stores their profile data and their record of the conversations +in which they participate. Each client is associated with a user account (and +may optionally support multiple user accounts). A user account is represented +by a unique "User ID". This ID is namespaced to the home server which allocated +the account and looks like:: @localpart:domain -The ``localpart`` of a user ID may be a user name, or an opaque ID identifying this user. They are -case-insensitive. +The ``localpart`` of a user ID may be a user name, or an opaque ID identifying +this user. They are case-insensitive. .. TODO - Need to specify precise grammar for Matrix IDs -A "Home Server" is a server which provides C-S APIs and has the ability to federate with other HSes. -It is typically responsible for multiple clients. "Federation" is the term used to describe the -sharing of data between two or more home servers. +A "Home Server" is a server which provides C-S APIs and has the ability to +federate with other HSes. It is typically responsible for multiple clients. +"Federation" is the term used to describe the sharing of data between two or +more home servers. -Data in Matrix is encapsulated in an "event". An event is an action within the system. Typically each -action (e.g. sending a message) correlates with exactly one event. Each event has a ``type`` which is used -to differentiate different kinds of data. ``type`` values MUST be uniquely globally namespaced following -Java's `package naming conventions `, -e.g. ``com.example.myapp.event``. The special top-level namespace ``m.`` is reserved for events defined -in the Matrix specification. Events are usually sent in the context of a "Room". +Data in Matrix is encapsulated in an "event". An event is an action within the +system. Typically each action (e.g. sending a message) correlates with exactly +one event. Each event has a ``type`` which is used to differentiate different +kinds of data. ``type`` values MUST be uniquely globally namespaced following +Java's `package naming conventions +`, e.g. +``com.example.myapp.event``. The special top-level namespace ``m.`` is reserved +for events defined in the Matrix specification. Events are usually sent in the +context of a "Room". Room structure -------------- -A room is a conceptual place where users can send and receive events. Rooms -can be created, joined and left. Events are sent to a room, and all -participants in that room with sufficient access will receive the event. Rooms are uniquely +A room is a conceptual place where users can send and receive events. Rooms can +be created, joined and left. Events are sent to a room, and all participants in +that room with sufficient access will receive the event. Rooms are uniquely identified internally via a "Room ID", which look like:: !opaque_id:domain There is exactly one room ID for each room. Whilst the room ID does contain a -domain, it is simply for globally namespacing room IDs. The room does NOT reside on the -domain specified. Room IDs are not meant to be human readable. They ARE -case-sensitive. +domain, it is simply for globally namespacing room IDs. The room does NOT +reside on the domain specified. Room IDs are not meant to be human readable. +They ARE case-sensitive. The following diagram shows an ``m.room.message`` event being sent in the room ``!qporfwt:matrix.org``:: @@ -168,12 +174,13 @@ The following diagram shows an ``m.room.message`` event being sent in the room | - @bob:domain.com | |.................................| -Federation maintains shared state between multiple home servers, such that when an event is -sent to a room, the home server knows where to forward the event on to, and how to process -the event. Home servers do not need to have completely shared state in order to participate -in a room. State is scoped to a single room, and federation ensures that all home servers -have the information they need, even if that means the home server has to request more -information from another home server before processing the event. +Federation maintains shared state between multiple home servers, such that when +an event is sent to a room, the home server knows where to forward the event on +to, and how to process the event. Home servers do not need to have completely +shared state in order to participate in a room. State is scoped to a single +room, and federation ensures that all home servers have the information they +need, even if that means the home server has to request more information from +another home server before processing the event. Room Aliases ------------ @@ -185,12 +192,13 @@ Each room can also have multiple "Room Aliases", which looks like:: .. TODO - Need to specify precise grammar for Room IDs -A room alias "points" to a room ID and is the human-readable label by which rooms are -publicised and discovered. The room ID the alias is pointing to can be obtained -by visiting the domain specified. They are case-insensitive. Note that the mapping -from a room alias to a room ID is not fixed, and may change over time to point to a -different room ID. For this reason, Clients SHOULD resolve the room alias to a room ID -once and then use that ID on subsequent requests. +A room alias "points" to a room ID and is the human-readable label by which +rooms are publicised and discovered. The room ID the alias is pointing to can +be obtained by visiting the domain specified. They are case-insensitive. Note +that the mapping from a room alias to a room ID is not fixed, and may change +over time to point to a different room ID. For this reason, Clients SHOULD +resolve the room alias to a room ID once and then use that ID on subsequent +requests. :: @@ -213,50 +221,53 @@ once and then use that ID on subsequent requests. Identity -------- -Users in Matrix are identified via their user ID. However, existing 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 account. +Users in Matrix are identified via their user ID. However, existing 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 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 -can then be used by other Matrix users in order to discover other users, according -to a strict set of privacy permissions. +network accounts and phone numbers to their user ID. Linking 3PIDs creates a +mapping from a 3PID to a user ID. This mapping can then be used by other Matrix +users in order to discover other users, according to a strict set of privacy +permissions. -In order to ensure that the mapping from 3PID to user ID is genuine, a globally federated -cluster of trusted "Identity Servers" (IS) are used to perform authentication of the 3PID. -Identity servers are also used to preserve the mapping indefinitely, by replicating the -mappings across multiple ISes. +In order to ensure that the mapping from 3PID to user ID is genuine, a globally +federated cluster of trusted "Identity Servers" (IS) are used to perform +authentication of the 3PID. Identity servers are also used to preserve the +mapping indefinitely, by replicating the mappings across multiple ISes. -Usage of an IS is not required in order for a client application to be part of -the Matrix ecosystem. However, by not using an IS, discovery of users is greatly -impacted. +Usage of an IS is not required in order for a client application to be part of +the Matrix ecosystem. However, by not using an IS, discovery of users is +greatly impacted. API Standards ------------- -The mandatory baseline for communication in Matrix is exchanging JSON objects over RESTful -HTTP APIs. HTTPS is mandated as the baseline for server-server (federation) communication. -HTTPS is recommended for client-server communication, although HTTP may be supported as a -fallback to support basic HTTP clients. More efficient optional transports for -client-server communication will in future be supported as optional extensions - e.g. a +The mandatory baseline for communication in Matrix is exchanging JSON objects +over RESTful HTTP APIs. HTTPS is mandated as the baseline for server-server +(federation) communication. HTTPS is recommended for client-server +communication, although HTTP may be supported as a fallback to support basic +HTTP clients. More efficient optional transports for client-server +communication will in future be supported as optional extensions - e.g. a packed binary encoding over stream-cipher encrypted TCP socket for low-bandwidth/low-roundtrip mobile usage. .. TODO We need to specify capability negotiation for extensible transports -For the default HTTP transport, all API calls use a Content-Type of ``application/json``. -In addition, all strings MUST be encoded as UTF-8. +For the default HTTP transport, all API calls use a Content-Type of +``application/json``. In addition, all strings MUST be encoded as UTF-8. -Clients are authenticated using opaque ``access_token`` strings (see `Registration and -Login`_ for details), passed as a querystring parameter on all requests. +Clients are authenticated using opaque ``access_token`` strings (see +`Registration and Login`_ for details), passed as a querystring parameter on +all requests. .. TODO Need to specify any HMAC or access_token lifetime/ratcheting tricks -Any errors which occur on the Matrix API level -MUST return a "standard error response". This is a JSON object which looks like:: +Any errors which occur on the Matrix API level MUST return a "standard error +response". This is a JSON object which looks like:: { "errcode": "", @@ -264,12 +275,13 @@ MUST return a "standard error response". This is a JSON object which looks like: } The ``error`` string will be a human-readable error message, usually a sentence -explaining what went wrong. The ``errcode`` string will be a unique string which can be -used to handle an error message e.g. ``M_FORBIDDEN``. These error codes should have their -namespace first in ALL CAPS, followed by a single _. For example, if there was a custom -namespace ``com.mydomain.here``, and a ``FORBIDDEN`` code, the error code should look -like ``COM.MYDOMAIN.HERE_FORBIDDEN``. There may be additional keys depending on -the error, but the keys ``error`` and ``errcode`` MUST always be present. +explaining what went wrong. The ``errcode`` string will be a unique string +which can be used to handle an error message e.g. ``M_FORBIDDEN``. These error +codes should have their namespace first in ALL CAPS, followed by a single _. +For example, if there was a custom namespace ``com.mydomain.here``, and a +``FORBIDDEN`` code, the error code should look like +``COM.MYDOMAIN.HERE_FORBIDDEN``. There may be additional keys depending on the +error, but the keys ``error`` and ``errcode`` MUST always be present. Some standard error codes are below: @@ -307,15 +319,17 @@ Some requests have unique error codes: :``M_LOGIN_EMAIL_URL_NOT_YET``: Encountered when polling for an email link which has not been clicked yet. -The C-S API typically uses ``HTTP POST`` to submit requests. This means these requests are -not idempotent. The C-S API also allows ``HTTP PUT`` to make requests idempotent. In order -to use a ``PUT``, paths should be suffixed with ``/{txnId}``. ``{txnId}`` is a -unique client-generated transaction ID which identifies the request, and is scoped to a given -Client (identified by that client's ``access_token``). Crucially, it **only** serves to -identify new requests from retransmits. After the request has finished, the ``{txnId}`` -value should be changed (how is not specified; a monotonically increasing integer is -recommended). It is preferable to use ``HTTP PUT`` to make sure requests to send messages -do not get sent more than once should clients need to retransmit requests. +The C-S API typically uses ``HTTP POST`` to submit requests. This means these +requests are not idempotent. The C-S API also allows ``HTTP PUT`` to make +requests idempotent. In order to use a ``PUT``, paths should be suffixed with +``/{txnId}``. ``{txnId}`` is a unique client-generated transaction ID which +identifies the request, and is scoped to a given Client (identified by that +client's ``access_token``). Crucially, it **only** serves to identify new +requests from retransmits. After the request has finished, the ``{txnId}`` +value should be changed (how is not specified; a monotonically increasing +integer is recommended). It is preferable to use ``HTTP PUT`` to make sure +requests to send messages do not get sent more than once should clients need to +retransmit requests. Valid requests look like:: @@ -344,12 +358,12 @@ In contrast, these are invalid requests:: Receiving live updates on a client ---------------------------------- -Clients can receive new events by long-polling the home server. This will hold open the -HTTP connection for a short period of time waiting for new events, returning early if an -event occurs. This is called the `Event Stream`_. All events which are visible to the -client will appear in the event stream. When the request -returns, an ``end`` token is included in the response. This token can be used in the next -request to continue where the client left off. +Clients can receive new events by long-polling the home server. This will hold +open the HTTP connection for a short period of time waiting for new events, +returning early if an event occurs. This is called the `Event Stream`_. All +events which are visible to the client will appear in the event stream. When +the request returns, an ``end`` token is included in the response. This token +can be used in the next request to continue where the client left off. .. TODO How do we filter the event stream? @@ -357,9 +371,9 @@ request to continue where the client left off. setup RTT latency if we only do one event per request? Do we ever support streaming requests? Why not websockets? -When the client first logs in, they will need to initially synchronise with their home -server. This is achieved via the |initialSync|_ API. This API also returns an ``end`` -token which can be used with the event stream. +When the client first logs in, they will need to initially synchronise with +their home server. This is achieved via the |initialSync|_ API. This API also +returns an ``end`` token which can be used with the event stream. Rooms ===== @@ -369,8 +383,8 @@ Creation .. TODO kegan - TODO: Key for invite these users? -To create a room, a client has to use the |createRoom|_ API. There are various options -which can be set when creating a room: +To create a room, a client has to use the |createRoom|_ API. There are various +options which can be set when creating a room: ``visibility`` Type: @@ -380,9 +394,9 @@ which can be set when creating a room: Value: Either ``public`` or ``private``. Description: - A ``public`` visibility indicates that the room will be shown in the public room list. A - ``private`` visibility will hide the room from the public room list. Rooms default to - ``public`` visibility if this key is not included. + A ``public`` visibility indicates that the room will be shown in the public + room list. A ``private`` visibility will hide the room from the public room + list. Rooms default to ``public`` visibility if this key is not included. ``room_alias_name`` Type: @@ -392,9 +406,9 @@ which can be set when creating a room: Value: The room alias localpart. Description: - If this is included, a room alias will be created and mapped to the newly created room. - The alias will belong on the same home server which created the room, e.g. - ``!qadnasoi:domain.com >>> #room_alias_name:domain.com`` + If this is included, a room alias will be created and mapped to the newly + created room. The alias will belong on the same home server which created + the room, e.g. ``!qadnasoi:domain.com >>> #room_alias_name:domain.com`` ``name`` Type: @@ -404,8 +418,9 @@ which can be set when creating a room: Value: The ``name`` value for the ``m.room.name`` state event. Description: - If this is included, an ``m.room.name`` event will be sent into the room to indicate the - name of the room. See `Room Events`_ for more information on ``m.room.name``. + If this is included, an ``m.room.name`` event will be sent into the room to + indicate the name of the room. See `Room Events`_ for more information on + ``m.room.name``. ``topic`` Type: @@ -415,8 +430,9 @@ which can be set when creating a room: Value: The ``topic`` value for the ``m.room.topic`` state event. Description: - If this is included, an ``m.room.topic`` event will be sent into the room to indicate the - topic for the room. See `Room Events`_ for more information on ``m.room.topic``. + If this is included, an ``m.room.topic`` event will be sent into the room + to indicate the topic for the room. See `Room Events`_ for more information + on ``m.room.topic``. ``invite`` Type: @@ -426,7 +442,8 @@ which can be set when creating a room: Value: A list of user ids to invite. Description: - This will tell the server to invite everyone in the list to the newly created room. + This will tell the server to invite everyone in the list to the newly + created room. Example:: @@ -437,20 +454,20 @@ Example:: "topic": "All about happy hour" } -The home server will create a ``m.room.create`` event when the room is -created, which serves as the root of the PDU graph for this room. This -event also has a ``creator`` key which contains the user ID of the room -creator. It will also generate several other events in order to manage -permissions in this room. This includes: +The home server will create a ``m.room.create`` event when the room is created, +which serves as the root of the PDU graph for this room. This event also has a +``creator`` key which contains the user ID of the room creator. It will also +generate several other events in order to manage permissions in this room. This +includes: - ``m.room.power_levels`` : Sets the power levels of users. - ``m.room.join_rules`` : Whether the room is "invite-only" or not. - - ``m.room.add_state_level``: The power level required in order to - add new state to the room (as opposed to updating exisiting state) - - ``m.room.send_event_level`` : The power level required in order to - send a message in this room. - - ``m.room.ops_level`` : The power level required in order to kick or - ban a user from the room. + - ``m.room.add_state_level``: The power level required in order to add new + state to the room (as opposed to updating exisiting state) + - ``m.room.send_event_level`` : The power level required in order to send a + message in this room. + - ``m.room.ops_level`` : The power level required in order to kick or ban a + user from the room. See `Room Events`_ for more information on these events. @@ -482,11 +499,11 @@ Permissions Permissions for rooms are done via the concept of power levels - to do any action in a room a user must have a suitable power level. -Power levels for users are defined in ``m.room.power_levels``, where both -a default and specific users' power levels can be set. By default all users -have a power level of 0, other than the room creator whose power level defaults to 100. -Power levels for users are tracked per-room even if the user is not present in -the room. +Power levels for users are defined in ``m.room.power_levels``, where both a +default and specific users' power levels can be set. By default all users have +a power level of 0, other than the room creator whose power level defaults to +100. Power levels for users are tracked per-room even if the user is not +present in the room. State events may contain a ``required_power_level`` key, which indicates the minimum power a user must have before they can update that state key. The only @@ -508,22 +525,24 @@ Joining rooms .. TODO kegan - TODO: What does the home server have to do to join a user to a room? -Users need to join a room in order to send and receive events in that room. A user can join a -room by making a request to |/join/|_ with:: +Users need to join a room in order to send and receive events in that room. A +user can join a room by making a request to |/join/|_ with:: {} -Alternatively, a user can make a request to |/rooms//join|_ with the same request content. -This is only provided for symmetry with the other membership APIs: ``/rooms//invite`` and -``/rooms//leave``. If a room alias was specified, it will be automatically resolved to -a room ID, which will then be joined. The room ID that was joined will be returned in response:: +Alternatively, a user can make a request to |/rooms//join|_ with the +same request content. This is only provided for symmetry with the other +membership APIs: ``/rooms//invite`` and ``/rooms//leave``. If +a room alias was specified, it will be automatically resolved to a room ID, +which will then be joined. The room ID that was joined will be returned in +response:: { "room_id": "!roomid:domain" } -The membership state for the joining user can also be modified directly to be ``join`` -by sending the following request to +The membership state for the joining user can also be modified directly to be +``join`` by sending the following request to ``/rooms//state/m.room.member/``:: { @@ -532,11 +551,12 @@ by sending the following request to See the `Room events`_ section for more information on ``m.room.member``. -After the user has joined a room, they will receive subsequent events in that room. This room -will now appear as an entry in the |initialSync|_ API. +After the user has joined a room, they will receive subsequent events in that +room. This room will now appear as an entry in the |initialSync|_ API. -Some rooms enforce that a user is *invited* to a room before they can join that room. Other -rooms will allow anyone to join the room even if they have not received an invite. +Some rooms enforce that a user is *invited* to a room before they can join that +room. Other rooms will allow anyone to join the room even if they have not +received an invite. Inviting users -------------- @@ -546,20 +566,20 @@ Inviting users - What does the home server have to do? - TODO: In what circumstances will direct member editing NOT be equivalent to ``/invite``? -The purpose of inviting users to a room is to notify them that the room exists -so they can choose to become a member of that room. Some rooms require that all -users who join a room are previously invited to it (an "invite-only" room). -Whether a given room is an "invite-only" room is determined by the room config +The purpose of inviting users to a room is to notify them that the room exists +so they can choose to become a member of that room. Some rooms require that all +users who join a room are previously invited to it (an "invite-only" room). +Whether a given room is an "invite-only" room is determined by the room config key ``TODO``. It can have one of the following values: - TODO Room config invite only value explanation - TODO Room config free-to-join value explanation -Only users who have a membership state of ``join`` in a room can invite new -users to said room. The person being invited must not be in the ``join`` state -in the room. The fully-qualified user ID must be specified when inviting a user, -as the user may reside on a different home server. To invite a user, send the -following request to |/rooms//invite|_, which will manage the +Only users who have a membership state of ``join`` in a room can invite new +users to said room. The person being invited must not be in the ``join`` state +in the room. The fully-qualified user ID must be specified when inviting a +user, as the user may reside on a different home server. To invite a user, send +the following request to |/rooms//invite|_, which will manage the entire invitation process:: { @@ -583,10 +603,11 @@ Leaving rooms - TODO: Under what conditions should a room NOT be purged? -A user can leave a room to stop receiving events for that room. A user must have -joined the room before they are eligible to leave the room. If the room is an -"invite-only" room, they will need to be re-invited before they can re-join the room. -To leave a room, a request should be made to |/rooms//leave|_ with:: +A user can leave a room to stop receiving events for that room. A user must +have joined the room before they are eligible to leave the room. If the room is +an "invite-only" room, they will need to be re-invited before they can re-join +the room. To leave a room, a request should be made to +|/rooms//leave|_ with:: {} @@ -600,33 +621,34 @@ directly by sending the following request to See the `Room events`_ section for more information on ``m.room.member``. -Once a user has left a room, that room will no longer appear on the |initialSync|_ -API. Be aware that leaving a room is not equivalent to have never been -in that room. A user who has previously left a room still maintains some residual state in -that room. Their membership state will be marked as ``leave``. This contrasts with -a user who has *never been invited or joined to that room* who will not have any -membership state for that room. +Once a user has left a room, that room will no longer appear on the +|initialSync|_ API. Be aware that leaving a room is not equivalent to have +never been in that room. A user who has previously left a room still maintains +some residual state in that room. Their membership state will be marked as +``leave``. This contrasts with a user who has *never been invited or joined to +that room* who will not have any membership state for that room. If all members in a room leave, that room becomes eligible for deletion. Banning users in a room ----------------------- -A user may decide to ban another user in a room. 'Banning' forces the target user -to leave the room and prevents them from re-joining the room. A banned user will -not be treated as a joined user, and so will not be able to send or receive events -in the room. In order to ban someone, the user performing the ban MUST have the -required power level. To ban a user, a request should be made to -|/rooms//ban|_ with:: +A user may decide to ban another user in a room. 'Banning' forces the target +user to leave the room and prevents them from re-joining the room. A banned +user will not be treated as a joined user, and so will not be able to send or +receive events in the room. In order to ban someone, the user performing the +ban MUST have the required power level. To ban a user, a request should be made +to |/rooms//ban|_ with:: { "user_id": "" } -Banning a user adjusts the banned member's membership state to ``ban`` and adjusts -the power level of this event to a level higher than the banned person. Like -with other membership changes, a user can directly adjust the target member's -state, by making a request to ``/rooms//state/m.room.member/``:: +Banning a user adjusts the banned member's membership state to ``ban`` and +adjusts the power level of this event to a level higher than the banned person. +Like with other membership changes, a user can directly adjust the target +member's state, by making a request to +``/rooms//state/m.room.member/``:: { "membership": "ban" @@ -637,31 +659,34 @@ Events in a room Room events can be split into two categories: :State Events: - These are events which replace events that came before it, depending on a set of unique keys. - These keys are the event ``type`` and a ``state_key``. Events with the same set of keys will - be overwritten. Typically, state events are used to store state, hence their name. + These are events which replace events that came before it, depending on a set + of unique keys. These keys are the event ``type`` and a ``state_key``. + Events with the same set of keys will be overwritten. Typically, state events + are used to store state, hence their name. :Non-state events: - These are events which cannot be overwritten after sending. The list of events continues - to grow as more events are sent. As this list grows, it becomes necessary to - provide a mechanism for navigating this list. Pagination APIs are used to view the list - of historical non-state events. Typically, non-state events are used to send messages. + These are events which cannot be overwritten after sending. The list of + events continues to grow as more events are sent. As this list grows, it + becomes necessary to provide a mechanism for navigating this list. Pagination + APIs are used to view the list of historical non-state events. Typically, + non-state events are used to send messages. -This specification outlines several events, all with the event type prefix ``m.``. However, -applications may wish to add their own type of event, and this can be achieved using the -REST API detailed in the following sections. If new events are added, the event ``type`` -key SHOULD follow the Java package naming convention, e.g. ``com.example.myapp.event``. -This ensures event types are suitably namespaced for each application and reduces the -risk of clashes. +This specification outlines several events, all with the event type prefix +``m.``. However, applications may wish to add their own type of event, and this +can be achieved using the REST API detailed in the following sections. If new +events are added, the event ``type`` key SHOULD follow the Java package naming +convention, e.g. ``com.example.myapp.event``. This ensures event types are +suitably namespaced for each application and reduces the risk of clashes. State events ------------ -State events can be sent by ``PUT`` ing to |/rooms//state//|_. -These events will be overwritten if ````, ```` and ```` all match. -If the state event has no ``state_key``, it can be omitted from the path. These requests -**cannot use transaction IDs** like other ``PUT`` paths because they cannot be differentiated -from the ``state_key``. Furthermore, ``POST`` is unsupported on state paths. Valid requests -look like:: +State events can be sent by ``PUT`` ing to +|/rooms//state//|_. These events will be +overwritten if ````, ```` and ```` all match. +If the state event has no ``state_key``, it can be omitted from the path. These +requests **cannot use transaction IDs** like other ``PUT`` paths because they +cannot be differentiated from the ``state_key``. Furthermore, ``POST`` is +unsupported on state paths. Valid requests look like:: PUT /rooms/!roomid:domain/state/m.example.event { "key" : "without a state key" } @@ -682,8 +707,8 @@ Care should be taken to avoid setting the wrong ``state key``:: PUT /rooms/!roomid:domain/state/m.another.example.event/11 { "key" : "with '11' as the state key, but was probably intended to be a txnId" } -The ``state_key`` is often used to store state about individual users, by using the user ID as the -``state_key`` value. For example:: +The ``state_key`` is often used to store state about individual users, by using +the user ID as the ``state_key`` value. For example:: PUT /rooms/!roomid:domain/state/m.favorite.animal.event/%40my_user%3Adomain.com { "animal" : "cat", "reason": "fluffy" } @@ -697,10 +722,11 @@ See `Room Events`_ for the ``m.`` event specification. Non-state events ---------------- -Non-state events can be sent by sending a request to |/rooms//send/|_. -These requests *can* use transaction IDs and ``PUT``/``POST`` methods. Non-state events -allow access to historical events and pagination, making it best suited for sending messages. -For example:: +Non-state events can be sent by sending a request to +|/rooms//send/|_. These requests *can* use transaction +IDs and ``PUT``/``POST`` methods. Non-state events allow access to historical +events and pagination, making it best suited for sending messages. For +example:: POST /rooms/!roomid:domain/send/m.custom.example.message { "text": "Hello world!" } @@ -715,16 +741,17 @@ Syncing rooms .. NOTE:: This section is a work in progress. -When a client logs in, they may have a list of rooms which they have already joined. These rooms -may also have a list of events associated with them. The purpose of 'syncing' is to present the -current room and event information in a convenient, compact manner. The events returned are not -limited to room events; presence events will also be returned. There are two APIs provided: +When a client logs in, they may have a list of rooms which they have already +joined. These rooms may also have a list of events associated with them. The +purpose of 'syncing' is to present the current room and event information in a +convenient, compact manner. The events returned are not limited to room events; +presence events will also be returned. There are two APIs provided: - - |initialSync|_ : A global sync which will present room and event information for all rooms - the user has joined. + - |initialSync|_ : A global sync which will present room and event information + for all rooms the user has joined. - - |/rooms//initialSync|_ : A sync scoped to a single room. Presents room and event - information for this room only. + - |/rooms//initialSync|_ : A sync scoped to a single room. Presents + room and event information for this room only. .. TODO kegan - TODO: JSON response format for both types @@ -761,9 +788,9 @@ There are several APIs provided to ``GET`` events for a room: |/rooms//messages|_ Description: - Get all ``m.room.message`` and ``m.room.member`` events. This API supports pagination - using ``from`` and ``to`` query parameters, coupled with the ``start`` and ``end`` - tokens from an |initialSync|_ API. + Get all ``m.room.message`` and ``m.room.member`` events. This API supports + pagination using ``from`` and ``to`` query parameters, coupled with the + ``start`` and ``end`` tokens from an |initialSync|_ API. Response format: ``{ "start": "", "end": "" }`` Example: @@ -800,11 +827,12 @@ prefixed with ``m.`` Example: ``{ "name" : "My Room" }`` Description: - A room has an opaque room ID which is not human-friendly to read. A room alias is - human-friendly, but not all rooms have room aliases. The room name is a human-friendly - string designed to be displayed to the end-user. The room name is not *unique*, as - multiple rooms can have the same room name set. The room name can also be set when - creating a room using |createRoom|_ with the ``name`` key. + A room has an opaque room ID which is not human-friendly to read. A room + alias is human-friendly, but not all rooms have room aliases. The room name + is a human-friendly string designed to be displayed to the end-user. The + room name is not *unique*, as multiple rooms can have the same room name + set. The room name can also be set when creating a room using |createRoom|_ + with the ``name`` key. ``m.room.topic`` Summary: @@ -816,10 +844,11 @@ prefixed with ``m.`` Example: ``{ "topic" : "Welcome to the real world." }`` Description: - A topic is a short message detailing what is currently being discussed in the room. - It can also be used as a way to display extra information about the room, which may - not be suitable for the room name. The room topic can also be set when creating a - room using |createRoom|_ with the ``topic`` key. + A topic is a short message detailing what is currently being discussed in + the room. It can also be used as a way to display extra information about + the room, which may not be suitable for the room name. The room topic can + also be set when creating a room using |createRoom|_ with the ``topic`` + key. ``m.room.member`` Summary: @@ -831,12 +860,12 @@ prefixed with ``m.`` Example: ``{ "membership" : "join" }`` Description: - Adjusts the membership state for a user in a room. It is preferable to use the - membership APIs (``/rooms//invite`` etc) when performing membership actions - rather than adjusting the state directly as there are a restricted set of valid - transformations. For example, user A cannot force user B to join a room, and trying - to force this state change directly will fail. See the `Rooms`_ section for how to - use the membership APIs. + Adjusts the membership state for a user in a room. It is preferable to use + the membership APIs (``/rooms//invite`` etc) when performing + membership actions rather than adjusting the state directly as there are a + restricted set of valid transformations. For example, user A cannot force + user B to join a room, and trying to force this state change directly will + fail. See the `Rooms`_ section for how to use the membership APIs. ``m.room.create`` Summary: @@ -923,7 +952,8 @@ prefixed with ``m.`` ``m.room.aliases`` Summary: - These state events are used to inform the room about what room aliases it has. + These state events are used to inform the room about what room aliases it + has. Type: State event JSON format: @@ -931,11 +961,10 @@ prefixed with ``m.`` Example: ``{ "aliases": ["#foo:example.com"] }`` Description: - A server `may` inform the room that it has added or removed an alias for + A server `may` inform the room that it has added or removed an alias for the room. This is purely for informational purposes and may become stale. Clients `should` check that the room alias is still valid before using it. - The ``state_key`` of the event is the homeserver which owns the room - alias. + The ``state_key`` of the event is the homeserver which owns the room alias. ``m.room.message`` Summary: @@ -947,11 +976,12 @@ prefixed with ``m.`` Example: ``{ "msgtype": "m.text", "body": "Testing" }`` Description: - This event is used when sending messages in a room. Messages are not limited to be text. - The ``msgtype`` key outlines the type of message, e.g. text, audio, image, video, etc. - Whilst not required, the ``body`` key SHOULD be used with every kind of ``msgtype`` as - a fallback mechanism when a client cannot render the message. For more information on - the types of messages which can be sent, see `m.room.message msgtypes`_. + This event is used when sending messages in a room. Messages are not + limited to be text. The ``msgtype`` key outlines the type of message, e.g. + text, audio, image, video, etc. Whilst not required, the ``body`` key + SHOULD be used with every kind of ``msgtype`` as a fallback mechanism when + a client cannot render the message. For more information on the types of + messages which can be sent, see `m.room.message msgtypes`_. ``m.room.message.feedback`` Summary: @@ -963,16 +993,17 @@ prefixed with ``m.`` Example: ``{ "type": "delivered", "target_event_id": "e3b2icys" }`` Description: - Feedback events are events sent to acknowledge a message in some way. There are two - supported acknowledgements: ``delivered`` (sent when the event has been received) and - ``read`` (sent when the event has been observed by the end-user). The ``target_event_id`` - should reference the ``m.room.message`` event being acknowledged. + Feedback events are events sent to acknowledge a message in some way. There + are two supported acknowledgements: ``delivered`` (sent when the event has + been received) and ``read`` (sent when the event has been observed by the + end-user). The ``target_event_id`` should reference the ``m.room.message`` + event being acknowledged. m.room.message msgtypes ----------------------- -Each ``m.room.message`` MUST have a ``msgtype`` key which identifies the type of -message being sent. Each type has their own required and optional keys, as outlined -below: +Each ``m.room.message`` MUST have a ``msgtype`` key which identifies the type +of message being sent. Each type has their own required and optional keys, as +outlined below: ``m.text`` Required keys: @@ -994,12 +1025,12 @@ below: Required keys: - ``url`` : "string" - The URL to the image. Optional keys: - - ``info`` : "string" - info : JSON object (ImageInfo) - The image info for image - referred to in ``url``. + - ``info`` : "string" - info : JSON object (ImageInfo) - The image info for + image referred to in ``url``. - ``thumbnail_url`` : "string" - The URL to the thumbnail. - - ``thumbnail_info`` : JSON object (ImageInfo) - The image info for the image - referred to in ``thumbnail_url``. - - ``body`` : "string" - The alt text of the image, or some kind of content + - ``thumbnail_info`` : JSON object (ImageInfo) - The image info for the + image referred to in ``thumbnail_url``. + - ``body`` : "string" - The alt text of the image, or some kind of content description for accessibility e.g. "image attachment". ImageInfo: @@ -1016,10 +1047,10 @@ below: Required keys: - ``url`` : "string" - The URL to the audio. Optional keys: - - ``info`` : JSON object (AudioInfo) - The audio info for the audio referred to in - ``url``. - - ``body`` : "string" - A description of the audio e.g. "Bee Gees - - Stayin' Alive", or some kind of content description for accessibility e.g. + - ``info`` : JSON object (AudioInfo) - The audio info for the audio + referred to in ``url``. + - ``body`` : "string" - A description of the audio e.g. "Bee Gees - Stayin' + Alive", or some kind of content description for accessibility e.g. "audio attachment". AudioInfo: Information about a piece of audio:: @@ -1034,10 +1065,11 @@ below: Required keys: - ``url`` : "string" - The URL to the video. Optional keys: - - ``info`` : JSON object (VideoInfo) - The video info for the video referred to in - ``url``. - - ``body`` : "string" - A description of the video e.g. "Gangnam style", - or some kind of content description for accessibility e.g. "video attachment". + - ``info`` : JSON object (VideoInfo) - The video info for the video + referred to in ``url``. + - ``body`` : "string" - A description of the video e.g. "Gangnam style", or + some kind of content description for accessibility e.g. "video + attachment". VideoInfo: Information about a video:: @@ -1056,18 +1088,18 @@ below: Required keys: - ``geo_uri`` : "string" - The geo URI representing the location. Optional keys: - - ``thumbnail_url`` : "string" - The URL to a thumnail of the location being - represented. - - ``thumbnail_info`` : JSON object (ImageInfo) - The image info for the image - referred to in ``thumbnail_url``. - - ``body`` : "string" - A description of the location e.g. "Big Ben, - London, UK", or some kind of content description for accessibility e.g. + - ``thumbnail_url`` : "string" - The URL to a thumnail of the location + being represented. + - ``thumbnail_info`` : JSON object (ImageInfo) - The image info for the + image referred to in ``thumbnail_url``. + - ``body`` : "string" - A description of the location e.g. "Big Ben, + London, UK", or some kind of content description for accessibility e.g. "location attachment". The following keys can be attached to any ``m.room.message``: Optional keys: - - ``sender_ts`` : integer - A timestamp (ms resolution) representing the + - ``sender_ts`` : integer - A timestamp (ms resolution) representing the wall-clock time when the message was sent from the client. Presence @@ -1078,20 +1110,22 @@ Presence Each user has the concept of presence information. This encodes the "availability" of that user, suitable for display on other user's clients. This is transmitted as an ``m.presence`` event and is one of the few events which -are sent *outside the context of a room*. The basic piece of presence information -is represented by the ``presence`` key, which is an enum of one of the following: +are sent *outside the context of a room*. The basic piece of presence +information is represented by the ``presence`` key, which is an enum of one of +the following: - - ``online`` : The default state when the user is connected to an event stream. + - ``online`` : The default state when the user is connected to an event + stream. - ``unavailable`` : The user is not reachable at this time. - ``offline`` : The user is not connected to an event stream. - - ``free_for_chat`` : The user is generally willing to receive messages + - ``free_for_chat`` : The user is generally willing to receive messages moreso than default. - - ``hidden`` : TODO. Behaves as offline, but allows the user to see the client - state anyway and generally interact with client features. + - ``hidden`` : TODO. Behaves as offline, but allows the user to see the + client state anyway and generally interact with client features. -This basic ``presence`` field applies to the user as a whole, regardless of how many -client devices they have connected. The home server should synchronise this -status choice among multiple devices to ensure the user gets a consistent +This basic ``presence`` field applies to the user as a whole, regardless of how +many client devices they have connected. The home server should synchronise +this status choice among multiple devices to ensure the user gets a consistent experience. In addition, the server maintains a timestamp of the last time it saw an active @@ -1122,7 +1156,7 @@ Transmission Presence List ------------- Each user's home server stores a "presence list" for that user. This stores a -list of other user IDs the user has chosen to add to it. To be added to this +list of other user IDs the user has chosen to add to it. To be added to this list, the user being added must receive permission from the list owner. Once granted, both user's HS(es) store this information. Since such subscriptions are likely to be bidirectional, HSes may wish to automatically accept requests @@ -1153,9 +1187,9 @@ Typing notifications Voice over IP ============= -Matrix can also be used to set up VoIP calls. This is part of the core specification, -although is still in a very early stage. Voice (and video) over Matrix is based on -the WebRTC standards. +Matrix can also be used to set up VoIP calls. This is part of the core +specification, although is still in a very early stage. Voice (and video) over +Matrix is based on the WebRTC standards. Call events are sent to a room, like any other event. This means that clients must only send call events to rooms with exactly two participants as currently @@ -1170,13 +1204,11 @@ This event is sent by the caller when they wish to establish a call. - ``call_id`` : "string" - A unique identifier for the call - ``offer`` : "offer object" - The session description - ``version`` : "integer" - The version of the VoIP specification this - message adheres to. This specification is - version 0. + message adheres to. This specification is version 0. - ``lifetime`` : "integer" - The time in milliseconds that the invite is - valid for. Once the invite age exceeds this - value, clients should discard it. They - should also no longer show the call as - awaiting an answer in the UI. + valid for. Once the invite age exceeds this value, clients should discard + it. They should also no longer show the call as awaiting an answer in the + UI. Optional keys: None. @@ -1185,48 +1217,54 @@ This event is sent by the caller when they wish to establish a call. ``Offer Object`` Required keys: - - ``type`` : "string" - The type of session description, in this case 'offer' + - ``type`` : "string" - The type of session description, in this case + 'offer' - ``sdp`` : "string" - The SDP text of the session description ``m.call.candidates`` -This event is sent by callers after sending an invite and by the callee after answering. -Its purpose is to give the other party additional ICE candidates to try using to -communicate. +This event is sent by callers after sending an invite and by the callee after +answering. Its purpose is to give the other party additional ICE candidates to +try using to communicate. Required keys: - ``call_id`` : "string" - The ID of the call this event relates to - - ``version`` : "integer" - The version of the VoIP specification this messages - adheres to. his specification is version 0. - - ``candidates`` : "array of candidate objects" - Array of object describing the candidates. + - ``version`` : "integer" - The version of the VoIP specification this + messages adheres to. his specification is version 0. + - ``candidates`` : "array of candidate objects" - Array of object + describing the candidates. ``Candidate Object`` Required Keys: - - ``sdpMid`` : "string" - The SDP media type this candidate is intended for. + - ``sdpMid`` : "string" - The SDP media type this candidate is intended + for. - ``sdpMLineIndex`` : "integer" - The index of the SDP 'm' line this - candidate is intended for + candidate is intended for - ``candidate`` : "string" - The SDP 'a' line of the candidate ``m.call.answer`` Required keys: - ``call_id`` : "string" - The ID of the call this event relates to - - ``version`` : "integer" - The version of the VoIP specification this messages + - ``version`` : "integer" - The version of the VoIP specification this + messages - ``answer`` : "answer object" - Object giving the SDK answer ``Answer Object`` Required keys: - - ``type`` : "string" - The type of session description. 'answer' in this case. + - ``type`` : "string" - The type of session description. 'answer' in this + case. - ``sdp`` : "string" - The SDP text of the session description ``m.call.hangup`` -Sent by either party to signal their termination of the call. This can be sent either once -the call has has been established or before to abort the call. +Sent by either party to signal their termination of the call. This can be sent +either once the call has has been established or before to abort the call. Required keys: - ``call_id`` : "string" - The ID of the call this event relates to - - ``version`` : "integer" - The version of the VoIP specification this messages + - ``version`` : "integer" - The version of the VoIP specification this + messages Message Exchange ---------------- @@ -1272,8 +1310,8 @@ The rules for dealing with such a situation are as follows: - If an invite to a room is received whilst the client is preparing to send an invite to the same room, the client should cancel its outgoing call and instead automatically accept the incoming call on behalf of the user. - - If an invite to a room is received after the client has sent an invite to the - same room and is waiting for a response, the client should perform a + - If an invite to a room is received after the client has sent an invite to + the same room and is waiting for a response, the client should perform a lexicographical comparison of the call IDs of the two calls and use the lesser of the two calls, aborting the greater. If the incoming call is the lesser, the client should accept this call on behalf of the user. @@ -1297,14 +1335,15 @@ Profiles - Display name changes also generates m.room.member with displayname key f.e. room the user is in. -Internally within Matrix users are referred to by their user ID, which is typically -a compact unique identifier. Profiles grant users the ability to see human-readable -names for other users that are in some way meaningful to them. Additionally, -profiles can publish additional information, such as the user's age or location. +Internally within Matrix users are referred to by their user ID, which is +typically a compact unique identifier. Profiles grant users the ability to see +human-readable names for other users that are in some way meaningful to them. +Additionally, profiles can publish additional information, such as the user's +age or location. -A Profile consists of a display name, an avatar picture, and a set of other +A Profile consists of a display name, an avatar picture, and a set of other metadata fields that the user may wish to publish (email address, phone -numbers, website URLs, etc...). This specification puts no requirements on the +numbers, website URLs, etc...). This specification puts no requirements on the display name other than it being a valid unicode string. @@ -1312,20 +1351,20 @@ display name other than it being a valid unicode string. Registration and login ====================== -Clients must register with a home server in order to use Matrix. After +Clients must register with a home server in order to use Matrix. After registering, the client will be given an access token which must be used in ALL requests to that home server as a query parameter 'access_token'. If the client has already registered, they need to be able to login to their -account. The home server may provide many different ways of logging in, such -as user/password auth, login via a social network (OAuth2), login by confirming -a token sent to their email address, etc. This specification does not define how -home servers should authorise their users who want to login to their existing -accounts, but instead defines the standard interface which implementations +account. The home server may provide many different ways of logging in, such as +user/password auth, login via a social network (OAuth2), login by confirming a +token sent to their email address, etc. This specification does not define how +home servers should authorise their users who want to login to their existing +accounts, but instead defines the standard interface which implementations should follow so that ANY client can login to ANY home server. Clients login -using the |login|_ API. Clients register using the |register|_ API. Registration -follows the same procedure as login, but the path requests are sent to are -different. +using the |login|_ API. Clients register using the |register|_ API. +Registration follows the same procedure as login, but the path requests are +sent to are different. The registration/login process breaks down into the following: 1. Determine the requirements for logging in. @@ -1333,13 +1372,14 @@ The registration/login process breaks down into the following: 3. Get credentials or be told the next stage in the login process and repeat step 2. -As each home server may have different ways of logging in, the client needs to know how -they should login. All distinct login stages MUST have a corresponding ``type``. -A ``type`` is a namespaced string which details the mechanism for logging in. +As each home server may have different ways of logging in, the client needs to +know how they should login. All distinct login stages MUST have a corresponding +``type``. A ``type`` is a namespaced string which details the mechanism for +logging in. -A client may be able to login via multiple valid login flows, and should choose a single -flow when logging in. A flow is a series of login stages. The home server MUST respond -with all the valid login flows when requested:: +A client may be able to login via multiple valid login flows, and should choose +a single flow when logging in. A flow is a series of login stages. The home +server MUST respond with all the valid login flows when requested:: The client can login via 3 paths: 1a and 1b, 2a and 2b, or 3. The client should select one of these paths. @@ -1360,21 +1400,21 @@ with all the valid login flows when requested:: ] } -After the login is completed, the client's fully-qualified user ID and a new access -token MUST be returned:: +After the login is completed, the client's fully-qualified user ID and a new +access token MUST be returned:: { "user_id": "@user:matrix.org", "access_token": "abcdef0123456789" } -The ``user_id`` key is particularly useful if the home server wishes to support -localpart entry of usernames (e.g. "user" rather than "@user:matrix.org"), as the -client may not be able to determine its ``user_id`` in this case. +The ``user_id`` key is particularly useful if the home server wishes to support +localpart entry of usernames (e.g. "user" rather than "@user:matrix.org"), as +the client may not be able to determine its ``user_id`` in this case. -If a login has multiple requests, the home server may wish to create a session. If -a home server responds with a 'session' key to a request, clients MUST submit it in -subsequent requests until the login is completed:: +If a login has multiple requests, the home server may wish to create a session. +If a home server responds with a 'session' key to a request, clients MUST +submit it in subsequent requests until the login is completed:: { "session": "" @@ -1402,8 +1442,8 @@ To respond to this type, reply with:: "password": "" } -The home server MUST respond with either new credentials, the next stage of the login -process, or a standard error response. +The home server MUST respond with either new credentials, the next stage of the +login process, or a standard error response. OAuth2-based ------------ @@ -1425,22 +1465,22 @@ The server MUST respond with:: "uri": } -The home server acts as a 'confidential' client for the purposes of OAuth2. -If the uri is a ``sevice selection URI``, it MUST point to a webpage which prompts the -user to choose which service to authorize with. On selection of a service, this -MUST link through to an ``Authorization Request URI``. If there is only 1 service which the -home server accepts when logging in, this indirection can be skipped and the -"uri" key can be the ``Authorization Request URI``. +The home server acts as a 'confidential' client for the purposes of OAuth2. If +the uri is a ``sevice selection URI``, it MUST point to a webpage which prompts +the user to choose which service to authorize with. On selection of a service, +this MUST link through to an ``Authorization Request URI``. If there is only 1 +service which the home server accepts when logging in, this indirection can be +skipped and the "uri" key can be the ``Authorization Request URI``. -The client then visits the ``Authorization Request URI``, which then shows the OAuth2 -Allow/Deny prompt. Hitting 'Allow' returns the ``redirect URI`` with the auth code. -Home servers can choose any path for the ``redirect URI``. The client should visit -the ``redirect URI``, which will then finish the OAuth2 login process, granting the -home server an access token for the chosen service. When the home server gets -this access token, it verifies that the cilent has authorised with the 3rd party, and -can now complete the login. The OAuth2 ``redirect URI`` (with auth code) MUST respond -with either new credentials, the next stage of the login process, or a standard error -response. +The client then visits the ``Authorization Request URI``, which then shows the +OAuth2 Allow/Deny prompt. Hitting 'Allow' returns the ``redirect URI`` with the +auth code. Home servers can choose any path for the ``redirect URI``. The +client should visit the ``redirect URI``, which will then finish the OAuth2 +login process, granting the home server an access token for the chosen service. +When the home server gets this access token, it verifies that the cilent has +authorised with the 3rd party, and can now complete the login. The OAuth2 +``redirect URI`` (with auth code) MUST respond with either new credentials, the +next stage of the login process, or a standard error response. For example, if a home server accepts OAuth2 from Google, it would return the Authorization Request URI for Google:: @@ -1474,15 +1514,16 @@ To respond to this type, reply with:: "email": "" } -After validating the email address, the home server MUST send an email containing -an authentication code and return:: +After validating the email address, the home server MUST send an email +containing an authentication code and return:: { "type": "m.login.email.code", "session": "" } -The second request in this login stage involves sending this authentication code:: +The second request in this login stage involves sending this authentication +code:: { "type": "m.login.email.code", @@ -1490,8 +1531,8 @@ The second request in this login stage involves sending this authentication code "code": "" } -The home server MUST respond to this with either new credentials, the next stage of -the login process, or a standard error response. +The home server MUST respond to this with either new credentials, the next +stage of the login process, or a standard error response. Email-based (url) ----------------- @@ -1509,8 +1550,8 @@ To respond to this type, reply with:: "email": "" } -After validating the email address, the home server MUST send an email containing -an authentication URL and return:: +After validating the email address, the home server MUST send an email +containing an authentication URL and return:: { "type": "m.login.email.url", @@ -1525,12 +1566,12 @@ client should perform another request:: "session": "" } -The home server MUST respond to this with either new credentials, the next stage of -the login process, or a standard error response. +The home server MUST respond to this with either new credentials, the next +stage of the login process, or a standard error response. -A common client implementation will be to periodically poll until the link is clicked. -If the link has not been visited yet, a standard error response with an errcode of -``M_LOGIN_EMAIL_URL_NOT_YET`` should be returned. +A common client implementation will be to periodically poll until the link is +clicked. If the link has not been visited yet, a standard error response with +an errcode of ``M_LOGIN_EMAIL_URL_NOT_YET`` should be returned. Email-based (identity server) @@ -1540,8 +1581,9 @@ Email-based (identity server) :Description: Login is supported by authorising an email address with an identity server. -Prior to submitting this, the client should authenticate with an identity server. -After authenticating, the session information should be submitted to the home server. +Prior to submitting this, the client should authenticate with an identity +server. After authenticating, the session information should be submitted to +the home server. To respond to this type, reply with:: @@ -1560,10 +1602,11 @@ To respond to this type, reply with:: N-Factor Authentication ----------------------- -Multiple login stages can be combined to create N-factor authentication during login. +Multiple login stages can be combined to create N-factor authentication during +login. -This can be achieved by responding with the ``next`` login type on completion of a -previous login stage:: +This can be achieved by responding with the ``next`` login type on completion +of a previous login stage:: { "next": "" @@ -1610,9 +1653,9 @@ This can be represented conceptually as:: Fallback -------- -Clients cannot be expected to be able to know how to process every single -login type. If a client determines it does not know how to handle a given -login type, it should request a login fallback page:: +Clients cannot be expected to be able to know how to process every single login +type. If a client determines it does not know how to handle a given login type, +it should request a login fallback page:: GET matrix/client/api/v1/login/fallback @@ -1629,17 +1672,17 @@ Identity Federation ========== -Federation is the term used to describe how to communicate between Matrix home +Federation is the term used to describe how to communicate between Matrix home servers. Federation is a mechanism by which two home servers can exchange Matrix event messages, both as a real-time push of current events, and as a historic fetching mechanism to synchronise past history for clients to view. It uses HTTPS connections between each pair of servers involved as the underlying -transport. Messages are exchanged between servers in real-time by active pushing -from each server's HTTP client into the server of the other. Queries to fetch -historic data for the purpose of back-filling scrollback buffers and the like -can also be performed. Currently routing of messages between homeservers is full -mesh (like email) - however, fan-out refinements to this design are currently -under consideration. +transport. Messages are exchanged between servers in real-time by active +pushing from each server's HTTP client into the server of the other. Queries to +fetch historic data for the purpose of back-filling scrollback buffers and the +like can also be performed. Currently routing of messages between homeservers +is full mesh (like email) - however, fan-out refinements to this design are +currently under consideration. There are three main kinds of communication that occur between home servers: @@ -1652,8 +1695,8 @@ There are three main kinds of communication that occur between home servers: :Ephemeral Data Units (EDUs): These are notifications of events that are pushed from one home server to - another. They are not persisted and contain no long-term significant history, - nor does the receiving home server have to reply to them. + another. They are not persisted and contain no long-term significant + history, nor does the receiving home server have to reply to them. :Persisted Data Units (PDUs): These are notifications of events that are broadcast from one home server to @@ -1661,8 +1704,9 @@ There are three main kinds of communication that occur between home servers: They are persisted to long-term storage and form the record of history for that context. -EDUs and PDUs are further wrapped in an envelope called a Transaction, which is -transferred from the origin to the destination home server using an HTTP PUT request. +EDUs and PDUs are further wrapped in an envelope called a Transaction, which is +transferred from the origin to the destination home server using an HTTP PUT +request. Transactions @@ -1671,16 +1715,18 @@ Transactions This section may be misleading or inaccurate. The transfer of EDUs and PDUs between home servers is performed by an exchange -of Transaction messages, which are encoded as JSON objects, passed over an -HTTP PUT request. A Transaction is meaningful only to the pair of home servers that +of Transaction messages, which are encoded as JSON objects, passed over an HTTP +PUT request. A Transaction is meaningful only to the pair of home servers that exchanged it; they are not globally-meaningful. Each transaction has: - An opaque transaction ID. - - A timestamp (UNIX epoch time in milliseconds) generated by its origin server. + - A timestamp (UNIX epoch time in milliseconds) generated by its origin + server. - An origin and destination server name. - A list of "previous IDs". - - A list of PDUs and EDUs - the actual message payload that the Transaction carries. + - A list of PDUs and EDUs - the actual message payload that the Transaction + carries. ``origin`` Type: @@ -1719,20 +1765,20 @@ Each transaction has: "edus":[...] } -The ``prev_ids`` field contains a list of previous transaction IDs that -the ``origin`` server has sent to this ``destination``. Its purpose is to act as a +The ``prev_ids`` field contains a list of previous transaction IDs that the +``origin`` server has sent to this ``destination``. Its purpose is to act as a sequence checking mechanism - the destination server can check whether it has successfully received that Transaction, or ask for a retransmission if not. The ``pdus`` field of a transaction is a list, containing zero or more PDUs.[*] -Each PDU is itself a JSON object containing a number of keys, the exact details of -which will vary depending on the type of PDU. Similarly, the ``edus`` field is -another list containing the EDUs. This key may be entirely absent if there are -no EDUs to transfer. +Each PDU is itself a JSON object containing a number of keys, the exact details +of which will vary depending on the type of PDU. Similarly, the ``edus`` field +is another list containing the EDUs. This key may be entirely absent if there +are no EDUs to transfer. (* Normally the PDU list will be non-empty, but the server should cope with -receiving an "empty" transaction, as this is useful for informing peers of other -transaction IDs they should be aware of. This effectively acts as a push +receiving an "empty" transaction, as this is useful for informing peers of +other transaction IDs they should be aware of. This effectively acts as a push mechanism to encourage peers to continue to replicate content.) PDUs and EDUs @@ -1744,8 +1790,8 @@ All PDUs have: - An ID - A context - A declaration of their type - - A list of other PDU IDs that have been seen recently on that context (regardless of which origin - sent them) + - A list of other PDU IDs that have been seen recently on that context + (regardless of which origin sent them) ``context`` Type: @@ -1769,7 +1815,8 @@ All PDUs have: Type: Integer Description: - Timestamp in milliseconds on originating homeserver when this PDU was created. + Timestamp in milliseconds on originating homeserver when this PDU was + created. ``pdu_type`` Type: @@ -1781,7 +1828,7 @@ All PDUs have: Type: List of pairs of strings Description: - The originating homeserver and PDU ids of the most recent PDUs the + The originating homeserver and PDU ids of the most recent PDUs the homeserver was aware of for this context when it made this PDU. ``depth`` @@ -1855,13 +1902,13 @@ For state updates: In contrast to Transactions, it is important to note that the ``prev_pdus`` field of a PDU refers to PDUs that any origin server has sent, rather than -previous IDs that this ``origin`` has sent. This list may refer to other PDUs sent -by the same origin as the current one, or other origins. +previous IDs that this ``origin`` has sent. This list may refer to other PDUs +sent by the same origin as the current one, or other origins. Because of the distributed nature of participants in a Matrix conversation, it is impossible to establish a globally-consistent total ordering on the events. -However, by annotating each outbound PDU at its origin with IDs of other PDUs it -has received, a partial ordering can be constructed allowing causality +However, by annotating each outbound PDU at its origin with IDs of other PDUs +it has received, a partial ordering can be constructed allowing causality relationships to be preserved. A client can then display these messages to the end-user in some order consistent with their content and ensure that no message that is semantically in reply of an earlier one is ever displayed before it. @@ -1934,8 +1981,8 @@ To fetch all the state of a given context:: Response: JSON encoding of a single Transaction containing multiple PDUs Retrieves a snapshot of the entire current state of the given context. The -response will contain a single Transaction, inside which will be a list of -PDUs that encode the state. +response will contain a single Transaction, inside which will be a list of PDUs +that encode the state. To backfill events on a given context:: @@ -1943,11 +1990,10 @@ To backfill events on a given context:: Query args: v, limit Response: JSON encoding of a single Transaction containing multiple PDUs -Retrieves a sliding-window history of previous PDUs that occurred on the -given context. Starting from the PDU ID(s) given in the "v" argument, the -PDUs that preceeded it are retrieved, up to a total number given by the -"limit" argument. These are then returned in a new Transaction containing all -of the PDUs. +Retrieves a sliding-window history of previous PDUs that occurred on the given +context. Starting from the PDU ID(s) given in the "v" argument, the PDUs that +preceeded it are retrieved, up to a total number given by the "limit" argument. +These are then returned in a new Transaction containing all of the PDUs. To stream events all the events:: @@ -2122,9 +2168,9 @@ contents or metadata for messages in that room. Rate limiting ------------- -Home servers SHOULD implement rate limiting to reduce the risk of being overloaded. If a -request is refused due to rate limiting, it should return a standard error response of -the form:: +Home servers SHOULD implement rate limiting to reduce the risk of being +overloaded. If a request is refused due to rate limiting, it should return a +standard error response of the form:: { "errcode": "M_LIMIT_EXCEEDED", @@ -2132,8 +2178,8 @@ the form:: "retry_after_ms": integer (optional) } -The ``retry_after_ms`` key SHOULD be included to tell the client how long they have to wait -in milliseconds before they can try again. +The ``retry_after_ms`` key SHOULD be included to tell the client how long they +have to wait in milliseconds before they can try again. .. TODO - Surely we should recommend an algorithm for the rate limiting, rather than letting every From 3ee9a67aa4d7d22a0756531babfb145ac8859c41 Mon Sep 17 00:00:00 2001 From: "Paul \"LeoNerd\" Evans" Date: Mon, 29 Sep 2014 16:10:16 +0100 Subject: [PATCH 023/106] =?UTF-8?q?Re=C3=B6rder=20the=20specification=20se?= =?UTF-8?q?ctions,=20to=20move=20'Registration=20and=20Login'=20first,=20w?= =?UTF-8?q?here=20it=20logically=20belongs?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/specification.rst | 631 +++++++++++++++++++++-------------------- 1 file changed, 316 insertions(+), 315 deletions(-) diff --git a/docs/specification.rst b/docs/specification.rst index 3686ea8366..e2626078a1 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -260,7 +260,7 @@ For the default HTTP transport, all API calls use a Content-Type of ``application/json``. In addition, all strings MUST be encoded as UTF-8. Clients are authenticated using opaque ``access_token`` strings (see -`Registration and Login`_ for details), passed as a querystring parameter on +`Registration and Login`_ for details), passed as a query string parameter on all requests. .. TODO @@ -375,6 +375,321 @@ When the client first logs in, they will need to initially synchronise with their home server. This is achieved via the |initialSync|_ API. This API also returns an ``end`` token which can be used with the event stream. + +Registration and login +====================== + +Clients must register with a home server in order to use Matrix. After +registering, the client will be given an access token which must be used in ALL +requests to that home server as a query parameter 'access_token'. + +If the client has already registered, they need to be able to login to their +account. The home server may provide many different ways of logging in, such as +user/password auth, login via a social network (OAuth2), login by confirming a +token sent to their email address, etc. This specification does not define how +home servers should authorise their users who want to login to their existing +accounts, but instead defines the standard interface which implementations +should follow so that ANY client can login to ANY home server. Clients login +using the |login|_ API. Clients register using the |register|_ API. +Registration follows the same procedure as login, but the path requests are +sent to are different. + +The registration/login process breaks down into the following: + 1. Determine the requirements for logging in. + 2. Submit the login stage credentials. + 3. Get credentials or be told the next stage in the login process and repeat + step 2. + +As each home server may have different ways of logging in, the client needs to +know how they should login. All distinct login stages MUST have a corresponding +``type``. A ``type`` is a namespaced string which details the mechanism for +logging in. + +A client may be able to login via multiple valid login flows, and should choose +a single flow when logging in. A flow is a series of login stages. The home +server MUST respond with all the valid login flows when requested:: + + The client can login via 3 paths: 1a and 1b, 2a and 2b, or 3. The client should + select one of these paths. + + { + "flows": [ + { + "type": "", + "stages": [ "", "" ] + }, + { + "type": "", + "stages": [ "", "" ] + }, + { + "type": "" + } + ] + } + +After the login is completed, the client's fully-qualified user ID and a new +access token MUST be returned:: + + { + "user_id": "@user:matrix.org", + "access_token": "abcdef0123456789" + } + +The ``user_id`` key is particularly useful if the home server wishes to support +localpart entry of usernames (e.g. "user" rather than "@user:matrix.org"), as +the client may not be able to determine its ``user_id`` in this case. + +If a login has multiple requests, the home server may wish to create a session. +If a home server responds with a 'session' key to a request, clients MUST +submit it in subsequent requests until the login is completed:: + + { + "session": "" + } + +This specification defines the following login types: + - ``m.login.password`` + - ``m.login.oauth2`` + - ``m.login.email.code`` + - ``m.login.email.url`` + - ``m.login.email.identity`` + +Password-based +-------------- +:Type: + ``m.login.password`` +:Description: + Login is supported via a username and password. + +To respond to this type, reply with:: + + { + "type": "m.login.password", + "user": "", + "password": "" + } + +The home server MUST respond with either new credentials, the next stage of the +login process, or a standard error response. + +OAuth2-based +------------ +:Type: + ``m.login.oauth2`` +:Description: + Login is supported via OAuth2 URLs. This login consists of multiple requests. + +To respond to this type, reply with:: + + { + "type": "m.login.oauth2", + "user": "" + } + +The server MUST respond with:: + + { + "uri": + } + +The home server acts as a 'confidential' client for the purposes of OAuth2. If +the uri is a ``sevice selection URI``, it MUST point to a webpage which prompts +the user to choose which service to authorize with. On selection of a service, +this MUST link through to an ``Authorization Request URI``. If there is only 1 +service which the home server accepts when logging in, this indirection can be +skipped and the "uri" key can be the ``Authorization Request URI``. + +The client then visits the ``Authorization Request URI``, which then shows the +OAuth2 Allow/Deny prompt. Hitting 'Allow' returns the ``redirect URI`` with the +auth code. Home servers can choose any path for the ``redirect URI``. The +client should visit the ``redirect URI``, which will then finish the OAuth2 +login process, granting the home server an access token for the chosen service. +When the home server gets this access token, it verifies that the cilent has +authorised with the 3rd party, and can now complete the login. The OAuth2 +``redirect URI`` (with auth code) MUST respond with either new credentials, the +next stage of the login process, or a standard error response. + +For example, if a home server accepts OAuth2 from Google, it would return the +Authorization Request URI for Google:: + + { + "uri": "https://accounts.google.com/o/oauth2/auth?response_type=code& + client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=photos" + } + +The client then visits this URI and authorizes the home server. The client then +visits the REDIRECT_URI with the auth code= query parameter which returns:: + + { + "user_id": "@user:matrix.org", + "access_token": "0123456789abcdef" + } + +Email-based (code) +------------------ +:Type: + ``m.login.email.code`` +:Description: + Login is supported by typing in a code which is sent in an email. This login + consists of multiple requests. + +To respond to this type, reply with:: + + { + "type": "m.login.email.code", + "user": "", + "email": "" + } + +After validating the email address, the home server MUST send an email +containing an authentication code and return:: + + { + "type": "m.login.email.code", + "session": "" + } + +The second request in this login stage involves sending this authentication +code:: + + { + "type": "m.login.email.code", + "session": "", + "code": "" + } + +The home server MUST respond to this with either new credentials, the next +stage of the login process, or a standard error response. + +Email-based (url) +----------------- +:Type: + ``m.login.email.url`` +:Description: + Login is supported by clicking on a URL in an email. This login consists of + multiple requests. + +To respond to this type, reply with:: + + { + "type": "m.login.email.url", + "user": "", + "email": "" + } + +After validating the email address, the home server MUST send an email +containing an authentication URL and return:: + + { + "type": "m.login.email.url", + "session": "" + } + +The email contains a URL which must be clicked. After it has been clicked, the +client should perform another request:: + + { + "type": "m.login.email.url", + "session": "" + } + +The home server MUST respond to this with either new credentials, the next +stage of the login process, or a standard error response. + +A common client implementation will be to periodically poll until the link is +clicked. If the link has not been visited yet, a standard error response with +an errcode of ``M_LOGIN_EMAIL_URL_NOT_YET`` should be returned. + + +Email-based (identity server) +----------------------------- +:Type: + ``m.login.email.identity`` +:Description: + Login is supported by authorising an email address with an identity server. + +Prior to submitting this, the client should authenticate with an identity +server. After authenticating, the session information should be submitted to +the home server. + +To respond to this type, reply with:: + + { + "type": "m.login.email.identity", + "threepidCreds": [ + { + "sid": "", + "clientSecret": "", + "idServer": "" + } + ] + } + + + +N-Factor Authentication +----------------------- +Multiple login stages can be combined to create N-factor authentication during +login. + +This can be achieved by responding with the ``next`` login type on completion +of a previous login stage:: + + { + "next": "" + } + +If a home server implements N-factor authentication, it MUST respond with all +``stages`` when initially queried for their login requirements:: + + { + "type": "<1st login type>", + "stages": [ <1st login type>, <2nd login type>, ... , ] + } + +This can be represented conceptually as:: + + _______________________ + | Login Stage 1 | + | type: "" | + | ___________________ | + | |_Request_1_________| | <-- Returns "session" key which is used throughout. + | ___________________ | + | |_Request_2_________| | <-- Returns a "next" value of "login type2" + |_______________________| + | + | + _________V_____________ + | Login Stage 2 | + | type: "" | + | ___________________ | + | |_Request_1_________| | + | ___________________ | + | |_Request_2_________| | + | ___________________ | + | |_Request_3_________| | <-- Returns a "next" value of "login type3" + |_______________________| + | + | + _________V_____________ + | Login Stage 3 | + | type: "" | + | ___________________ | + | |_Request_1_________| | <-- Returns user credentials + |_______________________| + +Fallback +-------- +Clients cannot be expected to be able to know how to process every single login +type. If a client determines it does not know how to handle a given login type, +it should request a login fallback page:: + + GET matrix/client/api/v1/login/fallback + +This MUST return an HTML page which can perform the entire login process. + + Rooms ===== @@ -1347,320 +1662,6 @@ numbers, website URLs, etc...). This specification puts no requirements on the display name other than it being a valid unicode string. - -Registration and login -====================== - -Clients must register with a home server in order to use Matrix. After -registering, the client will be given an access token which must be used in ALL -requests to that home server as a query parameter 'access_token'. - -If the client has already registered, they need to be able to login to their -account. The home server may provide many different ways of logging in, such as -user/password auth, login via a social network (OAuth2), login by confirming a -token sent to their email address, etc. This specification does not define how -home servers should authorise their users who want to login to their existing -accounts, but instead defines the standard interface which implementations -should follow so that ANY client can login to ANY home server. Clients login -using the |login|_ API. Clients register using the |register|_ API. -Registration follows the same procedure as login, but the path requests are -sent to are different. - -The registration/login process breaks down into the following: - 1. Determine the requirements for logging in. - 2. Submit the login stage credentials. - 3. Get credentials or be told the next stage in the login process and repeat - step 2. - -As each home server may have different ways of logging in, the client needs to -know how they should login. All distinct login stages MUST have a corresponding -``type``. A ``type`` is a namespaced string which details the mechanism for -logging in. - -A client may be able to login via multiple valid login flows, and should choose -a single flow when logging in. A flow is a series of login stages. The home -server MUST respond with all the valid login flows when requested:: - - The client can login via 3 paths: 1a and 1b, 2a and 2b, or 3. The client should - select one of these paths. - - { - "flows": [ - { - "type": "", - "stages": [ "", "" ] - }, - { - "type": "", - "stages": [ "", "" ] - }, - { - "type": "" - } - ] - } - -After the login is completed, the client's fully-qualified user ID and a new -access token MUST be returned:: - - { - "user_id": "@user:matrix.org", - "access_token": "abcdef0123456789" - } - -The ``user_id`` key is particularly useful if the home server wishes to support -localpart entry of usernames (e.g. "user" rather than "@user:matrix.org"), as -the client may not be able to determine its ``user_id`` in this case. - -If a login has multiple requests, the home server may wish to create a session. -If a home server responds with a 'session' key to a request, clients MUST -submit it in subsequent requests until the login is completed:: - - { - "session": "" - } - -This specification defines the following login types: - - ``m.login.password`` - - ``m.login.oauth2`` - - ``m.login.email.code`` - - ``m.login.email.url`` - - ``m.login.email.identity`` - -Password-based --------------- -:Type: - ``m.login.password`` -:Description: - Login is supported via a username and password. - -To respond to this type, reply with:: - - { - "type": "m.login.password", - "user": "", - "password": "" - } - -The home server MUST respond with either new credentials, the next stage of the -login process, or a standard error response. - -OAuth2-based ------------- -:Type: - ``m.login.oauth2`` -:Description: - Login is supported via OAuth2 URLs. This login consists of multiple requests. - -To respond to this type, reply with:: - - { - "type": "m.login.oauth2", - "user": "" - } - -The server MUST respond with:: - - { - "uri": - } - -The home server acts as a 'confidential' client for the purposes of OAuth2. If -the uri is a ``sevice selection URI``, it MUST point to a webpage which prompts -the user to choose which service to authorize with. On selection of a service, -this MUST link through to an ``Authorization Request URI``. If there is only 1 -service which the home server accepts when logging in, this indirection can be -skipped and the "uri" key can be the ``Authorization Request URI``. - -The client then visits the ``Authorization Request URI``, which then shows the -OAuth2 Allow/Deny prompt. Hitting 'Allow' returns the ``redirect URI`` with the -auth code. Home servers can choose any path for the ``redirect URI``. The -client should visit the ``redirect URI``, which will then finish the OAuth2 -login process, granting the home server an access token for the chosen service. -When the home server gets this access token, it verifies that the cilent has -authorised with the 3rd party, and can now complete the login. The OAuth2 -``redirect URI`` (with auth code) MUST respond with either new credentials, the -next stage of the login process, or a standard error response. - -For example, if a home server accepts OAuth2 from Google, it would return the -Authorization Request URI for Google:: - - { - "uri": "https://accounts.google.com/o/oauth2/auth?response_type=code& - client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=photos" - } - -The client then visits this URI and authorizes the home server. The client then -visits the REDIRECT_URI with the auth code= query parameter which returns:: - - { - "user_id": "@user:matrix.org", - "access_token": "0123456789abcdef" - } - -Email-based (code) ------------------- -:Type: - ``m.login.email.code`` -:Description: - Login is supported by typing in a code which is sent in an email. This login - consists of multiple requests. - -To respond to this type, reply with:: - - { - "type": "m.login.email.code", - "user": "", - "email": "" - } - -After validating the email address, the home server MUST send an email -containing an authentication code and return:: - - { - "type": "m.login.email.code", - "session": "" - } - -The second request in this login stage involves sending this authentication -code:: - - { - "type": "m.login.email.code", - "session": "", - "code": "" - } - -The home server MUST respond to this with either new credentials, the next -stage of the login process, or a standard error response. - -Email-based (url) ------------------ -:Type: - ``m.login.email.url`` -:Description: - Login is supported by clicking on a URL in an email. This login consists of - multiple requests. - -To respond to this type, reply with:: - - { - "type": "m.login.email.url", - "user": "", - "email": "" - } - -After validating the email address, the home server MUST send an email -containing an authentication URL and return:: - - { - "type": "m.login.email.url", - "session": "" - } - -The email contains a URL which must be clicked. After it has been clicked, the -client should perform another request:: - - { - "type": "m.login.email.url", - "session": "" - } - -The home server MUST respond to this with either new credentials, the next -stage of the login process, or a standard error response. - -A common client implementation will be to periodically poll until the link is -clicked. If the link has not been visited yet, a standard error response with -an errcode of ``M_LOGIN_EMAIL_URL_NOT_YET`` should be returned. - - -Email-based (identity server) ------------------------------ -:Type: - ``m.login.email.identity`` -:Description: - Login is supported by authorising an email address with an identity server. - -Prior to submitting this, the client should authenticate with an identity -server. After authenticating, the session information should be submitted to -the home server. - -To respond to this type, reply with:: - - { - "type": "m.login.email.identity", - "threepidCreds": [ - { - "sid": "", - "clientSecret": "", - "idServer": "" - } - ] - } - - - -N-Factor Authentication ------------------------ -Multiple login stages can be combined to create N-factor authentication during -login. - -This can be achieved by responding with the ``next`` login type on completion -of a previous login stage:: - - { - "next": "" - } - -If a home server implements N-factor authentication, it MUST respond with all -``stages`` when initially queried for their login requirements:: - - { - "type": "<1st login type>", - "stages": [ <1st login type>, <2nd login type>, ... , ] - } - -This can be represented conceptually as:: - - _______________________ - | Login Stage 1 | - | type: "" | - | ___________________ | - | |_Request_1_________| | <-- Returns "session" key which is used throughout. - | ___________________ | - | |_Request_2_________| | <-- Returns a "next" value of "login type2" - |_______________________| - | - | - _________V_____________ - | Login Stage 2 | - | type: "" | - | ___________________ | - | |_Request_1_________| | - | ___________________ | - | |_Request_2_________| | - | ___________________ | - | |_Request_3_________| | <-- Returns a "next" value of "login type3" - |_______________________| - | - | - _________V_____________ - | Login Stage 3 | - | type: "" | - | ___________________ | - | |_Request_1_________| | <-- Returns user credentials - |_______________________| - -Fallback --------- -Clients cannot be expected to be able to know how to process every single login -type. If a client determines it does not know how to handle a given login type, -it should request a login fallback page:: - - GET matrix/client/api/v1/login/fallback - -This MUST return an HTML page which can perform the entire login process. - Identity ======== .. NOTE:: From 2d61dbc77481a9baa31c72e62caa4c5f038e6b75 Mon Sep 17 00:00:00 2001 From: "Paul \"LeoNerd\" Evans" Date: Mon, 29 Sep 2014 18:35:56 +0100 Subject: [PATCH 024/106] Extended docs about the registration/login flows --- docs/specification.rst | 51 ++++++++++++++++++++++++------------------ 1 file changed, 29 insertions(+), 22 deletions(-) diff --git a/docs/specification.rst b/docs/specification.rst index e2626078a1..e9e9296073 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -376,7 +376,7 @@ their home server. This is achieved via the |initialSync|_ API. This API also returns an ``end`` token which can be used with the event stream. -Registration and login +Registration and Login ====================== Clients must register with a home server in order to use Matrix. After @@ -391,27 +391,29 @@ home servers should authorise their users who want to login to their existing accounts, but instead defines the standard interface which implementations should follow so that ANY client can login to ANY home server. Clients login using the |login|_ API. Clients register using the |register|_ API. -Registration follows the same procedure as login, but the path requests are -sent to are different. +Registration follows the same general procedure as login, but the path requests +are sent to and the details contained in them are different. -The registration/login process breaks down into the following: - 1. Determine the requirements for logging in. - 2. Submit the login stage credentials. - 3. Get credentials or be told the next stage in the login process and repeat - step 2. - -As each home server may have different ways of logging in, the client needs to -know how they should login. All distinct login stages MUST have a corresponding -``type``. A ``type`` is a namespaced string which details the mechanism for -logging in. +In both registration and login cases, the process takes the form of one or more +stages, where at each stage the client submits a set of data for a given stage +type and awaits a response from the server, which will either be a final +success or a request to perform an additional stage. This exchange continues +until the final success. + +In order to determine up-front what the server's requirements are, the client +can request from the server a complete description of all of its acceptable +flows of the registration or login process. It can then inspect the list of +returned flows looking for one for which it believes it can complete all of the +required stages, and perform it. As each home server may have different ways of +logging in, the client needs to know how they should login. All distinct login +stages MUST have a corresponding ``type``. A ``type`` is a namespaced string +which details the mechanism for logging in. A client may be able to login via multiple valid login flows, and should choose a single flow when logging in. A flow is a series of login stages. The home -server MUST respond with all the valid login flows when requested:: +server MUST respond with all the valid login flows when requested by a simple +``GET`` request directly to the ``/login`` or ``/register`` paths:: - The client can login via 3 paths: 1a and 1b, 2a and 2b, or 3. The client should - select one of these paths. - { "flows": [ { @@ -428,8 +430,12 @@ server MUST respond with all the valid login flows when requested:: ] } -After the login is completed, the client's fully-qualified user ID and a new -access token MUST be returned:: +The client can now select which flow it wishes to use, and begin making +``POST`` requests to the ``/login`` or ``/register`` paths with JSON body +content containing the name of the stage as the ``type`` key, along with +whatever additional parameters are required for that login or registration type +(see below). After the flow is completed, the client's fully-qualified user +ID and a new access token MUST be returned:: { "user_id": "@user:matrix.org", @@ -440,9 +446,10 @@ The ``user_id`` key is particularly useful if the home server wishes to support localpart entry of usernames (e.g. "user" rather than "@user:matrix.org"), as the client may not be able to determine its ``user_id`` in this case. -If a login has multiple requests, the home server may wish to create a session. -If a home server responds with a 'session' key to a request, clients MUST -submit it in subsequent requests until the login is completed:: +If the flow has multiple stages to it, the home server may wish to create a +session to store context between requests. If a home server responds with a +``session`` key to a request, clients MUST submit it in subsequent requests +until the flow is completed:: { "session": "" From 1f76377a7ce4a8b782462a9a819e504df7c46ce0 Mon Sep 17 00:00:00 2001 From: "Paul \"LeoNerd\" Evans" Date: Mon, 29 Sep 2014 18:40:15 +0100 Subject: [PATCH 025/106] Re-wrap content after latest additions --- docs/specification.rst | 55 +++++++++++++++++++++++------------------- 1 file changed, 30 insertions(+), 25 deletions(-) diff --git a/docs/specification.rst b/docs/specification.rst index 23b6bed764..07c57f9dda 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -78,9 +78,10 @@ The functionality that Matrix provides includes: + Mapping of 3PIDs to Matrix IDs The end goal of Matrix is to be a ubiquitous messaging layer for synchronising -arbitrary data between sets of people, devices and services - be that for instant -messages, VoIP call setups, or any other objects that need to be reliably and -persistently pushed from A to B in an interoperable and federated manner. +arbitrary data between sets of people, devices and services - be that for +instant messages, VoIP call setups, or any other objects that need to be +reliably and persistently pushed from A to B in an interoperable and federated +manner. Architecture @@ -1120,8 +1121,8 @@ There are several APIs provided to ``GET`` events for a room: |/rooms//initialSync|_ Description: - Get all relevant events for a room. This includes state events, paginated non-state - events and presence events. + Get all relevant events for a room. This includes state events, paginated + non-state events and presence events. Response format: `` { TODO } `` Example: @@ -1129,20 +1130,22 @@ There are several APIs provided to ``GET`` events for a room: Redactions ---------- -Since events are extensible it is possible for malicious users and/or servers to add -keys that are, for example offensive or illegal. Since some events cannot be simply -deleted, e.g. membership events, we instead 'redact' events. This involves removing -all keys from an event that are not required by the protocol. This stripped down -event is thereafter returned anytime a client or remote server requests it. +Since events are extensible it is possible for malicious users and/or servers +to add keys that are, for example offensive or illegal. Since some events +cannot be simply deleted, e.g. membership events, we instead 'redact' events. +This involves removing all keys from an event that are not required by the +protocol. This stripped down event is thereafter returned anytime a client or +remote server requests it. -Events that have been redacted include a ``redacted_because`` key whose value is the -event that caused it to be redacted, which may include a reason. +Events that have been redacted include a ``redacted_because`` key whose value +is the event that caused it to be redacted, which may include a reason. -Redacting an event cannot be undone, allowing server owners to delete the offending -content from the databases. +Redacting an event cannot be undone, allowing server owners to delete the +offending content from the databases. -Currently, only room admins can redact events by sending a ``m.room.redacted`` event, -but server admins also need to be able to redact events by a similar mechanism. +Currently, only room admins can redact events by sending a ``m.room.redacted`` +event, but server admins also need to be able to redact events by a similar +mechanism. Room Events @@ -1346,13 +1349,15 @@ prefixed with ``m.`` JSON format: ``{ "reason": "string" }`` Description: - Events can be redacted by either room or server admins. Redacting an event means that - all keys not required by the protocol are stripped off, allowing admins to remove - offensive or illegal content that may have been attached to any event. This cannot be - undone, allowing server owners to physically delete the offending data. - There is also a concept of a moderator hiding a non-state event, which can be undone, - but cannot be applied to state events. - The event that has been redacted is specified in the ``redacts`` event level key. + Events can be redacted by either room or server admins. Redacting an event + means that all keys not required by the protocol are stripped off, allowing + admins to remove offensive or illegal content that may have been attached + to any event. This cannot be undone, allowing server owners to physically + delete the offending data. There is also a concept of a moderator hiding a + non-state event, which can be undone, but cannot be applied to state + events. + The event that has been redacted is specified in the ``redacts`` event + level key. m.room.message msgtypes ----------------------- @@ -1731,8 +1736,8 @@ There are three main kinds of communication that occur between home servers: These are single request/response interactions between a given pair of servers, initiated by one side sending an HTTPS GET request to obtain some information, and responded by the other. They are not persisted and contain - no long-term significant history. They simply request a snapshot state at the - instant the query is made. + no long-term significant history. They simply request a snapshot state at + the instant the query is made. :Ephemeral Data Units (EDUs): These are notifications of events that are pushed from one home server to From e06adc6d7e645e5116c28d2b5756a70bb8f4f240 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Tue, 30 Sep 2014 11:31:22 +0100 Subject: [PATCH 026/106] SYN-2: Allow server admins to delete room aliases --- synapse/handlers/directory.py | 45 +++++++++++++++++++++------------ synapse/rest/directory.py | 20 ++++++++++++++- synapse/storage/directory.py | 30 ++++++++++++++++++++++ tests/storage/test_directory.py | 25 +++++++++++++++--- 4 files changed, 99 insertions(+), 21 deletions(-) diff --git a/synapse/handlers/directory.py b/synapse/handlers/directory.py index 4ab00a761a..84c3a1d56f 100644 --- a/synapse/handlers/directory.py +++ b/synapse/handlers/directory.py @@ -57,7 +57,6 @@ class DirectoryHandler(BaseHandler): if not servers: raise SynapseError(400, "Failed to get server list") - try: yield self.store.create_room_alias_association( room_alias, @@ -68,25 +67,19 @@ class DirectoryHandler(BaseHandler): defer.returnValue("Already exists") # TODO: Send the room event. + yield self._update_room_alias_events(user_id, room_id) - aliases = yield self.store.get_aliases_for_room(room_id) + @defer.inlineCallbacks + def delete_association(self, user_id, room_alias): + # TODO Check if server admin - event = self.event_factory.create_event( - etype=RoomAliasesEvent.TYPE, - state_key=self.hs.hostname, - room_id=room_id, - user_id=user_id, - content={"aliases": aliases}, - ) + if not room_alias.is_mine: + raise SynapseError(400, "Room alias must be local") - snapshot = yield self.store.snapshot_room( - room_id=room_id, - user_id=user_id, - ) - - yield self.state_handler.handle_new_event(event, snapshot) - yield self._on_new_room_event(event, snapshot, extra_users=[user_id]) + room_id = yield self.store.delete_room_alias(room_alias) + if room_id: + yield self._update_room_alias_events(user_id, room_id) @defer.inlineCallbacks def get_association(self, room_alias): @@ -142,3 +135,23 @@ class DirectoryHandler(BaseHandler): "room_id": result.room_id, "servers": result.servers, }) + + @defer.inlineCallbacks + def _update_room_alias_events(self, user_id, room_id): + aliases = yield self.store.get_aliases_for_room(room_id) + + event = self.event_factory.create_event( + etype=RoomAliasesEvent.TYPE, + state_key=self.hs.hostname, + room_id=room_id, + user_id=user_id, + content={"aliases": aliases}, + ) + + snapshot = yield self.store.snapshot_room( + room_id=room_id, + user_id=user_id, + ) + + yield self.state_handler.handle_new_event(event, snapshot) + yield self._on_new_room_event(event, snapshot, extra_users=[user_id]) diff --git a/synapse/rest/directory.py b/synapse/rest/directory.py index 31849246a1..6c260e7102 100644 --- a/synapse/rest/directory.py +++ b/synapse/rest/directory.py @@ -16,7 +16,7 @@ from twisted.internet import defer -from synapse.api.errors import SynapseError, Codes +from synapse.api.errors import AuthError, SynapseError, Codes from base import RestServlet, client_path_pattern import json @@ -81,6 +81,24 @@ class ClientDirectoryServer(RestServlet): defer.returnValue((200, {})) + @defer.inlineCallbacks + def on_DELETE(self, request, room_alias): + user = yield self.auth.get_user_by_req(request) + + is_admin = yield self.auth.is_server_admin(user) + if not is_admin: + raise AuthError(403, "You need to be a server admin") + + dir_handler = self.handlers.directory_handler + + room_alias = self.hs.parse_roomalias(urllib.unquote(room_alias)) + + yield dir_handler.delete_association( + user.to_string(), room_alias + ) + + defer.returnValue((200, {})) + def _parse_json(request): try: diff --git a/synapse/storage/directory.py b/synapse/storage/directory.py index 540eb4c2c4..52373a28a6 100644 --- a/synapse/storage/directory.py +++ b/synapse/storage/directory.py @@ -93,6 +93,36 @@ class DirectoryStore(SQLBaseStore): } ) + def delete_room_alias(self, room_alias): + return self.runInteraction( + self._delete_room_alias_txn, + room_alias, + ) + + def _delete_room_alias_txn(self, txn, room_alias): + cursor = txn.execute( + "SELECT room_id FROM room_aliases WHERE room_alias = ?", + (room_alias.to_string(),) + ) + + res = cursor.fetchone() + if res: + room_id = res[0] + else: + return None + + txn.execute( + "DELETE FROM room_aliases WHERE room_alias = ?", + (room_alias.to_string(),) + ) + + txn.execute( + "DELETE FROM room_alias_servers WHERE room_alias = ?", + (room_alias.to_string(),) + ) + + return room_id + def get_aliases_for_room(self, room_id): return self._simple_select_onecol( "room_aliases", diff --git a/tests/storage/test_directory.py b/tests/storage/test_directory.py index 7e8e7e1e83..e9c242cc07 100644 --- a/tests/storage/test_directory.py +++ b/tests/storage/test_directory.py @@ -30,7 +30,8 @@ class DirectoryStoreTestCase(unittest.TestCase): db_pool = SQLiteMemoryDbPool() yield db_pool.prepare() - hs = HomeServer("test", + hs = HomeServer( + "test", db_pool=db_pool, ) @@ -60,9 +61,25 @@ class DirectoryStoreTestCase(unittest.TestCase): servers=["test"], ) - self.assertObjectHasAttributes( - {"room_id": self.room.to_string(), - "servers": ["test"]}, + { + "room_id": self.room.to_string(), + "servers": ["test"], + }, + (yield self.store.get_association_from_room_alias(self.alias)) + ) + + @defer.inlineCallbacks + def test_delete_alias(self): + yield self.store.create_room_alias_association( + room_alias=self.alias, + room_id=self.room.to_string(), + servers=["test"], + ) + + room_id = yield self.store.delete_room_alias(self.alias) + self.assertEqual(self.room.to_string(), room_id) + + self.assertIsNone( (yield self.store.get_association_from_room_alias(self.alias)) ) From fbf6320614e23f7181e9b7d2a2ba6df0791343bb Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Tue, 30 Sep 2014 12:38:38 +0100 Subject: [PATCH 027/106] pyflakes cleanup --- synapse/config/repository.py | 1 - synapse/storage/__init__.py | 2 +- synapse/storage/roommember.py | 1 - 3 files changed, 1 insertion(+), 3 deletions(-) diff --git a/synapse/config/repository.py b/synapse/config/repository.py index 407c8d6c24..b71d30227c 100644 --- a/synapse/config/repository.py +++ b/synapse/config/repository.py @@ -14,7 +14,6 @@ # limitations under the License. from ._base import Config -import os class ContentRepositoryConfig(Config): def __init__(self, args): diff --git a/synapse/storage/__init__.py b/synapse/storage/__init__.py index 1ebbeab2e7..32d9c1392b 100644 --- a/synapse/storage/__init__.py +++ b/synapse/storage/__init__.py @@ -105,7 +105,7 @@ class DataStore(RoomMemberStore, RoomStore, stream_ordering=stream_ordering, is_new_state=is_new_state, ) - except _RollbackButIsFineException as e: + except _RollbackButIsFineException: pass @defer.inlineCallbacks diff --git a/synapse/storage/roommember.py b/synapse/storage/roommember.py index 958e730591..ceeef5880e 100644 --- a/synapse/storage/roommember.py +++ b/synapse/storage/roommember.py @@ -18,7 +18,6 @@ from twisted.internet import defer from ._base import SQLBaseStore from synapse.api.constants import Membership -from synapse.util.logutils import log_function import logging From b95a178584cac07018f47e571f48993878da7284 Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Tue, 30 Sep 2014 15:15:10 +0100 Subject: [PATCH 028/106] SYN-75 Verify signatures on server to server transactions --- synapse/crypto/keyclient.py | 75 +++++++---------- synapse/crypto/keyring.py | 125 ++++++++++++++++++++++++++++ synapse/crypto/keyserver.py | 111 ------------------------ synapse/crypto/resource/__init__.py | 15 ---- synapse/federation/replication.py | 24 +++--- synapse/federation/transport.py | 22 ++--- synapse/federation/units.py | 3 - synapse/server.py | 5 ++ synapse/storage/__init__.py | 1 + synapse/storage/keys.py | 75 ++++++++++------- synapse/storage/schema/keys.sql | 13 +-- tests/federation/test_federation.py | 1 + tests/handlers/test_presence.py | 9 +- tests/handlers/test_typing.py | 1 + 14 files changed, 245 insertions(+), 235 deletions(-) create mode 100644 synapse/crypto/keyring.py delete mode 100644 synapse/crypto/keyserver.py delete mode 100644 synapse/crypto/resource/__init__.py diff --git a/synapse/crypto/keyclient.py b/synapse/crypto/keyclient.py index c11df5c529..c26f16a038 100644 --- a/synapse/crypto/keyclient.py +++ b/synapse/crypto/keyclient.py @@ -15,9 +15,10 @@ from twisted.web.http import HTTPClient +from twisted.internet.protocol import Factory from twisted.internet import defer, reactor -from twisted.internet.protocol import ClientFactory -from twisted.names.srvconnect import SRVConnector +from twisted.internet.endpoints import connectProtocol +from synapse.http.endpoint import matrix_endpoint import json import logging @@ -30,15 +31,19 @@ def fetch_server_key(server_name, ssl_context_factory): """Fetch the keys for a remote server.""" factory = SynapseKeyClientFactory() + endpoint = matrix_endpoint( + reactor, server_name, ssl_context_factory, timeout=30 + ) - SRVConnector( - reactor, "matrix", server_name, factory, - protocol="tcp", connectFuncName="connectSSL", defaultPort=443, - connectFuncKwArgs=dict(contextFactory=ssl_context_factory)).connect() - - server_key, server_certificate = yield factory.remote_key - - defer.returnValue((server_key, server_certificate)) + for i in range(5): + try: + protocol = yield endpoint.connect(factory) + server_response, server_certificate = yield protocol.remote_key + defer.returnValue((server_response, server_certificate)) + return + except Exception as e: + logger.exception(e) + raise IOError("Cannot get key for " % server_name) class SynapseKeyClientError(Exception): @@ -51,69 +56,47 @@ class SynapseKeyClientProtocol(HTTPClient): the server and extracts the X.509 certificate for the remote peer from the SSL connection.""" + timeout = 30 + + def __init__(self): + self.remote_key = defer.Deferred() + def connectionMade(self): logger.debug("Connected to %s", self.transport.getHost()) - self.sendCommand(b"GET", b"/key") + self.sendCommand(b"GET", b"/_matrix/key/v1/") self.endHeaders() self.timer = reactor.callLater( - self.factory.timeout_seconds, + self.timeout, self.on_timeout ) def handleStatus(self, version, status, message): if status != b"200": - logger.info("Non-200 response from %s: %s %s", - self.transport.getHost(), status, message) + #logger.info("Non-200 response from %s: %s %s", + # self.transport.getHost(), status, message) self.transport.abortConnection() def handleResponse(self, response_body_bytes): try: json_response = json.loads(response_body_bytes) except ValueError: - logger.info("Invalid JSON response from %s", - self.transport.getHost()) + #logger.info("Invalid JSON response from %s", + # self.transport.getHost()) self.transport.abortConnection() return certificate = self.transport.getPeerCertificate() - self.factory.on_remote_key((json_response, certificate)) + self.remote_key.callback((json_response, certificate)) self.transport.abortConnection() self.timer.cancel() def on_timeout(self): logger.debug("Timeout waiting for response from %s", self.transport.getHost()) + self.on_remote_key.errback(IOError("Timeout waiting for response")) self.transport.abortConnection() -class SynapseKeyClientFactory(ClientFactory): +class SynapseKeyClientFactory(Factory): protocol = SynapseKeyClientProtocol - max_retries = 5 - timeout_seconds = 30 - def __init__(self): - self.succeeded = False - self.retries = 0 - self.remote_key = defer.Deferred() - - def on_remote_key(self, key): - self.succeeded = True - self.remote_key.callback(key) - - def retry_connection(self, connector): - self.retries += 1 - if self.retries < self.max_retries: - connector.connector = None - connector.connect() - else: - self.remote_key.errback( - SynapseKeyClientError("Max retries exceeded")) - - def clientConnectionFailed(self, connector, reason): - logger.info("Connection failed %s", reason) - self.retry_connection(connector) - - def clientConnectionLost(self, connector, reason): - logger.info("Connection lost %s", reason) - if not self.succeeded: - self.retry_connection(connector) diff --git a/synapse/crypto/keyring.py b/synapse/crypto/keyring.py new file mode 100644 index 0000000000..ce19c69bd5 --- /dev/null +++ b/synapse/crypto/keyring.py @@ -0,0 +1,125 @@ +# -*- coding: utf-8 -*- +# Copyright 2014 OpenMarket Ltd +# +# Licensed under the Apache License, Version 2.0 (the "License"); +# you may not use this file except in compliance with the License. +# You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. + +from synapse.crypto.keyclient import fetch_server_key +from twisted.internet import defer +from syutil.crypto.jsonsign import verify_signed_json, signature_ids +from syutil.crypto.signing_key import ( + is_signing_algorithm_supported, decode_verify_key_bytes +) +from syutil.base64util import decode_base64, encode_base64 + +from OpenSSL import crypto + +import logging + + +logger = logging.getLogger(__name__) + + +class Keyring(object): + def __init__(self, hs): + self.store = hs.get_datastore() + self.clock = hs.get_clock() + self.hs = hs + + @defer.inlineCallbacks + def verify_json_for_server(self, server_name, json_object): + key_ids = signature_ids(json_object, server_name) + verify_key = yield self.get_server_verify_key(server_name, key_ids) + verify_signed_json(json_object, server_name, verify_key) + + @defer.inlineCallbacks + def get_server_verify_key(self, server_name, key_ids): + """Finds a verification key for the server with one of the key ids. + Args: + server_name (str): The name of the server to fetch a key for. + keys_ids (list of str): The key_ids to check for. + """ + + # Check the datastore to see if we have one cached. + cached = yield self.store.get_server_verify_keys(server_name, key_ids) + + if cached: + defer.returnValue(cached[0]) + return + + # Try to fetch the key from the remote server. + # TODO(markjh): Ratelimit requests to a given server. + + (response, tls_certificate) = yield fetch_server_key( + server_name, self.hs.tls_context_factory + ) + + # Check the response. + + x509_certificate_bytes = crypto.dump_certificate( + crypto.FILETYPE_ASN1, tls_certificate + ) + + if ("signatures" not in response + or server_name not in response["signatures"]): + raise ValueError("Key response not signed by remote server") + + if "tls_certificate" not in response: + raise ValueError("Key response missing TLS certificate") + + tls_certificate_b64 = response["tls_certificate"] + + if encode_base64(x509_certificate_bytes) != tls_certificate_b64: + raise ValueError("TLS certificate doesn't match") + + verify_keys = {} + for key_id, key_base64 in response["verify_keys"].items(): + if is_signing_algorithm_supported(key_id): + key_bytes = decode_base64(key_base64) + verify_key = decode_verify_key_bytes(key_id, key_bytes) + verify_keys[key_id] = verify_key + + for key_id in response["signatures"][server_name]: + if key_id not in response["verify_keys"]: + raise ValueError( + "Key response must include verification keys for all" + " signatures" + ) + if key_id in verify_keys: + verify_signed_json( + response, + server_name, + verify_keys[key_id] + ) + + # Cache the result in the datastore. + + time_now_ms = self.clock.time_msec() + + self.store.store_server_certificate( + server_name, + server_name, + time_now_ms, + tls_certificate, + ) + + for key_id, key in verify_keys.items(): + self.store.store_server_verify_key( + server_name, server_name, time_now_ms, key + ) + + for key_id in key_ids: + if key_id in verify_keys: + defer.returnValue(verify_keys[key_id]) + return + + raise ValueError("No verification key found for given key ids") diff --git a/synapse/crypto/keyserver.py b/synapse/crypto/keyserver.py deleted file mode 100644 index a23484dbae..0000000000 --- a/synapse/crypto/keyserver.py +++ /dev/null @@ -1,111 +0,0 @@ -# -*- coding: utf-8 -*- -# Copyright 2014 OpenMarket Ltd -# -# Licensed under the Apache License, Version 2.0 (the "License"); -# you may not use this file except in compliance with the License. -# You may obtain a copy of the License at -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, -# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -# See the License for the specific language governing permissions and -# limitations under the License. - - -from twisted.internet import reactor, ssl -from twisted.web import server -from twisted.web.resource import Resource -from twisted.python.log import PythonLoggingObserver - -from synapse.crypto.resource.key import LocalKey -from synapse.crypto.config import load_config - -from syutil.base64util import decode_base64 - -from OpenSSL import crypto, SSL - -import logging -import nacl.signing -import sys - - -class KeyServerSSLContextFactory(ssl.ContextFactory): - """Factory for PyOpenSSL SSL contexts that are used to handle incoming - connections and to make connections to remote servers.""" - - def __init__(self, key_server): - self._context = SSL.Context(SSL.SSLv23_METHOD) - self.configure_context(self._context, key_server) - - @staticmethod - def configure_context(context, key_server): - context.set_options(SSL.OP_NO_SSLv2 | SSL.OP_NO_SSLv3) - context.use_certificate(key_server.tls_certificate) - context.use_privatekey(key_server.tls_private_key) - context.load_tmp_dh(key_server.tls_dh_params_path) - context.set_cipher_list("!ADH:HIGH+kEDH:!AECDH:HIGH+kEECDH") - - def getContext(self): - return self._context - - -class KeyServer(object): - """An HTTPS server serving LocalKey and RemoteKey resources.""" - - def __init__(self, server_name, tls_certificate_path, tls_private_key_path, - tls_dh_params_path, signing_key_path, bind_host, bind_port): - self.server_name = server_name - self.tls_certificate = self.read_tls_certificate(tls_certificate_path) - self.tls_private_key = self.read_tls_private_key(tls_private_key_path) - self.tls_dh_params_path = tls_dh_params_path - self.signing_key = self.read_signing_key(signing_key_path) - self.bind_host = bind_host - self.bind_port = int(bind_port) - self.ssl_context_factory = KeyServerSSLContextFactory(self) - - @staticmethod - def read_tls_certificate(cert_path): - with open(cert_path) as cert_file: - cert_pem = cert_file.read() - return crypto.load_certificate(crypto.FILETYPE_PEM, cert_pem) - - @staticmethod - def read_tls_private_key(private_key_path): - with open(private_key_path) as private_key_file: - private_key_pem = private_key_file.read() - return crypto.load_privatekey(crypto.FILETYPE_PEM, private_key_pem) - - @staticmethod - def read_signing_key(signing_key_path): - with open(signing_key_path) as signing_key_file: - signing_key_b64 = signing_key_file.read() - signing_key_bytes = decode_base64(signing_key_b64) - return nacl.signing.SigningKey(signing_key_bytes) - - def run(self): - root = Resource() - root.putChild("key", LocalKey(self)) - site = server.Site(root) - reactor.listenSSL( - self.bind_port, - site, - self.ssl_context_factory, - interface=self.bind_host - ) - - logging.basicConfig(level=logging.DEBUG) - observer = PythonLoggingObserver() - observer.start() - - reactor.run() - - -def main(): - key_server = KeyServer(**load_config(__doc__, sys.argv[1:])) - key_server.run() - - -if __name__ == "__main__": - main() diff --git a/synapse/crypto/resource/__init__.py b/synapse/crypto/resource/__init__.py deleted file mode 100644 index 9bff9ec169..0000000000 --- a/synapse/crypto/resource/__init__.py +++ /dev/null @@ -1,15 +0,0 @@ -# -*- coding: utf-8 -*- -# Copyright 2014 OpenMarket Ltd -# -# Licensed under the Apache License, Version 2.0 (the "License"); -# you may not use this file except in compliance with the License. -# You may obtain a copy of the License at -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, -# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -# See the License for the specific language governing permissions and -# limitations under the License. - diff --git a/synapse/federation/replication.py b/synapse/federation/replication.py index 84977e7e57..a8dd038b0b 100644 --- a/synapse/federation/replication.py +++ b/synapse/federation/replication.py @@ -66,6 +66,8 @@ class ReplicationLayer(object): hs, self.transaction_actions, transport_layer ) + self.keyring = hs.get_keyring() + self.handler = None self.edu_handlers = {} self.query_handlers = {} @@ -291,6 +293,10 @@ class ReplicationLayer(object): @defer.inlineCallbacks @log_function def on_incoming_transaction(self, transaction_data): + yield self.keyring.verify_json_for_server( + transaction_data["origin"], transaction_data + ) + transaction = Transaction(**transaction_data) for p in transaction.pdus: @@ -590,7 +596,7 @@ class _TransactionQueue(object): transaction = Transaction.create_new( ts=self._clock.time_msec(), - transaction_id=self._next_txn_id, + transaction_id=str(self._next_txn_id), origin=self.server_name, destination=destination, pdus=pdus, @@ -611,20 +617,18 @@ class _TransactionQueue(object): # FIXME (erikj): This is a bit of a hack to make the Pdu age # keys work - def cb(transaction): + def json_data_cb(): + data = transaction.get_dict() now = int(self._clock.time_msec()) - if "pdus" in transaction: - for p in transaction["pdus"]: + if "pdus" in data: + for p in data["pdus"]: if "age_ts" in p: p["age"] = now - int(p["age_ts"]) - - transaction = sign_json(transaction, server_name, signing_key) - - return transaction + data = sign_json(data, server_name, signing_key) + return data code, response = yield self.transport_layer.send_transaction( - transaction, - on_send_callback=cb, + transaction, json_data_cb ) logger.debug("TX [%s] Sent transaction", destination) diff --git a/synapse/federation/transport.py b/synapse/federation/transport.py index afc777ec9e..5d595b7433 100644 --- a/synapse/federation/transport.py +++ b/synapse/federation/transport.py @@ -144,7 +144,7 @@ class TransportLayer(object): @defer.inlineCallbacks @log_function - def send_transaction(self, transaction, on_send_callback=None): + def send_transaction(self, transaction, json_data_callback=None): """ Sends the given Transaction to it's destination Args: @@ -163,24 +163,26 @@ class TransportLayer(object): if transaction.destination == self.server_name: raise RuntimeError("Transport layer cannot send to itself!") - data = transaction.get_dict() + if json_data_callback is None: + def json_data_callback(): + return transaction.get_dict() # FIXME (erikj): This is a bit of a hack to make the Pdu age # keys work def cb(destination, method, path_bytes, producer): - if not on_send_callback: - return + json_data = json_data_callback() + del json_data["destination"] + del json_data["transaction_id"] + producer.reset(json_data) - transaction = json.loads(producer.body) - - new_transaction = on_send_callback(transaction) - - producer.reset(new_transaction) + json_data = transaction.get_dict() + del json_data["destination"] + del json_data["transaction_id"] code, response = yield self.client.put_json( transaction.destination, path=PREFIX + "/send/%s/" % transaction.transaction_id, - data=data, + data=json_data, on_send_callback=cb, ) diff --git a/synapse/federation/units.py b/synapse/federation/units.py index 622fe66a8f..1ca123d1bf 100644 --- a/synapse/federation/units.py +++ b/synapse/federation/units.py @@ -186,9 +186,6 @@ class Transaction(JsonEncodedObject): "previous_ids", "pdus", "edus", - ] - - internal_keys = [ "transaction_id", "destination", ] diff --git a/synapse/server.py b/synapse/server.py index 529500d595..ed5b810d3e 100644 --- a/synapse/server.py +++ b/synapse/server.py @@ -34,6 +34,7 @@ from synapse.util.distributor import Distributor from synapse.util.lockutils import LockManager from synapse.streams.events import EventSources from synapse.api.ratelimiting import Ratelimiter +from synapse.crypto.keyring import Keyring class BaseHomeServer(object): @@ -78,6 +79,7 @@ class BaseHomeServer(object): 'resource_for_server_key', 'event_sources', 'ratelimiter', + 'keyring', ] def __init__(self, hostname, **kwargs): @@ -201,6 +203,9 @@ class HomeServer(BaseHomeServer): def build_ratelimiter(self): return Ratelimiter() + def build_keyring(self): + return Keyring(self) + def register_servlets(self): """ Register all servlets associated with this HomeServer. """ diff --git a/synapse/storage/__init__.py b/synapse/storage/__init__.py index 66658f6721..ef98b6a444 100644 --- a/synapse/storage/__init__.py +++ b/synapse/storage/__init__.py @@ -56,6 +56,7 @@ SCHEMAS = [ "presence", "im", "room_aliases", + "keys", ] diff --git a/synapse/storage/keys.py b/synapse/storage/keys.py index 5a38c3e8f2..253dc17be2 100644 --- a/synapse/storage/keys.py +++ b/synapse/storage/keys.py @@ -18,7 +18,8 @@ from _base import SQLBaseStore from twisted.internet import defer import OpenSSL -import nacl.signing +from syutil.crypto.signing_key import decode_verify_key_bytes +import hashlib class KeyStore(SQLBaseStore): """Persistence for signature verification keys and tls X.509 certificates @@ -42,62 +43,74 @@ class KeyStore(SQLBaseStore): ) defer.returnValue(tls_certificate) - def store_server_certificate(self, server_name, key_server, ts_now_ms, + def store_server_certificate(self, server_name, from_server, time_now_ms, tls_certificate): """Stores the TLS X.509 certificate for the given server Args: - server_name (bytes): The name of the server. - key_server (bytes): Where the certificate was looked up - ts_now_ms (int): The time now in milliseconds + server_name (str): The name of the server. + from_server (str): Where the certificate was looked up + time_now_ms (int): The time now in milliseconds tls_certificate (OpenSSL.crypto.X509): The X.509 certificate. """ tls_certificate_bytes = OpenSSL.crypto.dump_certificate( OpenSSL.crypto.FILETYPE_ASN1, tls_certificate ) + fingerprint = hashlib.sha256(tls_certificate_bytes).hexdigest() return self._simple_insert( table="server_tls_certificates", - keyvalues={ + values={ "server_name": server_name, - "key_server": key_server, - "ts_added_ms": ts_now_ms, - "tls_certificate": tls_certificate_bytes, + "fingerprint": fingerprint, + "from_server": from_server, + "ts_added_ms": time_now_ms, + "tls_certificate": buffer(tls_certificate_bytes), }, ) @defer.inlineCallbacks - def get_server_verification_key(self, server_name): - """Retrieve the NACL verification key for a given server + def get_server_verify_keys(self, server_name, key_ids): + """Retrieve the NACL verification key for a given server for the given + key_ids Args: - server_name (bytes): The name of the server. + server_name (str): The name of the server. + key_ids (list of str): List of key_ids to try and look up. Returns: - (nacl.signing.VerifyKey): The verification key. + (list of VerifyKey): The verification keys. """ - verification_key_bytes, = yield self._simple_select_one( - table="server_signature_keys", - key_values={"server_name": server_name}, - retcols=("tls_certificate",), + sql = ( + "SELECT key_id, verify_key FROM server_signature_keys" + " WHERE server_name = ?" + " AND key_id in (" + ",".join("?" for key_id in key_ids) + ")" ) - verification_key = nacl.signing.VerifyKey(verification_key_bytes) - defer.returnValue(verification_key) - def store_server_verification_key(self, server_name, key_version, - key_server, ts_now_ms, verification_key): + rows = yield self._execute_and_decode(sql, server_name, *key_ids) + + keys = [] + for row in rows: + key_id = row["key_id"] + key_bytes = row["verify_key"] + key = decode_verify_key_bytes(key_id, str(key_bytes)) + keys.append(key) + defer.returnValue(keys) + + def store_server_verify_key(self, server_name, from_server, time_now_ms, + verify_key): """Stores a NACL verification key for the given server. Args: - server_name (bytes): The name of the server. - key_version (bytes): The version of the key for the server. - key_server (bytes): Where the verification key was looked up + server_name (str): The name of the server. + key_id (str): The version of the key for the server. + from_server (str): Where the verification key was looked up ts_now_ms (int): The time now in milliseconds - verification_key (nacl.signing.VerifyKey): The NACL verify key. + verification_key (VerifyKey): The NACL verify key. """ - verification_key_bytes = verification_key.encode() + verify_key_bytes = verify_key.encode() return self._simple_insert( table="server_signature_keys", - key_values={ + values={ "server_name": server_name, - "key_version": key_version, - "key_server": key_server, - "ts_added_ms": ts_now_ms, - "verification_key": verification_key_bytes, + "key_id": "%s:%s" % (verify_key.alg, verify_key.version), + "from_server": from_server, + "ts_added_ms": time_now_ms, + "verify_key": buffer(verify_key.encode()), }, ) diff --git a/synapse/storage/schema/keys.sql b/synapse/storage/schema/keys.sql index 706a1a03ff..9bf2068d84 100644 --- a/synapse/storage/schema/keys.sql +++ b/synapse/storage/schema/keys.sql @@ -14,17 +14,18 @@ */ CREATE TABLE IF NOT EXISTS server_tls_certificates( server_name TEXT, -- Server name. - key_server TEXT, -- Which key server the certificate was fetched from. + fingerprint TEXT, -- Certificate fingerprint. + from_server TEXT, -- Which key server the certificate was fetched from. ts_added_ms INTEGER, -- When the certifcate was added. tls_certificate BLOB, -- DER encoded x509 certificate. - CONSTRAINT uniqueness UNIQUE (server_name) + CONSTRAINT uniqueness UNIQUE (server_name, fingerprint) ); CREATE TABLE IF NOT EXISTS server_signature_keys( server_name TEXT, -- Server name. - key_version TEXT, -- Key version. - key_server TEXT, -- Which key server the key was fetched form. + key_id TEXT, -- Key version. + from_server TEXT, -- Which key server the key was fetched form. ts_added_ms INTEGER, -- When the key was added. - verification_key BLOB, -- NACL verification key. - CONSTRAINT uniqueness UNIQUE (server_name, key_version) + verify_key BLOB, -- NACL verification key. + CONSTRAINT uniqueness UNIQUE (server_name, key_id) ); diff --git a/tests/federation/test_federation.py b/tests/federation/test_federation.py index eafc7879e0..c893c4863d 100644 --- a/tests/federation/test_federation.py +++ b/tests/federation/test_federation.py @@ -74,6 +74,7 @@ class FederationTestCase(unittest.TestCase): datastore=self.mock_persistence, clock=self.clock, config=self.mock_config, + keyring=Mock(), ) self.federation = initialize_http_replication(hs) self.distributor = hs.get_distributor() diff --git a/tests/handlers/test_presence.py b/tests/handlers/test_presence.py index fe4b892ffb..c9406b70c4 100644 --- a/tests/handlers/test_presence.py +++ b/tests/handlers/test_presence.py @@ -17,7 +17,7 @@ from tests import unittest from twisted.internet import defer, reactor -from mock import Mock, call, ANY, NonCallableMock +from mock import Mock, call, ANY, NonCallableMock, patch import json from tests.utils import ( @@ -59,7 +59,6 @@ class JustPresenceHandlers(object): def __init__(self, hs): self.presence_handler = PresenceHandler(hs) - class PresenceStateTestCase(unittest.TestCase): """ Tests presence management. """ @@ -78,6 +77,7 @@ class PresenceStateTestCase(unittest.TestCase): resource_for_federation=Mock(), http_client=None, config=self.mock_config, + keyring=Mock(), ) hs.handlers = JustPresenceHandlers(hs) @@ -230,6 +230,7 @@ class PresenceInvitesTestCase(unittest.TestCase): resource_for_federation=self.mock_federation_resource, http_client=self.mock_http_client, config=self.mock_config, + keyring=Mock(), ) hs.handlers = JustPresenceHandlers(hs) @@ -533,6 +534,7 @@ class PresencePushTestCase(unittest.TestCase): resource_for_federation=self.mock_federation_resource, http_client=self.mock_http_client, config=self.mock_config, + keyring=Mock(), ) hs.handlers = JustPresenceHandlers(hs) @@ -1025,7 +1027,8 @@ class PresencePollingTestCase(unittest.TestCase): resource_for_client=Mock(), resource_for_federation=self.mock_federation_resource, http_client=self.mock_http_client, - config = self.mock_config, + config=self.mock_config, + keyring=Mock(), ) hs.handlers = JustPresenceHandlers(hs) diff --git a/tests/handlers/test_typing.py b/tests/handlers/test_typing.py index 0ab829b9ad..ff40343b8c 100644 --- a/tests/handlers/test_typing.py +++ b/tests/handlers/test_typing.py @@ -79,6 +79,7 @@ class TypingNotificationsTestCase(unittest.TestCase): resource_for_federation=self.mock_federation_resource, http_client=self.mock_http_client, config=self.mock_config, + keyring=Mock(), ) hs.handlers = JustTypingNotificationHandlers(hs) From 392dc8af59e333ad90bd598a6ab355a5e6bd14bf Mon Sep 17 00:00:00 2001 From: "Paul \"LeoNerd\" Evans" Date: Tue, 30 Sep 2014 18:11:24 +0100 Subject: [PATCH 029/106] Annotate all the 'TODO' marks as relating to either the specification itself or the documentation thereof --- docs/specification.rst | 104 +++++++++++++++++++++-------------------- 1 file changed, 54 insertions(+), 50 deletions(-) diff --git a/docs/specification.rst b/docs/specification.rst index 07c57f9dda..6dcdea3060 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -118,7 +118,7 @@ the account and looks like:: The ``localpart`` of a user ID may be a user name, or an opaque ID identifying this user. They are case-insensitive. -.. TODO +.. TODO-spec - Need to specify precise grammar for Matrix IDs A "Home Server" is a server which provides C-S APIs and has the ability to @@ -366,7 +366,7 @@ events which are visible to the client will appear in the event stream. When the request returns, an ``end`` token is included in the response. This token can be used in the next request to continue where the client left off. -.. TODO +.. TODO-spec How do we filter the event stream? Do we ever return multiple events in a single request? Don't we get lots of request setup RTT latency if we only do one event per request? Do we ever support streaming @@ -704,7 +704,7 @@ Rooms Creation -------- .. TODO kegan - - TODO: Key for invite these users? + - TODO-spec: Key for invite these users? To create a room, a client has to use the |createRoom|_ API. There are various options which can be set when creating a room: @@ -799,7 +799,7 @@ Modifying aliases .. NOTE:: This section is a work in progress. -.. TODO kegan +.. TODO-doc kegan - path to edit aliases - PUT /directory/room/ { room_id : foo } - GET /directory/room/ { room_id : foo, servers: [a.com, b.com] } @@ -811,11 +811,11 @@ Permissions .. NOTE:: This section is a work in progress. -.. TODO kegan - - TODO: What is a power level? How do they work? Defaults / required levels for X. How do they change +.. TODO-doc kegan + - What is a power level? How do they work? Defaults / required levels for X. How do they change as people join and leave rooms? What do you do if you get a clash? Examples. - - TODO: List all actions which use power levels (sending msgs, inviting users, banning people, etc...) - - TODO: Room config - what is the event and what are the keys/values and explanations for them. + - List all actions which use power levels (sending msgs, inviting users, banning people, etc...) + - Room config - what is the event and what are the keys/values and explanations for them. Link through to respective sections where necessary. How does this tie in with permissions, e.g. give example of creating a read-only room. @@ -845,7 +845,7 @@ defined in the following state events: Joining rooms ------------- -.. TODO kegan +.. TODO-doc kegan - TODO: What does the home server have to do to join a user to a room? Users need to join a room in order to send and receive events in that room. A @@ -883,7 +883,7 @@ received an invite. Inviting users -------------- -.. TODO kegan +.. TODO-doc kegan - Can invite users to a room if the room config key TODO is set to TODO. Must have required power level. - Outline invite join dance. What is it? Why is it required? How does it work? - What does the home server have to do? @@ -921,7 +921,7 @@ See the `Room events`_ section for more information on ``m.room.member``. Leaving rooms ------------- -.. TODO kegan +.. TODO-spec kegan - TODO: Grace period before deletion? - TODO: Under what conditions should a room NOT be purged? @@ -1076,7 +1076,7 @@ presence events will also be returned. There are two APIs provided: - |/rooms//initialSync|_ : A sync scoped to a single room. Presents room and event information for this room only. -.. TODO kegan +.. TODO-doc kegan - TODO: JSON response format for both types - TODO: when would you use global? when would you use scoped? @@ -1098,7 +1098,7 @@ There are several APIs provided to ``GET`` events for a room: Response format: ``[ { state event }, { state event }, ... ]`` Example: - TODO + TODO-doc |/rooms//members|_ @@ -1107,7 +1107,7 @@ There are several APIs provided to ``GET`` events for a room: Response format: ``{ "start": "", "end": "", "chunk": [ { m.room.member event }, ... ] }`` Example: - TODO + TODO-doc |/rooms//messages|_ Description: @@ -1117,16 +1117,16 @@ There are several APIs provided to ``GET`` events for a room: Response format: ``{ "start": "", "end": "" }`` Example: - TODO + TODO-doc |/rooms//initialSync|_ Description: Get all relevant events for a room. This includes state events, paginated non-state events and presence events. Response format: - `` { TODO } `` + `` { TODO-doc } `` Example: - TODO + TODO-doc Redactions ---------- @@ -1153,7 +1153,7 @@ Room Events .. NOTE:: This section is a work in progress. -.. TODO dave? +.. TODO-doc dave? - voip events? This specification outlines several standard event types, all of which are @@ -1232,7 +1232,7 @@ prefixed with ``m.`` Example: ``{ "join_rule": "public" }`` Description: - TODO : Use docs/models/rooms.rst + TODO-doc : Use docs/models/rooms.rst ``m.room.power_levels`` Summary: @@ -1480,8 +1480,9 @@ the following: - ``offline`` : The user is not connected to an event stream. - ``free_for_chat`` : The user is generally willing to receive messages moreso than default. - - ``hidden`` : TODO. Behaves as offline, but allows the user to see the - client state anyway and generally interact with client features. + - ``hidden`` : Behaves as offline, but allows the user to see the client + state anyway and generally interact with client features. (Not yet + implemented in synapse). This basic ``presence`` field applies to the user as a whole, regardless of how many client devices they have connected. The home server should synchronise @@ -1509,7 +1510,7 @@ Transmission .. NOTE:: This section is a work in progress. -.. TODO: +.. TODO-doc: - Transmitted as an EDU. - Presence lists determine who to send to. @@ -1534,17 +1535,23 @@ user, either: In the latter case, this allows for clients to display some minimal sense of presence information in a user list for a room. + Typing notifications ==================== .. NOTE:: This section is a work in progress. -.. TODO Leo +.. TODO-doc Leo - what is the event type. Are they bundled with other event types? If so, which. - what are the valid keys / values. What do they represent. Any gotchas? - Timeouts. How do they work, who sets them and how do they expire. Does one have priority over another? Give examples. +.. TODO-spec Leo + - actually define the client-server API; the only thing that currently + exists is entirely server-server + + Voice over IP ============= Matrix can also be used to set up VoIP calls. This is part of the core @@ -1681,12 +1688,13 @@ a call and the other party had accepted. Thusly, any media stream that had been setup for use on a call should be transferred and used for the call that replaces it. + Profiles ======== .. NOTE:: This section is a work in progress. -.. TODO +.. TODO-doc - Metadata extensibility - Changing profile info generates m.presence events ("presencelike") - keys on m.presence are optional, except presence which is required @@ -1712,9 +1720,10 @@ Identity .. NOTE:: This section is a work in progress. -.. TODO Dave +.. TODO-doc Dave - 3PIDs and identity server, functions + Federation ========== @@ -1884,10 +1893,9 @@ All PDUs have: The maximum depth of the previous PDUs plus one. -.. TODO paul - [[TODO(paul): Update this structure so that 'pdu_id' is a two-element - [origin,ref] pair like the prev_pdus are]] - +.. TODO-spec paul + - Update this structure so that 'pdu_id' is a two-element [origin,ref] pair + like the prev_pdus are For state updates: @@ -1967,18 +1975,10 @@ keys exist to support this: {..., "is_state":true, - "state_key":TODO - "power_level":TODO - "prev_state_id":TODO - "prev_state_origin":TODO} - -.. TODO paul - [[TODO(paul): At this point we should probably have a long description of how - State management works, with descriptions of clobbering rules, power levels, etc - etc... But some of that detail is rather up-in-the-air, on the whiteboard, and - so on. This part needs refining. And writing in its own document as the details - relate to the server/system as a whole, not specifically to server-server - federation.]] + "state_key":TODO-doc + "power_level":TODO-doc + "prev_state_id":TODO-doc + "prev_state_origin":TODO-doc} EDUs, by comparison to PDUs, do not have an ID, a context, or a list of "previous" IDs. The only mandatory fields for these are the type, origin and @@ -2005,7 +2005,7 @@ For active pushing of messages representing live activity "as it happens":: PUT .../send/:transaction_id/ Body: JSON encoding of a single Transaction - Response: TODO + Response: TODO-doc The transaction_id path argument will override any ID given in the JSON body. The destination name will be set to that of the receiving server itself. Each @@ -2068,7 +2068,7 @@ Backfilling .. NOTE:: This section is a work in progress. -.. TODO +.. TODO-doc - What it is, when is it used, how is it done SRV Records @@ -2076,9 +2076,10 @@ SRV Records .. NOTE:: This section is a work in progress. -.. TODO +.. TODO-doc - Why it is needed + Security ======== @@ -2119,7 +2120,7 @@ victim would then include in their view of the chatroom history. Other servers in the chatroom would reject the invalid messages and potentially reject the victims messages as well since they depended on the invalid messages. -.. TODO +.. TODO-spec Track trustworthiness of HS or users based on if they try to pretend they haven't seen recent events, and fake a splitbrain... --M @@ -2227,7 +2228,7 @@ standard error response of the form:: The ``retry_after_ms`` key SHOULD be included to tell the client how long they have to wait in milliseconds before they can try again. -.. TODO +.. TODO-spec - Surely we should recommend an algorithm for the rate limiting, rather than letting every homeserver come up with their own idea, causing totally unpredictable performance over federated rooms? @@ -2236,30 +2237,33 @@ have to wait in milliseconds before they can try again. - Lawful intercept + Key Escrow TODO Mark + Policy Servers ============== .. NOTE:: This section is a work in progress. -.. TODO +.. TODO-spec We should mention them in the Architecture section at least... - + + Content repository ================== .. NOTE:: This section is a work in progress. -.. TODO +.. TODO-spec - path to upload - format for thumbnail paths, mention what it is protecting against. - content size limit and associated M_ERROR. + Address book repository ======================= .. NOTE:: This section is a work in progress. -.. TODO +.. TODO-spec - format: POST(?) wodges of json, some possible processing, then return wodges of json on GET. - processing may remove dupes, merge contacts, pepper with extra info (e.g. matrix-ability of contacts), etc. From c8d67beb9cf32f273fd5a78e26636aa4feedde25 Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Wed, 1 Oct 2014 15:51:49 +0100 Subject: [PATCH 030/106] remove "red", "blue" and "green" server_name mappings --- synapse/http/client.py | 7 ------- 1 file changed, 7 deletions(-) diff --git a/synapse/http/client.py b/synapse/http/client.py index eb11bfd4d5..822afeec1d 100644 --- a/synapse/http/client.py +++ b/synapse/http/client.py @@ -35,13 +35,6 @@ import urllib logger = logging.getLogger(__name__) -# FIXME: SURELY these should be killed?! -_destination_mappings = { - "red": "localhost:8080", - "blue": "localhost:8081", - "green": "localhost:8082", -} - class HttpClient(object): """ Interface for talking json over http From 166bec0c088de407cace0ec9c5293f0a65e74824 Mon Sep 17 00:00:00 2001 From: "Paul \"LeoNerd\" Evans" Date: Wed, 1 Oct 2014 17:32:49 +0100 Subject: [PATCH 031/106] Nuke the entire 'Typing Notifications' spec section given as they don't exist yet in the implementation --- docs/specification.rst | 16 ---------------- 1 file changed, 16 deletions(-) diff --git a/docs/specification.rst b/docs/specification.rst index 6dcdea3060..f35ddec881 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -1536,22 +1536,6 @@ In the latter case, this allows for clients to display some minimal sense of presence information in a user list for a room. -Typing notifications -==================== -.. NOTE:: - This section is a work in progress. - -.. TODO-doc Leo - - what is the event type. Are they bundled with other event types? If so, which. - - what are the valid keys / values. What do they represent. Any gotchas? - - Timeouts. How do they work, who sets them and how do they expire. Does one - have priority over another? Give examples. - -.. TODO-spec Leo - - actually define the client-server API; the only thing that currently - exists is entirely server-server - - Voice over IP ============= Matrix can also be used to set up VoIP calls. This is part of the core From a6d3be4dbf4504a1ec07ffa9c10febbcdc63590d Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Wed, 1 Oct 2014 17:55:31 +0100 Subject: [PATCH 032/106] s/m.room.redacted/m.room.redaction/ --- docs/specification.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/specification.rst b/docs/specification.rst index f35ddec881..6fe72da224 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -1143,7 +1143,7 @@ is the event that caused it to be redacted, which may include a reason. Redacting an event cannot be undone, allowing server owners to delete the offending content from the databases. -Currently, only room admins can redact events by sending a ``m.room.redacted`` +Currently, only room admins can redact events by sending a ``m.room.redaction`` event, but server admins also need to be able to redact events by a similar mechanism. From 5813e81dc65764cbb8862e49f619d6ff71e8e004 Mon Sep 17 00:00:00 2001 From: "Paul \"LeoNerd\" Evans" Date: Wed, 1 Oct 2014 17:59:55 +0100 Subject: [PATCH 033/106] Move documented but-unimplemented 'presence idle times' into a new document to contain such features --- docs/specification-NOTHAVE.rst | 20 ++++++++++++++++++++ docs/specification.rst | 8 -------- 2 files changed, 20 insertions(+), 8 deletions(-) create mode 100644 docs/specification-NOTHAVE.rst diff --git a/docs/specification-NOTHAVE.rst b/docs/specification-NOTHAVE.rst new file mode 100644 index 0000000000..6ed8298cd9 --- /dev/null +++ b/docs/specification-NOTHAVE.rst @@ -0,0 +1,20 @@ +Matrix Specification NOTHAVEs +============================= + +This document contains sections of the main specification that have been +temporarily removed, because they specify intentions or aspirations that have +in no way yet been implemented. Rather than outright-deleting them, they have +been moved here so as to stand as an initial version for such time as they +become extant. + + +Presence +======== + +Idle Time +--------- +As well as the basic ``presence`` field, the presence information can also show +a sense of an "idle timer". This should be maintained individually by the +user's clients, and the home server can take the highest reported time as that +to report. When a user is offline, the home server can still report when the +user was last seen online. diff --git a/docs/specification.rst b/docs/specification.rst index 6fe72da224..84801b7d65 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -1497,14 +1497,6 @@ in the other direction will not). This timestamp is presented via a key called ``last_active_ago``, which gives the relative number of miliseconds since the message is generated/emitted, that the user was last seen active. -Idle Time ---------- -As well as the basic ``presence`` field, the presence information can also show -a sense of an "idle timer". This should be maintained individually by the -user's clients, and the home server can take the highest reported time as that -to report. When a user is offline, the home server can still report when the -user was last seen online. - Transmission ------------ .. NOTE:: From a940a87ddc5bca1eb497abfc91eb835a61328d5f Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Wed, 1 Oct 2014 18:16:47 +0100 Subject: [PATCH 034/106] SPEC-25: Add details on how to prune redacted events. SPEC-25 #comment I've added the details of what the server should do on receipt of a redaction event. In reality it can do whatever it wants, and its probably a reasonable implementation to flag it up to a server admin for verification before actually redacting an event. --- docs/specification.rst | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/docs/specification.rst b/docs/specification.rst index 84801b7d65..22c55ad861 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -1147,6 +1147,36 @@ Currently, only room admins can redact events by sending a ``m.room.redaction`` event, but server admins also need to be able to redact events by a similar mechanism. +Upon receipt of a redaction event, the server should strip off any keys not in +the following list: + + - ``event_id`` + - ``type`` + - ``room_id`` + - ``user_id`` + - ``state_key`` + - ``prev_state`` + - ``content`` + +The content object should also be stripped of all keys, unless it is one of +one of the following event types: + + - ``m.room.member`` allows key ``membership`` + - ``m.room.create`` allows key ``creator`` + - ``m.room.join_rules`` allows key ``join_rule`` + - ``m.room.power_levels`` allows keys that are user ids or ``default`` + - ``m.room.add_state_level`` allows key ``level`` + - ``m.room.send_event_level`` allows key ``level`` + - ``m.room.ops_levels`` allows keys ``kick_level``, ``ban_level`` + and ``redact_level`` + - ``m.room.aliases`` allows key ``aliases`` + +The redaction event should be added under the key ``redacted_because``. + + +When a client receives a redaction event it should change the redacted event +in the same way a server does. + Room Events =========== From ee447abcad251cd499a9752d3dbdda004c940298 Mon Sep 17 00:00:00 2001 From: "Paul \"LeoNerd\" Evans" Date: Wed, 1 Oct 2014 18:34:00 +0100 Subject: [PATCH 035/106] Continue moving content out of docs/model/presence into the main spec; delete model docs that are duplicated --- docs/client-server/model/presence.rst | 100 -------------------------- docs/specification-NOTHAVE.rst | 10 +++ docs/specification.rst | 14 ++++ 3 files changed, 24 insertions(+), 100 deletions(-) diff --git a/docs/client-server/model/presence.rst b/docs/client-server/model/presence.rst index 7e54505364..811bac3fab 100644 --- a/docs/client-server/model/presence.rst +++ b/docs/client-server/model/presence.rst @@ -1,103 +1,3 @@ -======== -Presence -======== - -A description of presence information and visibility between users. - -Overview -======== - -Each user has the concept of Presence information. This encodes a sense of the -"availability" of that user, suitable for display on other user's clients. - - -Presence Information -==================== - -The basic piece of presence information is an enumeration of a small set of -state; such as "free to chat", "online", "busy", or "offline". The default state -unless the user changes it is "online". Lower states suggest some amount of -decreased availability from normal, which might have some client-side effect -like muting notification sounds and suggests to other users not to bother them -unless it is urgent. Equally, the "free to chat" state exists to let the user -announce their general willingness to receive messages moreso than default. - -Home servers should also allow a user to set their state as "hidden" - a state -which behaves as offline, but allows the user to see the client state anyway and -generally interact with client features such as reading message history or -accessing contacts in the address book. - -This basic state field applies to the user as a whole, regardless of how many -client devices they have connected. The home server should synchronise this -status choice among multiple devices to ensure the user gets a consistent -experience. - -Idle Time ---------- - -As well as the basic state field, the presence information can also show a sense -of an "idle timer". This should be maintained individually by the user's -clients, and the homeserver can take the highest reported time as that to -report. Likely this should be presented in fairly coarse granularity; possibly -being limited to letting the home server automatically switch from a "free to -chat" or "online" mode into "idle". - -When a user is offline, the Home Server can still report when the user was last -seen online, again perhaps in a somewhat coarse manner. - -Device Type ------------ - -Client devices that may limit the user experience somewhat (such as "mobile" -devices with limited ability to type on a real keyboard or read large amounts of -text) should report this to the home server, as this is also useful information -to report as "presence" if the user cannot be expected to provide a good typed -response to messages. - - -Presence List -============= - -Each user's home server stores a "presence list" for that user. This stores a -list of other user IDs the user has chosen to add to it (remembering any ACL -Pointer if appropriate). - -To be added to a contact list, the user being added must grant permission. Once -granted, both user's HS(es) store this information, as it allows the user who -has added the contact some more abilities; see below. Since such subscriptions -are likely to be bidirectional, HSes may wish to automatically accept requests -when a reverse subscription already exists. - -As a convenience, presence lists should support the ability to collect users -into groups, which could allow things like inviting the entire group to a new -("ad-hoc") chat room, or easy interaction with the profile information ACL -implementation of the HS. - - -Presence and Permissions -======================== - -For a viewing user to be allowed to see the presence information of a target -user, either - - * The target user has allowed the viewing user to add them to their presence - list, or - - * The two users share at least one room in common - -In the latter case, this allows for clients to display some minimal sense of -presence information in a user list for a room. - -Home servers can also use the user's choice of presence state as a signal for -how to handle new private one-to-one chat message requests. For example, it -might decide: - - "free to chat": accept anything - "online": accept from anyone in my addres book list - "busy": accept from anyone in this "important people" group in my address - book list - - API Efficiency ============== diff --git a/docs/specification-NOTHAVE.rst b/docs/specification-NOTHAVE.rst index 6ed8298cd9..369594f6ae 100644 --- a/docs/specification-NOTHAVE.rst +++ b/docs/specification-NOTHAVE.rst @@ -18,3 +18,13 @@ a sense of an "idle timer". This should be maintained individually by the user's clients, and the home server can take the highest reported time as that to report. When a user is offline, the home server can still report when the user was last seen online. + +Device Type +----------- + +Client devices that may limit the user experience somewhat (such as "mobile" +devices with limited ability to type on a real keyboard or read large amounts of +text) should report this to the home server, as this is also useful information +to report as "presence" if the user cannot be expected to provide a good typed +response to messages. + diff --git a/docs/specification.rst b/docs/specification.rst index 22c55ad861..ada40bdbe3 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -1527,6 +1527,15 @@ in the other direction will not). This timestamp is presented via a key called ``last_active_ago``, which gives the relative number of miliseconds since the message is generated/emitted, that the user was last seen active. +Home servers can also use the user's choice of presence state as a signal for +how to handle new private one-to-one chat message requests. For example, it +might decide: + + - ``free_for_chat`` : accept anything + - ``online`` : accept from anyone in my addres book list + - ``busy`` : accept from anyone in this "important people" group in my + address book list + Transmission ------------ .. NOTE:: @@ -1545,6 +1554,11 @@ granted, both user's HS(es) store this information. Since such subscriptions are likely to be bidirectional, HSes may wish to automatically accept requests when a reverse subscription already exists. +As a convenience, presence lists should support the ability to collect users +into groups, which could allow things like inviting the entire group to a new +("ad-hoc") chat room, or easy interaction with the profile information ACL +implementation of the HS. + Presence and Permissions ------------------------ For a viewing user to be allowed to see the presence information of a target From c5757a0266a26f8448e42bf504c38b379c5a37d6 Mon Sep 17 00:00:00 2001 From: "Paul \"LeoNerd\" Evans" Date: Wed, 1 Oct 2014 19:35:13 +0100 Subject: [PATCH 036/106] Define the client and server APIs for Presence --- docs/specification.rst | 111 +++++++++++++++++++++++++++++++++++++---- 1 file changed, 102 insertions(+), 9 deletions(-) diff --git a/docs/specification.rst b/docs/specification.rst index ada40bdbe3..e270d8a6f5 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -1536,15 +1536,6 @@ might decide: - ``busy`` : accept from anyone in this "important people" group in my address book list -Transmission ------------- -.. NOTE:: - This section is a work in progress. - -.. TODO-doc: - - Transmitted as an EDU. - - Presence lists determine who to send to. - Presence List ------------- Each user's home server stores a "presence list" for that user. This stores a @@ -1571,6 +1562,108 @@ user, either: In the latter case, this allows for clients to display some minimal sense of presence information in a user list for a room. +Client API +---------- +The client API for presence is on the following set of REST calls. + +Fetching basic status:: + + GET $PREFIX/presence/:user_id/status + + Returned content: JSON object containing the following keys: + presence: "offline"|"unavailable"|"online"|"free_for_chat" + status_msg: (optional) string of freeform text + last_active_ago: miliseconds since the last activity by the user + +Setting basic status:: + + PUT $PREFIX/presence/:user_id/status + + Content: JSON object containing the following keys: + presence and status_msg: as above + +When setting the status, the activity time is updated to reflect that activity; +the client does not need to specify the ``last_active_ago`` field. + +Fetching the presence list:: + + GET $PREFIX/presence/list + + Returned content: JSON array containing objects; each object containing the + following keys: + user_id: observed user ID + presence: "offline"|"unavailable"|"online"|"free_for_chat" + status_msg: (optional) string of freeform text + last_active_ago: miliseconds since the last activity by the user + +Maintaining the presence list:: + + POST $PREFIX/presence/list + + Content: JSON object containing either or both of the following keys: + invite: JSON array of strings giving user IDs to send invites to + drop: JSON array of strings giving user IDs to remove from the list + +.. TODO-spec + - Define how users receive presence invites, and how they accept/decline them + +Server API +---------- +The server API for presence is based entirely on exchange of the following +EDUs. There are no PDUs or Federation Queries involved. + +Performing a presence update and poll subscription request:: + + EDU type: m.presence + + Content keys: + push: (optional): list of push operations. + Each should be an object with the following keys: + user_id: string containing a User ID + presence: "offline"|"unavailable"|"online"|"free_for_chat" + status_msg: (optional) string of freeform text + last_active_ago: miliseconds since the last activity by the user + + poll: (optional): list of strings giving User IDs + + unpoll: (optional): list of strings giving User IDs + +The presence of this combined message is two-fold: it informs the recipient +server of the current status of one or more users on the sending server (by the +``push`` key), and it maintains the list of users on the recipient server that +the sending server is interested in receiving updates for, by adding (by the +``poll`` key) or removing them (by the ``unpoll`` key). The ``poll`` and +``unpoll`` lists apply *changes* to the implied list of users; any existing IDs +that the server sent as ``poll`` operations in a previous message are not +removed until explicitly requested by a later ``unpoll``. + +On receipt of a message containing a non-empty ``poll`` list, the receiving +server should immediately send the sending server a presence update EDU of its +own, containing in a ``push`` list the current state of every user that was in +the orginal EDU's ``poll`` list. + +Sending a presence invite:: + + EDU type: m.presence_invite + + Content keys: + observed_user: string giving the User ID of the user whose presence is + requested (i.e. the recipient of the invite) + observer_user: string giving the User ID of the user who is requesting to + observe the presence (i.e. the sender of the invite) + +Accepting a presence invite:: + + EDU type: m.presence_accept + + Content keys - as for m.presence_invite + +Rejecting a presence invite:: + + EDU type: m.presence_deny + + Content keys - as for m.presence_invite + Voice over IP ============= From bf8b9b90cde80f4e60433378c552176f3a1d0619 Mon Sep 17 00:00:00 2001 From: "Paul \"LeoNerd\" Evans" Date: Wed, 1 Oct 2014 19:37:18 +0100 Subject: [PATCH 037/106] Added a TODO-doc marker about the presence timing system --- docs/specification.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/specification.rst b/docs/specification.rst index e270d8a6f5..0a421e9e38 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -1664,6 +1664,12 @@ Rejecting a presence invite:: Content keys - as for m.presence_invite +.. TODO-doc + - Explain the timing-based roundtrip reduction mechanism for presence + messages + - Explain the zero-byte presence inference logic + See also: docs/client-server/model/presence + Voice over IP ============= From a0b1b34c71e46304f7024f0570db92f4577303b5 Mon Sep 17 00:00:00 2001 From: David Baker Date: Thu, 2 Oct 2014 09:55:26 +0100 Subject: [PATCH 038/106] Make instructions synctl gives for generateing a config file actuall generate a config file. Also, make synctil run synapse correctly by invoking a module such that the path is correct to pull in other bits from the working directory rather than requiring them to be on the PYTHONPATH (which would lead to people being very confused when they edit source in the working directory and their changes do not take effect). --- synctl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/synctl b/synctl index 0f83e9cb1f..7523fd3dbc 100755 --- a/synctl +++ b/synctl @@ -1,6 +1,6 @@ #!/bin/bash -SYNAPSE="synapse/app/homeserver.py" +SYNAPSE="python -m synapse.app.homeserver" CONFIGFILE="homeserver.yaml" PIDFILE="homeserver.pid" @@ -14,7 +14,7 @@ case "$1" in start) if [ ! -f "$CONFIGFILE" ]; then echo "No config file found" - echo "To generate a config file, run 'python --generate-config'" + echo "To generate a config file, run '$SYNAPSE -c $CONFIGFILE --generate-config'" exit 1 fi From d1adb19b8af839afcb4fa4d302abb7036a9acd0a Mon Sep 17 00:00:00 2001 From: David Baker Date: Thu, 2 Oct 2014 10:38:11 +0100 Subject: [PATCH 039/106] Re-apply a0b1b34c71e46304f7024f0570db92f4577303b5 to master (fixing synctl) --- synctl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/synctl b/synctl index 0f83e9cb1f..7523fd3dbc 100755 --- a/synctl +++ b/synctl @@ -1,6 +1,6 @@ #!/bin/bash -SYNAPSE="synapse/app/homeserver.py" +SYNAPSE="python -m synapse.app.homeserver" CONFIGFILE="homeserver.yaml" PIDFILE="homeserver.pid" @@ -14,7 +14,7 @@ case "$1" in start) if [ ! -f "$CONFIGFILE" ]; then echo "No config file found" - echo "To generate a config file, run 'python --generate-config'" + echo "To generate a config file, run '$SYNAPSE -c $CONFIGFILE --generate-config'" exit 1 fi From 7a322b63264acbef7e60b511ad8d39ae4718386b Mon Sep 17 00:00:00 2001 From: David Baker Date: Thu, 2 Oct 2014 10:43:22 +0100 Subject: [PATCH 040/106] Update README setup instructions to be correct. Make synapse spit out explanatory note when generating config to tell people to look at it and customise it. --- README.rst | 12 +++++++----- synapse/config/_base.py | 1 + 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/README.rst b/README.rst index 6f7940e742..1530e5caac 100644 --- a/README.rst +++ b/README.rst @@ -46,11 +46,13 @@ To get up and running: - To simply play with an **existing** homeserver you can just go straight to http://matrix.org/alpha. - - To run your own **private** homeserver on localhost:8008, install synapse with - ``python setup.py develop --user`` and then run ``./synctl start`` twice (once to - generate a config; once to actually run) - you will find a webclient running at - http://localhost:8008. Please use a recent Chrome, Safari or Firefox for now... - + - To run your own **private** homeserver on localhost:8008, generate a basic + config file: ``./synctl start`` will give you instructions on how to do this. + Once you've done so, running ``./synctl start`` again will start your private + home sserver. You will find a webclient running at http://localhost:8008. + Please use a recent Chrome or Firefox for now (or Safari if you don't need + VoIP support). + - To run a **public** homeserver and let it exchange messages with other homeservers and participate in the global Matrix federation, you must expose port 8448 to the internet and edit homeserver.yaml to specify server_name (the public DNS entry for diff --git a/synapse/config/_base.py b/synapse/config/_base.py index 35bcece2c0..809f9c922b 100644 --- a/synapse/config/_base.py +++ b/synapse/config/_base.py @@ -123,6 +123,7 @@ class Config(object): # style mode markers into the file, to hint to people that # this is a YAML file. yaml.dump(config, config_file, default_flow_style=False) + print "A config file has been generated in %s (your server name is '%s'). Please review this file and customise it to your needs." % (config_args.config_path, config['server_name']) sys.exit(0) return cls(args) From 45f7677bdcffdc1e0b64d05f1b7c23dab0d1342c Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Thu, 2 Oct 2014 11:00:21 +0100 Subject: [PATCH 041/106] Trivial formatting fixes for README. --- README.rst | 166 +++++++++++++++++++++++++++-------------------------- 1 file changed, 85 insertions(+), 81 deletions(-) diff --git a/README.rst b/README.rst index 1530e5caac..0459d54634 100644 --- a/README.rst +++ b/README.rst @@ -4,13 +4,13 @@ Introduction Matrix is an ambitious new ecosystem for open federated Instant Messaging and VoIP. The basics you need to know to get up and running are: - - Chatrooms are distributed and do not exist on any single server. Rooms - can be found using aliases like ``#matrix:matrix.org`` or - ``#test:localhost:8008`` or they can be ephemeral. - - - Matrix user IDs look like ``@matthew:matrix.org`` (although in the future - you will normally refer to yourself and others using a 3PID: email - address, phone number, etc rather than manipulating Matrix user IDs) +- Chatrooms are distributed and do not exist on any single server. Rooms + can be found using aliases like ``#matrix:matrix.org`` or + ``#test:localhost:8008`` or they can be ephemeral. + +- Matrix user IDs look like ``@matthew:matrix.org`` (although in the future + you will normally refer to yourself and others using a 3PID: email + address, phone number, etc rather than manipulating Matrix user IDs) The overall architecture is:: @@ -20,70 +20,74 @@ The overall architecture is:: WARNING ======= -**Synapse is currently in a state of rapid development, and not all features are yet functional. -Critically, some security features are still in development, which means Synapse can *not* -be considered secure or reliable at this point.** For instance: +**Synapse is currently in a state of rapid development, and not all features +are yet functional. Critically, some security features are still in +development, which means Synapse can *not* be considered secure or reliable at +this point.** For instance: - **SSL Certificates used by server-server federation are not yet validated.** - **Room permissions are not yet enforced on traffic received via federation.** -- **Homeservers do not yet cryptographically sign their events to avoid tampering** +- **Homeservers do not yet cryptographically sign their events to avoid + tampering** - Default configuration provides open signup to the service from the internet -Despite this, we believe Synapse is more than useful as a way for experimenting and -exploring Synapse, and the missing features will land shortly. **Until then, please do *NOT* -use Synapse for any remotely important or secure communication.** +Despite this, we believe Synapse is more than useful as a way for experimenting +and exploring Synapse, and the missing features will land shortly. **Until +then, please do *NOT* use Synapse for any remotely important or secure +communication.** Quick Start =========== System requirements: - - POSIX-compliant system (tested on Linux & OSX) - - Python 2.7 +- POSIX-compliant system (tested on Linux & OSX) +- Python 2.7 To get up and running: - - - To simply play with an **existing** homeserver you can - just go straight to http://matrix.org/alpha. - - - To run your own **private** homeserver on localhost:8008, generate a basic - config file: ``./synctl start`` will give you instructions on how to do this. - Once you've done so, running ``./synctl start`` again will start your private - home sserver. You will find a webclient running at http://localhost:8008. - Please use a recent Chrome or Firefox for now (or Safari if you don't need - VoIP support). - - To run a **public** homeserver and let it exchange messages with other homeservers - and participate in the global Matrix federation, you must expose port 8448 to the - internet and edit homeserver.yaml to specify server_name (the public DNS entry for - this server) and then run ``synctl start``. If you changed the server_name, you may - need to move the old database (homeserver.db) out of the way first. Then come join - ``#matrix:matrix.org`` and say hi! :) +- To simply play with an **existing** homeserver you can + just go straight to http://matrix.org/alpha. + +- To run your own **private** homeserver on localhost:8008, generate a basic + config file: ``./synctl start`` will give you instructions on how to do this. + Once you've done so, running ``./synctl start`` again will start your private + home sserver. You will find a webclient running at http://localhost:8008. + Please use a recent Chrome or Firefox for now (or Safari if you don't need + VoIP support). + +- To run a **public** homeserver and let it exchange messages with other + homeservers and participate in the global Matrix federation, you must expose + port 8448 to the internet and edit homeserver.yaml to specify server_name + (the public DNS entry for this server) and then run ``synctl start``. If you + changed the server_name, you may need to move the old database + (homeserver.db) out of the way first. Then come join ``#matrix:matrix.org`` + and say hi! :) For more detailed setup instructions, please see further down this document. - + About Matrix ============ Matrix specifies a set of pragmatic RESTful HTTP JSON APIs as an open standard, which handle: - - Creating and managing fully distributed chat rooms with no - single points of control or failure - - Eventually-consistent cryptographically secure[1] synchronisation of room - state across a global open network of federated servers and services - - Sending and receiving extensible messages in a room with (optional) - end-to-end encryption[2] - - Inviting, joining, leaving, kicking, banning room members - - Managing user accounts (registration, login, logout) - - Using 3rd Party IDs (3PIDs) such as email addresses, phone numbers, - Facebook accounts to authenticate, identify and discover users on Matrix. - - Placing 1:1 VoIP and Video calls +- Creating and managing fully distributed chat rooms with no + single points of control or failure +- Eventually-consistent cryptographically secure[1] synchronisation of room + state across a global open network of federated servers and services +- Sending and receiving extensible messages in a room with (optional) + end-to-end encryption[2] +- Inviting, joining, leaving, kicking, banning room members +- Managing user accounts (registration, login, logout) +- Using 3rd Party IDs (3PIDs) such as email addresses, phone numbers, + Facebook accounts to authenticate, identify and discover users on Matrix. +- Placing 1:1 VoIP and Video calls These APIs are intended to be implemented on a wide range of servers, services -and clients, letting developers build messaging and VoIP functionality on top of -the entirely open Matrix ecosystem rather than using closed or proprietary +and clients, letting developers build messaging and VoIP functionality on top +of the entirely open Matrix ecosystem rather than using closed or proprietary solutions. The hope is for Matrix to act as the building blocks for a new generation of fully open and interoperable messaging and VoIP apps for the internet. @@ -98,17 +102,17 @@ In Matrix, every user runs one or more Matrix clients, which connect through to a Matrix homeserver which stores all their personal chat history and user account information - much as a mail client connects through to an IMAP/SMTP server. Just like email, you can either run your own Matrix homeserver and -control and own your own communications and history or use one hosted by someone -else (e.g. matrix.org) - there is no single point of control or mandatory -service provider in Matrix, unlike WhatsApp, Facebook, Hangouts, etc. +control and own your own communications and history or use one hosted by +someone else (e.g. matrix.org) - there is no single point of control or +mandatory service provider in Matrix, unlike WhatsApp, Facebook, Hangouts, etc. Synapse ships with two basic demo Matrix clients: webclient (a basic group chat web client demo implemented in AngularJS) and cmdclient (a basic Python command line utility which lets you easily see what the JSON APIs are up to). We'd like to invite you to take a look at the Matrix spec, try to run a -homeserver, and join the existing Matrix chatrooms already out there, experiment -with the APIs and the demo clients, and let us know your thoughts at +homeserver, and join the existing Matrix chatrooms already out there, +experiment with the APIs and the demo clients, and let us know your thoughts at https://github.com/matrix-org/synapse/issues or at matrix@matrix.org. Thanks for trying Matrix! @@ -121,14 +125,14 @@ Thanks for trying Matrix! Homeserver Installation ======================= -First, the dependencies need to be installed. Start by installing +First, the dependencies need to be installed. Start by installing 'python2.7-dev' and the various tools of the compiler toolchain. - Installing prerequisites on Ubuntu:: +Installing prerequisites on Ubuntu:: $ sudo apt-get install build-essential python2.7-dev libffi-dev - Installing prerequisites on Mac OS X:: +Installing prerequisites on Mac OS X:: $ xcode-select --install @@ -136,24 +140,24 @@ The homeserver has a number of external dependencies, that are easiest to install by making setup.py do so, in --user mode:: $ python setup.py develop --user - + You'll need a version of setuptools new enough to know about git, so you -may need to also run: +may need to also run:: $ sudo apt-get install python-pip $ sudo pip install --upgrade setuptools - + If you don't have access to github, then you may need to install ``syutil`` -manually by checking it out and running ``python setup.py develop --user`` on it -too. - +manually by checking it out and running ``python setup.py develop --user`` on +it too. + If you get errors about ``sodium.h`` being missing, you may also need to manually install a newer PyNaCl via pip as setuptools installs an old one. Or you can check PyNaCl out of git directly (https://github.com/pyca/pynacl) and -installing it. Installing PyNaCl using pip may also work (remember to remove any -other versions installed by setuputils in, for example, ~/.local/lib). +installing it. Installing PyNaCl using pip may also work (remember to remove +any other versions installed by setuputils in, for example, ~/.local/lib). -On OSX, if you encounter ``clang: error: unknown argument: '-mno-fused-madd'`` +On OSX, if you encounter ``clang: error: unknown argument: '-mno-fused-madd'`` you will need to ``export CFLAGS=-Qunused-arguments``. This will run a process of downloading and installing into your @@ -177,7 +181,7 @@ Upgrading an existing homeserver Before upgrading an existing homeserver to a new version, please refer to UPGRADE.rst for any additional instructions. - + Setting up Federation ===================== @@ -187,14 +191,14 @@ be publicly visible on the internet, and they will need to know its host name. You have two choices here, which will influence the form of your Matrix user IDs: - 1) Use the machine's own hostname as available on public DNS in the form of its - A or AAAA records. This is easier to set up initially, perhaps for testing, - but lacks the flexibility of SRV. +1) Use the machine's own hostname as available on public DNS in the form of + its A or AAAA records. This is easier to set up initially, perhaps for + testing, but lacks the flexibility of SRV. - 2) Set up a SRV record for your domain name. This requires you create a SRV - record in DNS, but gives the flexibility to run the server on your own - choice of TCP port, on a machine that might not be the same name as the - domain name. +2) Set up a SRV record for your domain name. This requires you create a SRV + record in DNS, but gives the flexibility to run the server on your own + choice of TCP port, on a machine that might not be the same name as the + domain name. For the first form, simply pass the required hostname (of the machine) as the --host parameter:: @@ -204,10 +208,10 @@ For the first form, simply pass the required hostname (of the machine) as the --config-path homeserver.config \ --generate-config $ python synapse/app/homeserver.py --config-path homeserver.config - -Alternatively, you can run synapse via synctl - running ``synctl start`` to -generate a homeserver.yaml config file, where you can then edit server-name to -specify machine.my.domain.name, and then set the actual server running again + +Alternatively, you can run synapse via synctl - running ``synctl start`` to +generate a homeserver.yaml config file, where you can then edit server-name to +specify machine.my.domain.name, and then set the actual server running again with synctl start. For the second form, first create your SRV record and publish it in DNS. This @@ -269,8 +273,8 @@ account. Your name will take the form of:: Specify your desired localpart in the topmost box of the "Register for an account" form, and click the "Register" button. Hostnames can contain ports if -required due to lack of SRV records (e.g. @matthew:localhost:8080 on an internal -synapse sandbox running on localhost) +required due to lack of SRV records (e.g. @matthew:localhost:8080 on an +internal synapse sandbox running on localhost) Logging In To An Existing Account @@ -285,9 +289,9 @@ Identity Servers The job of authenticating 3PIDs and tracking which 3PIDs are associated with a given Matrix user is very security-sensitive, as there is obvious risk of spam -if it is too easy to sign up for Matrix accounts or harvest 3PID data. Meanwhile -the job of publishing the end-to-end encryption public keys for Matrix users is -also very security-sensitive for similar reasons. +if it is too easy to sign up for Matrix accounts or harvest 3PID data. +Meanwhile the job of publishing the end-to-end encryption public keys for +Matrix users is also very security-sensitive for similar reasons. Therefore the role of managing trusted identity in the Matrix ecosystem is farmed out to a cluster of known trusted ecosystem partners, who run 'Matrix @@ -296,7 +300,7 @@ track 3PID logins and publish end-user public keys. It's currently early days for identity servers as Matrix is not yet using 3PIDs as the primary means of identity and E2E encryption is not complete. As such, -we are running a single identity server (http://matrix.org:8090) at the current +we are running a single identity server (http://matrix.org:8090) at the current time. From 4f11518934c3e032a763f115a73261414d67f87b Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Thu, 2 Oct 2014 13:57:48 +0100 Subject: [PATCH 042/106] Split PlainHttpClient into separate clients for talking to Identity servers and talking to Capatcha servers --- synapse/app/homeserver.py | 4 +- synapse/handlers/directory.py | 4 +- synapse/handlers/login.py | 6 +- synapse/handlers/register.py | 11 +- synapse/http/client.py | 296 ++++++++++++++++--------------- tests/handlers/test_directory.py | 4 +- 6 files changed, 166 insertions(+), 159 deletions(-) diff --git a/synapse/app/homeserver.py b/synapse/app/homeserver.py index 2f1b954902..61d574a00f 100755 --- a/synapse/app/homeserver.py +++ b/synapse/app/homeserver.py @@ -25,7 +25,7 @@ from twisted.web.static import File from twisted.web.server import Site from synapse.http.server import JsonResource, RootRedirect from synapse.http.content_repository import ContentRepoResource -from synapse.http.client import TwistedHttpClient +from synapse.http.client import MatrixHttpClient from synapse.api.urls import ( CLIENT_PREFIX, FEDERATION_PREFIX, WEB_CLIENT_PREFIX, CONTENT_REPO_PREFIX ) @@ -47,7 +47,7 @@ logger = logging.getLogger(__name__) class SynapseHomeServer(HomeServer): def build_http_client(self): - return TwistedHttpClient(self) + return MatrixHttpClient(self) def build_resource_for_client(self): return JsonResource() diff --git a/synapse/handlers/directory.py b/synapse/handlers/directory.py index 84c3a1d56f..cec7737e09 100644 --- a/synapse/handlers/directory.py +++ b/synapse/handlers/directory.py @@ -18,7 +18,7 @@ from twisted.internet import defer from ._base import BaseHandler from synapse.api.errors import SynapseError -from synapse.http.client import HttpClient +from synapse.http.client import MatrixHttpClient from synapse.api.events.room import RoomAliasesEvent import logging @@ -98,7 +98,7 @@ class DirectoryHandler(BaseHandler): query_type="directory", args={ "room_alias": room_alias.to_string(), - HttpClient.RETRY_DNS_LOOKUP_FAILURES: False + MatrixHttpClient.RETRY_DNS_LOOKUP_FAILURES: False } ) diff --git a/synapse/handlers/login.py b/synapse/handlers/login.py index 80ffdd2726..3f152e18f0 100644 --- a/synapse/handlers/login.py +++ b/synapse/handlers/login.py @@ -17,7 +17,7 @@ from twisted.internet import defer from ._base import BaseHandler from synapse.api.errors import LoginError, Codes -from synapse.http.client import PlainHttpClient +from synapse.http.client import IdentityServerHttpClient from synapse.util.emailutils import EmailException import synapse.util.emailutils as emailutils @@ -97,10 +97,10 @@ class LoginHandler(BaseHandler): @defer.inlineCallbacks def _query_email(self, email): - httpCli = PlainHttpClient(self.hs) + httpCli = IdentityServerHttpClient(self.hs) data = yield httpCli.get_json( 'matrix.org:8090', # TODO FIXME This should be configurable. "/_matrix/identity/api/v1/lookup?medium=email&address=" + "%s" % urllib.quote(email) ) - defer.returnValue(data) \ No newline at end of file + defer.returnValue(data) diff --git a/synapse/handlers/register.py b/synapse/handlers/register.py index a019d770d4..266495056e 100644 --- a/synapse/handlers/register.py +++ b/synapse/handlers/register.py @@ -22,7 +22,8 @@ from synapse.api.errors import ( ) from ._base import BaseHandler import synapse.util.stringutils as stringutils -from synapse.http.client import PlainHttpClient +from synapse.http.client import IdentityServerHttpClient +from synapse.http.client import CaptchaServerHttpClient import base64 import bcrypt @@ -154,7 +155,9 @@ class RegistrationHandler(BaseHandler): @defer.inlineCallbacks def _threepid_from_creds(self, creds): - httpCli = PlainHttpClient(self.hs) + # TODO: get this from the homeserver rather than creating a new one for + # each request + httpCli = IdentityServerHttpClient(self.hs) # XXX: make this configurable! trustedIdServers = ['matrix.org:8090'] if not creds['idServer'] in trustedIdServers: @@ -203,7 +206,9 @@ class RegistrationHandler(BaseHandler): @defer.inlineCallbacks def _submit_captcha(self, ip_addr, private_key, challenge, response): - client = PlainHttpClient(self.hs) + # TODO: get this from the homeserver rather than creating a new one for + # each request + client = CaptchaServerHttpClient(self.hs) data = yield client.post_urlencoded_get_raw( "www.google.com:80", "/recaptcha/api/verify", diff --git a/synapse/http/client.py b/synapse/http/client.py index 822afeec1d..e02cce5642 100644 --- a/synapse/http/client.py +++ b/synapse/http/client.py @@ -36,49 +36,6 @@ import urllib logger = logging.getLogger(__name__) -class HttpClient(object): - """ Interface for talking json over http - """ - RETRY_DNS_LOOKUP_FAILURES = "__retry_dns" - - def put_json(self, destination, path, data): - """ Sends the specifed json data using PUT - - Args: - destination (str): The remote server to send the HTTP request - to. - path (str): The HTTP path. - data (dict): A dict containing the data that will be used as - the request body. This will be encoded as JSON. - - Returns: - Deferred: Succeeds when we get a 2xx HTTP response. The result - will be the decoded JSON body. On a 4xx or 5xx error response a - CodeMessageException is raised. - """ - pass - - def get_json(self, destination, path, args=None): - """ Get's some json from the given host homeserver and path - - Args: - destination (str): The remote server to send the HTTP request - to. - path (str): The HTTP path. - args (dict): A dictionary used to create query strings, defaults to - None. - **Note**: The value of each key is assumed to be an iterable - and *not* a string. - - Returns: - Deferred: Succeeds when we get *any* HTTP response. - - The result of the deferred is a tuple of `(code, response)`, - where `response` is a dict representing the decoded JSON body. - """ - pass - - class MatrixHttpAgent(_AgentBase): def __init__(self, reactor, pool=None): @@ -102,113 +59,14 @@ class MatrixHttpAgent(_AgentBase): parsed_URI.originForm) -class TwistedHttpClient(HttpClient): - """ Wrapper around the twisted HTTP client api. - - Attributes: - agent (twisted.web.client.Agent): The twisted Agent used to send the - requests. +class BaseHttpClient(object): + """Base class for HTTP clients using twisted. """ def __init__(self, hs): self.agent = MatrixHttpAgent(reactor) self.hs = hs - @defer.inlineCallbacks - def put_json(self, destination, path, data, on_send_callback=None): - if destination in _destination_mappings: - destination = _destination_mappings[destination] - - response = yield self._create_request( - destination.encode("ascii"), - "PUT", - path.encode("ascii"), - producer=_JsonProducer(data), - headers_dict={"Content-Type": ["application/json"]}, - on_send_callback=on_send_callback, - ) - - logger.debug("Getting resp body") - body = yield readBody(response) - logger.debug("Got resp body") - - defer.returnValue((response.code, body)) - - @defer.inlineCallbacks - def get_json(self, destination, path, args={}): - if destination in _destination_mappings: - destination = _destination_mappings[destination] - - logger.debug("get_json args: %s", args) - - retry_on_dns_fail = True - if HttpClient.RETRY_DNS_LOOKUP_FAILURES in args: - # FIXME: This isn't ideal, but the interface exposed in get_json - # isn't comprehensive enough to give caller's any control over - # their connection mechanics. - retry_on_dns_fail = args.pop(HttpClient.RETRY_DNS_LOOKUP_FAILURES) - - query_bytes = urllib.urlencode(args, True) - logger.debug("Query bytes: %s Retry DNS: %s", args, retry_on_dns_fail) - - response = yield self._create_request( - destination.encode("ascii"), - "GET", - path.encode("ascii"), - query_bytes=query_bytes, - retry_on_dns_fail=retry_on_dns_fail - ) - - body = yield readBody(response) - - defer.returnValue(json.loads(body)) - - @defer.inlineCallbacks - def post_urlencoded_get_json(self, destination, path, args={}): - if destination in _destination_mappings: - destination = _destination_mappings[destination] - - logger.debug("post_urlencoded_get_json args: %s", args) - query_bytes = urllib.urlencode(args, True) - - response = yield self._create_request( - destination.encode("ascii"), - "POST", - path.encode("ascii"), - producer=FileBodyProducer(StringIO(urllib.urlencode(args))), - headers_dict={"Content-Type": ["application/x-www-form-urlencoded"]} - ) - - body = yield readBody(response) - - defer.returnValue(json.loads(body)) - - # XXX FIXME : I'm so sorry. - @defer.inlineCallbacks - def post_urlencoded_get_raw(self, destination, path, accept_partial=False, args={}): - if destination in _destination_mappings: - destination = _destination_mappings[destination] - - query_bytes = urllib.urlencode(args, True) - - response = yield self._create_request( - destination.encode("ascii"), - "POST", - path.encode("ascii"), - producer=FileBodyProducer(StringIO(urllib.urlencode(args))), - headers_dict={"Content-Type": ["application/x-www-form-urlencoded"]} - ) - - try: - body = yield readBody(response) - defer.returnValue(body) - except PartialDownloadError as e: - if accept_partial: - defer.returnValue(e.response) - else: - raise e - - @defer.inlineCallbacks def _create_request(self, destination, method, path_bytes, param_bytes=b"", query_bytes=b"", producer=None, headers_dict={}, @@ -232,7 +90,6 @@ class TwistedHttpClient(HttpClient): retries_left = 5 - # TODO: setup and pass in an ssl_context to enable TLS endpoint = self._getEndpoint(reactor, destination); while True: @@ -283,6 +140,92 @@ class TwistedHttpClient(HttpClient): defer.returnValue(response) + +class MatrixHttpClient(BaseHttpClient): + """ Wrapper around the twisted HTTP client api. Implements + + Attributes: + agent (twisted.web.client.Agent): The twisted Agent used to send the + requests. + """ + + RETRY_DNS_LOOKUP_FAILURES = "__retry_dns" + + @defer.inlineCallbacks + def put_json(self, destination, path, data, on_send_callback=None): + """ Sends the specifed json data using PUT + + Args: + destination (str): The remote server to send the HTTP request + to. + path (str): The HTTP path. + data (dict): A dict containing the data that will be used as + the request body. This will be encoded as JSON. + + Returns: + Deferred: Succeeds when we get a 2xx HTTP response. The result + will be the decoded JSON body. On a 4xx or 5xx error response a + CodeMessageException is raised. + """ + response = yield self._create_request( + destination.encode("ascii"), + "PUT", + path.encode("ascii"), + producer=_JsonProducer(data), + headers_dict={"Content-Type": ["application/json"]}, + on_send_callback=on_send_callback, + ) + + logger.debug("Getting resp body") + body = yield readBody(response) + logger.debug("Got resp body") + + defer.returnValue((response.code, body)) + + @defer.inlineCallbacks + def get_json(self, destination, path, args={}): + """ Get's some json from the given host homeserver and path + + Args: + destination (str): The remote server to send the HTTP request + to. + path (str): The HTTP path. + args (dict): A dictionary used to create query strings, defaults to + None. + **Note**: The value of each key is assumed to be an iterable + and *not* a string. + + Returns: + Deferred: Succeeds when we get *any* HTTP response. + + The result of the deferred is a tuple of `(code, response)`, + where `response` is a dict representing the decoded JSON body. + """ + logger.debug("get_json args: %s", args) + + retry_on_dns_fail = True + if HttpClient.RETRY_DNS_LOOKUP_FAILURES in args: + # FIXME: This isn't ideal, but the interface exposed in get_json + # isn't comprehensive enough to give caller's any control over + # their connection mechanics. + retry_on_dns_fail = args.pop(HttpClient.RETRY_DNS_LOOKUP_FAILURES) + + query_bytes = urllib.urlencode(args, True) + logger.debug("Query bytes: %s Retry DNS: %s", args, retry_on_dns_fail) + + response = yield self._create_request( + destination.encode("ascii"), + "GET", + path.encode("ascii"), + query_bytes=query_bytes, + retry_on_dns_fail=retry_on_dns_fail + ) + + body = yield readBody(response) + + defer.returnValue(json.loads(body)) + + def _getEndpoint(self, reactor, destination): return matrix_endpoint( reactor, destination, timeout=10, @@ -290,10 +233,69 @@ class TwistedHttpClient(HttpClient): ) -class PlainHttpClient(TwistedHttpClient): +class IdentityServerHttpClient(BaseHttpClient): + """Separate HTTP client for talking to the Identity servers since they + don't use SRV records and talk x-www-form-urlencoded rather than JSON. + """ + def _getEndpoint(self, reactor, destination): + #TODO: This should be talking TLS + return matrix_endpoint(reactor, destination, timeout=10) + + @defer.inlineCallbacks + def post_urlencoded_get_json(self, destination, path, args={}): + if destination in _destination_mappings: + destination = _destination_mappings[destination] + + logger.debug("post_urlencoded_get_json args: %s", args) + query_bytes = urllib.urlencode(args, True) + + response = yield self._create_request( + destination.encode("ascii"), + "POST", + path.encode("ascii"), + producer=FileBodyProducer(StringIO(urllib.urlencode(args))), + headers_dict={ + "Content-Type": ["application/x-www-form-urlencoded"] + } + ) + + body = yield readBody(response) + + defer.returnValue(json.loads(body)) + + +class CaptchaServerHttpClient(MatrixHttpClient): + """Separate HTTP client for talking to google's captcha servers""" + def _getEndpoint(self, reactor, destination): return matrix_endpoint(reactor, destination, timeout=10) - + + @defer.inlineCallbacks + def post_urlencoded_get_raw(self, destination, path, accept_partial=False, + args={}): + if destination in _destination_mappings: + destination = _destination_mappings[destination] + + query_bytes = urllib.urlencode(args, True) + + response = yield self._create_request( + destination.encode("ascii"), + "POST", + path.encode("ascii"), + producer=FileBodyProducer(StringIO(urllib.urlencode(args))), + headers_dict={ + "Content-Type": ["application/x-www-form-urlencoded"] + } + ) + + try: + body = yield readBody(response) + defer.returnValue(body) + except PartialDownloadError as e: + if accept_partial: + defer.returnValue(e.response) + else: + raise e def _print_ex(e): if hasattr(e, "reasons") and e.reasons: diff --git a/tests/handlers/test_directory.py b/tests/handlers/test_directory.py index dd5d85dde6..0c31502dd4 100644 --- a/tests/handlers/test_directory.py +++ b/tests/handlers/test_directory.py @@ -20,7 +20,7 @@ from twisted.internet import defer from mock import Mock from synapse.server import HomeServer -from synapse.http.client import HttpClient +from synapse.http.client import MatrixHttpClient from synapse.handlers.directory import DirectoryHandler from synapse.storage.directory import RoomAliasMapping @@ -95,7 +95,7 @@ class DirectoryTestCase(unittest.TestCase): query_type="directory", args={ "room_alias": "#another:remote", - HttpClient.RETRY_DNS_LOOKUP_FAILURES: False + MatrixHttpClient.RETRY_DNS_LOOKUP_FAILURES: False } ) From d694619a953adf6254e3960d2a4ec973d31dfcae Mon Sep 17 00:00:00 2001 From: David Baker Date: Thu, 2 Oct 2014 14:09:27 +0100 Subject: [PATCH 043/106] Fix ncorrect ports in documentation and add notes on how generate-config also generates certs bound to whatever hostname you give with --generate-config. SYN-87 #resolved --- README.rst | 5 +++-- synapse/config/_base.py | 3 ++- synctl | 2 +- 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/README.rst b/README.rst index 0459d54634..f40492b8a0 100644 --- a/README.rst +++ b/README.rst @@ -51,6 +51,7 @@ To get up and running: - To run your own **private** homeserver on localhost:8008, generate a basic config file: ``./synctl start`` will give you instructions on how to do this. + For this purpose, you can use 'localhost' or your hostname as a server name. Once you've done so, running ``./synctl start`` again will start your private home sserver. You will find a webclient running at http://localhost:8008. Please use a recent Chrome or Firefox for now (or Safari if you don't need @@ -253,7 +254,7 @@ http://localhost:8080. Simply run:: Running The Demo Web Client =========================== -The homeserver runs a web client by default at http://localhost:8080. +The homeserver runs a web client by default at https://localhost:8448/. If this is the first time you have used the client from that browser (it uses HTML5 local storage to remember its config), you will need to log in to your @@ -273,7 +274,7 @@ account. Your name will take the form of:: Specify your desired localpart in the topmost box of the "Register for an account" form, and click the "Register" button. Hostnames can contain ports if -required due to lack of SRV records (e.g. @matthew:localhost:8080 on an +required due to lack of SRV records (e.g. @matthew:localhost:8448 on an internal synapse sandbox running on localhost) diff --git a/synapse/config/_base.py b/synapse/config/_base.py index 809f9c922b..b3aeff327c 100644 --- a/synapse/config/_base.py +++ b/synapse/config/_base.py @@ -123,7 +123,8 @@ class Config(object): # style mode markers into the file, to hint to people that # this is a YAML file. yaml.dump(config, config_file, default_flow_style=False) - print "A config file has been generated in %s (your server name is '%s'). Please review this file and customise it to your needs." % (config_args.config_path, config['server_name']) + print "A config file has been generated in %s for server name '%s') with corresponding SSL keys and self-signed certificates. Please review this file and customise it to your needs." % (config_args.config_path, config['server_name']) + print "If this server name is incorrect, you will need to regenerate the SSL certificates" sys.exit(0) return cls(args) diff --git a/synctl b/synctl index 7523fd3dbc..c227a9e1e4 100755 --- a/synctl +++ b/synctl @@ -14,7 +14,7 @@ case "$1" in start) if [ ! -f "$CONFIGFILE" ]; then echo "No config file found" - echo "To generate a config file, run '$SYNAPSE -c $CONFIGFILE --generate-config'" + echo "To generate a config file, run '$SYNAPSE -c $CONFIGFILE --generate-config --server-name='" exit 1 fi From b2d41b1cd94d6278f5d3e090d45762fff4219d2f Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Thu, 2 Oct 2014 14:25:47 +0100 Subject: [PATCH 044/106] All room state is currently shared. --- docs/specification.rst | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/docs/specification.rst b/docs/specification.rst index 0a421e9e38..f45c75fca9 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -167,7 +167,7 @@ The following diagram shows an ``m.room.message`` event being sent in the room | matrix.org |<-------Federation------->| domain.com | +------------------+ +------------------+ | ................................. | - |______| Partially Shared State |_______| + |______| Shared State |_______| | Room ID: !qporfwt:matrix.org | | Servers: matrix.org, domain.com | | Members: | @@ -177,11 +177,10 @@ The following diagram shows an ``m.room.message`` event being sent in the room Federation maintains shared state between multiple home servers, such that when an event is sent to a room, the home server knows where to forward the event on -to, and how to process the event. Home servers do not need to have completely -shared state in order to participate in a room. State is scoped to a single -room, and federation ensures that all home servers have the information they -need, even if that means the home server has to request more information from -another home server before processing the event. +to, and how to process the event. State is scoped to a single room, and +federation ensures that all home servers have the information they need, even +if that means the home server has to request more information from another home +server before processing the event. Room Aliases ------------ From 574377636ee4eafba50580fc4d7a1d0793774332 Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Thu, 2 Oct 2014 14:09:15 +0100 Subject: [PATCH 045/106] Add a keyword argument to get_json to avoid retrying on DNS failures. Rather than passing MatrixHttpClient.RETRY_DNS_LOOKUP_FAILURES as a fake query string parameter --- synapse/federation/replication.py | 7 +++++-- synapse/federation/transport.py | 5 +++-- synapse/handlers/directory.py | 5 ++--- synapse/http/client.py | 9 +-------- tests/federation/test_federation.py | 5 +++-- tests/handlers/test_directory.py | 5 ++--- 6 files changed, 16 insertions(+), 20 deletions(-) diff --git a/synapse/federation/replication.py b/synapse/federation/replication.py index 96b82f00cb..5f96f79998 100644 --- a/synapse/federation/replication.py +++ b/synapse/federation/replication.py @@ -159,7 +159,8 @@ class ReplicationLayer(object): return defer.succeed(None) @log_function - def make_query(self, destination, query_type, args): + def make_query(self, destination, query_type, args, + retry_on_dns_fail=True): """Sends a federation Query to a remote homeserver of the given type and arguments. @@ -174,7 +175,9 @@ class ReplicationLayer(object): a Deferred which will eventually yield a JSON object from the response """ - return self.transport_layer.make_query(destination, query_type, args) + return self.transport_layer.make_query( + destination, query_type, args, retry_on_dns_fail=retry_on_dns_fail + ) @defer.inlineCallbacks @log_function diff --git a/synapse/federation/transport.py b/synapse/federation/transport.py index afc777ec9e..93296af204 100644 --- a/synapse/federation/transport.py +++ b/synapse/federation/transport.py @@ -193,13 +193,14 @@ class TransportLayer(object): @defer.inlineCallbacks @log_function - def make_query(self, destination, query_type, args): + def make_query(self, destination, query_type, args, retry_on_dns_fail): path = PREFIX + "/query/%s" % query_type response = yield self.client.get_json( destination=destination, path=path, - args=args + args=args, + retry_on_dns_fail=retry_on_dns_fail, ) defer.returnValue(response) diff --git a/synapse/handlers/directory.py b/synapse/handlers/directory.py index cec7737e09..a56830d520 100644 --- a/synapse/handlers/directory.py +++ b/synapse/handlers/directory.py @@ -18,7 +18,6 @@ from twisted.internet import defer from ._base import BaseHandler from synapse.api.errors import SynapseError -from synapse.http.client import MatrixHttpClient from synapse.api.events.room import RoomAliasesEvent import logging @@ -98,8 +97,8 @@ class DirectoryHandler(BaseHandler): query_type="directory", args={ "room_alias": room_alias.to_string(), - MatrixHttpClient.RETRY_DNS_LOOKUP_FAILURES: False - } + }, + retry_on_dns_fail=False, ) if result and "room_id" in result and "servers" in result: diff --git a/synapse/http/client.py b/synapse/http/client.py index e02cce5642..57b49355f2 100644 --- a/synapse/http/client.py +++ b/synapse/http/client.py @@ -183,7 +183,7 @@ class MatrixHttpClient(BaseHttpClient): defer.returnValue((response.code, body)) @defer.inlineCallbacks - def get_json(self, destination, path, args={}): + def get_json(self, destination, path, args={}, retry_on_dns_fail=True): """ Get's some json from the given host homeserver and path Args: @@ -203,13 +203,6 @@ class MatrixHttpClient(BaseHttpClient): """ logger.debug("get_json args: %s", args) - retry_on_dns_fail = True - if HttpClient.RETRY_DNS_LOOKUP_FAILURES in args: - # FIXME: This isn't ideal, but the interface exposed in get_json - # isn't comprehensive enough to give caller's any control over - # their connection mechanics. - retry_on_dns_fail = args.pop(HttpClient.RETRY_DNS_LOOKUP_FAILURES) - query_bytes = urllib.urlencode(args, True) logger.debug("Query bytes: %s Retry DNS: %s", args, retry_on_dns_fail) diff --git a/tests/federation/test_federation.py b/tests/federation/test_federation.py index bb17e9aafe..d95b9013a3 100644 --- a/tests/federation/test_federation.py +++ b/tests/federation/test_federation.py @@ -253,7 +253,7 @@ class FederationTestCase(unittest.TestCase): response = yield self.federation.make_query( destination="remote", query_type="a-question", - args={"one": "1", "two": "2"} + args={"one": "1", "two": "2"}, ) self.assertEquals({"your": "response"}, response) @@ -261,7 +261,8 @@ class FederationTestCase(unittest.TestCase): self.mock_http_client.get_json.assert_called_with( destination="remote", path="/_matrix/federation/v1/query/a-question", - args={"one": "1", "two": "2"} + args={"one": "1", "two": "2"}, + retry_on_dns_fail=True, ) @defer.inlineCallbacks diff --git a/tests/handlers/test_directory.py b/tests/handlers/test_directory.py index 0c31502dd4..e10a49a8ac 100644 --- a/tests/handlers/test_directory.py +++ b/tests/handlers/test_directory.py @@ -20,7 +20,6 @@ from twisted.internet import defer from mock import Mock from synapse.server import HomeServer -from synapse.http.client import MatrixHttpClient from synapse.handlers.directory import DirectoryHandler from synapse.storage.directory import RoomAliasMapping @@ -95,8 +94,8 @@ class DirectoryTestCase(unittest.TestCase): query_type="directory", args={ "room_alias": "#another:remote", - MatrixHttpClient.RETRY_DNS_LOOKUP_FAILURES: False - } + }, + retry_on_dns_fail=False, ) @defer.inlineCallbacks From ff553cc9dd4fe7c9203a7c4c414e5fa27348180a Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Thu, 2 Oct 2014 14:26:58 +0100 Subject: [PATCH 046/106] Alias lookups return a server list. --- docs/specification.rst | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/specification.rst b/docs/specification.rst index f45c75fca9..e0609f7074 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -190,7 +190,7 @@ Each room can also have multiple "Room Aliases", which looks like:: #room_alias:domain .. TODO - - Need to specify precise grammar for Room IDs + - Need to specify precise grammar for Room Aliases A room alias "points" to a room ID and is the human-readable label by which rooms are publicised and discovered. The room ID the alias is pointing to can @@ -200,6 +200,9 @@ over time to point to a different room ID. For this reason, Clients SHOULD resolve the room alias to a room ID once and then use that ID on subsequent requests. +When resolving a room alias the server will also respond with a list of servers +that are in the room that can be used to join via. + :: GET From 6860a18c12f9bedf59c70efca7ba2cda94f7b3dc Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Thu, 2 Oct 2014 14:27:35 +0100 Subject: [PATCH 047/106] Be less alarmist about not using an ID server. --- docs/specification.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/specification.rst b/docs/specification.rst index e0609f7074..26a9c17d98 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -241,8 +241,8 @@ authentication of the 3PID. Identity servers are also used to preserve the mapping indefinitely, by replicating the mappings across multiple ISes. Usage of an IS is not required in order for a client application to be part of -the Matrix ecosystem. However, by not using an IS, discovery of users is -greatly impacted. +the Matrix ecosystem. However, without one clients will not be able to look up +user IDs using 3PIDs. API Standards ------------- From cf3188352b898c91c9c3e0ef65c9fb120b00cc13 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Thu, 2 Oct 2014 14:28:22 +0100 Subject: [PATCH 048/106] Fix default value and key names. --- docs/specification.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/specification.rst b/docs/specification.rst index 26a9c17d98..e8790c2adc 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -721,7 +721,7 @@ options which can be set when creating a room: Description: A ``public`` visibility indicates that the room will be shown in the public room list. A ``private`` visibility will hide the room from the public room - list. Rooms default to ``public`` visibility if this key is not included. + list. Rooms default to ``private`` visibility if this key is not included. ``room_alias_name`` Type: @@ -2038,7 +2038,7 @@ For state updates: Description: The asserted power level of the user performing the update. -``min_update`` +``required_power_level`` Type: Integer Description: @@ -2056,7 +2056,7 @@ For state updates: Description: The PDU id of the update this replaces. -``user`` +``user_id`` Type: String Description: From 918e71adb7c645ee6edf3e796204f916cee26a42 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Thu, 2 Oct 2014 14:31:21 +0100 Subject: [PATCH 049/106] Don't use spaces in example room alias --- docs/specification.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/specification.rst b/docs/specification.rst index e8790c2adc..b5bfce59e5 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -774,7 +774,7 @@ Example:: { "visibility": "public", - "room_alias_name": "the pub", + "room_alias_name": "thepub", "name": "The Grand Duke Pub", "topic": "All about happy hour" } From f368ad946ea987abfe5d7fc0d9f10971f8fecaef Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Thu, 2 Oct 2014 14:33:26 +0100 Subject: [PATCH 050/106] m.room.ops_levels includes redact_level --- docs/specification.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/specification.rst b/docs/specification.rst index b5bfce59e5..732b50c694 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -792,7 +792,7 @@ includes: - ``m.room.send_event_level`` : The power level required in order to send a message in this room. - ``m.room.ops_level`` : The power level required in order to kick or ban a - user from the room. + user from the room or redact an event in the room. See `Room Events`_ for more information on these events. @@ -1316,7 +1316,7 @@ prefixed with ``m.`` Type: State event JSON format: - ``{ "ban_level": , "kick_level": }`` + ``{ "ban_level": , "kick_level": , "redact_level": }`` Example: ``{ "ban_level": 5, "kick_level": 5 }`` Description: From 1561ef56ed6b514aca6c21f2151af5ba892a69d2 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Thu, 2 Oct 2014 14:34:13 +0100 Subject: [PATCH 051/106] Remove note about assymetry of having left a room. Currently, if you leave a room you still appear in the members list. This is basically a bug with the current implementation/spec, rather than something that should happen. --- docs/specification.rst | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/docs/specification.rst b/docs/specification.rst index 732b50c694..081d949b41 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -947,11 +947,7 @@ directly by sending the following request to See the `Room events`_ section for more information on ``m.room.member``. Once a user has left a room, that room will no longer appear on the -|initialSync|_ API. Be aware that leaving a room is not equivalent to have -never been in that room. A user who has previously left a room still maintains -some residual state in that room. Their membership state will be marked as -``leave``. This contrasts with a user who has *never been invited or joined to -that room* who will not have any membership state for that room. +|initialSync|_ API. If all members in a room leave, that room becomes eligible for deletion. From b9cdc443d7acdd1f8095878e3c24b859f82ea31e Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Thu, 2 Oct 2014 14:37:30 +0100 Subject: [PATCH 052/106] Fix pyflakes errors --- synapse/handlers/register.py | 2 +- synapse/http/client.py | 10 ++-------- 2 files changed, 3 insertions(+), 9 deletions(-) diff --git a/synapse/handlers/register.py b/synapse/handlers/register.py index 266495056e..df562aa762 100644 --- a/synapse/handlers/register.py +++ b/synapse/handlers/register.py @@ -176,7 +176,7 @@ class RegistrationHandler(BaseHandler): @defer.inlineCallbacks def _bind_threepid(self, creds, mxid): - httpCli = PlainHttpClient(self.hs) + httpCli = IdentityServerHttpClient(self.hs) data = yield httpCli.post_urlencoded_get_json( creds['idServer'], "/_matrix/identity/api/v1/3pid/bind", diff --git a/synapse/http/client.py b/synapse/http/client.py index 57b49355f2..5c2fbd1f87 100644 --- a/synapse/http/client.py +++ b/synapse/http/client.py @@ -236,9 +236,6 @@ class IdentityServerHttpClient(BaseHttpClient): @defer.inlineCallbacks def post_urlencoded_get_json(self, destination, path, args={}): - if destination in _destination_mappings: - destination = _destination_mappings[destination] - logger.debug("post_urlencoded_get_json args: %s", args) query_bytes = urllib.urlencode(args, True) @@ -246,7 +243,7 @@ class IdentityServerHttpClient(BaseHttpClient): destination.encode("ascii"), "POST", path.encode("ascii"), - producer=FileBodyProducer(StringIO(urllib.urlencode(args))), + producer=FileBodyProducer(StringIO(query_bytes)), headers_dict={ "Content-Type": ["application/x-www-form-urlencoded"] } @@ -266,16 +263,13 @@ class CaptchaServerHttpClient(MatrixHttpClient): @defer.inlineCallbacks def post_urlencoded_get_raw(self, destination, path, accept_partial=False, args={}): - if destination in _destination_mappings: - destination = _destination_mappings[destination] - query_bytes = urllib.urlencode(args, True) response = yield self._create_request( destination.encode("ascii"), "POST", path.encode("ascii"), - producer=FileBodyProducer(StringIO(urllib.urlencode(args))), + producer=FileBodyProducer(StringIO(query_bytes)), headers_dict={ "Content-Type": ["application/x-www-form-urlencoded"] } From 82e278029c92c2460976142bb2aadb3b9dcdfa93 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Thu, 2 Oct 2014 14:38:22 +0100 Subject: [PATCH 053/106] Remove incorrect reasons for empty PDU lists. --- docs/specification.rst | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/docs/specification.rst b/docs/specification.rst index 081d949b41..dcb99d3792 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -1949,9 +1949,7 @@ is another list containing the EDUs. This key may be entirely absent if there are no EDUs to transfer. (* Normally the PDU list will be non-empty, but the server should cope with -receiving an "empty" transaction, as this is useful for informing peers of -other transaction IDs they should be aware of. This effectively acts as a push -mechanism to encourage peers to continue to replicate content.) +receiving an "empty" transaction.) PDUs and EDUs ------------- From 036333412d498b574075735ac5a49ce17036b11d Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Thu, 2 Oct 2014 14:38:53 +0100 Subject: [PATCH 054/106] Add todo notes --- docs/specification.rst | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/docs/specification.rst b/docs/specification.rst index dcb99d3792..891470d5fb 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -849,6 +849,7 @@ Joining rooms ------------- .. TODO-doc kegan - TODO: What does the home server have to do to join a user to a room? + See SPEC-30. Users need to join a room in order to send and receive events in that room. A user can join a room by making a request to |/join/|_ with:: @@ -1389,6 +1390,10 @@ prefixed with ``m.`` m.room.message msgtypes ----------------------- + +.. TODO-spec + How a client should handle unknown message types. + Each ``m.room.message`` MUST have a ``msgtype`` key which identifies the type of message being sent. Each type has their own required and optional keys, as outlined below: From de38f54f22cf5d3fecbcf227fcd43744345c8817 Mon Sep 17 00:00:00 2001 From: "Paul \"LeoNerd\" Evans" Date: Thu, 2 Oct 2014 17:18:32 +0100 Subject: [PATCH 055/106] Document the Profile system --- docs/specification.rst | 109 ++++++++++++++++++++++++++++++++++++++--- 1 file changed, 101 insertions(+), 8 deletions(-) diff --git a/docs/specification.rst b/docs/specification.rst index 0a421e9e38..f169cf02ce 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -1813,14 +1813,8 @@ Profiles .. NOTE:: This section is a work in progress. -.. TODO-doc +.. TODO-spec - Metadata extensibility - - Changing profile info generates m.presence events ("presencelike") - - keys on m.presence are optional, except presence which is required - - m.room.member is populated with the current displayname at that point in time. - - That is added by the HS, not you. - - Display name changes also generates m.room.member with displayname key f.e. room - the user is in. Internally within Matrix users are referred to by their user ID, which is typically a compact unique identifier. Profiles grant users the ability to see @@ -1831,7 +1825,106 @@ age or location. A Profile consists of a display name, an avatar picture, and a set of other metadata fields that the user may wish to publish (email address, phone numbers, website URLs, etc...). This specification puts no requirements on the -display name other than it being a valid unicode string. +display name other than it being a valid unicode string. Avatar images are not +stored directly; instead the home server stores an ``http``-scheme URL where +clients may fetch it from. + +Client API +---------- +The client API for profile management consists of the following REST calls. + +Fetching a user account displayname:: + + GET $PREFIX/profile/:user_id/displayname + + Returned content: JSON object containing the following keys: + displayname: string of freeform text + +This call may be used to fetch the user's own displayname or to query the name +of other users; either locally or on remote systems hosted on other home +servers. + +Setting a new displayname:: + + PUT $PREFIX/profile/:user_id/displayname + + Content: JSON object containing the following keys: + displayname: string of freeform text + +Fetching a user account avatar URL:: + + GET $PREFIX/profile/:user_id/avatar_url + + Returned content: JSON object containing the following keys: + avatar_url: string containing an http-scheme URL + +As with displayname, this call may be used to fetch either the user's own, or +other users' avatar URL. + +Setting a new avatar URL:: + + PUT $PREFIX/profile/:user_id/avatar_url + + Content: JSON object containing the following keys: + avatar_url: string containing an http-scheme URL + +Fetching combined account profile information:: + + GET $PREFIX/profile/:user_id + + Returned content: JSON object containing the following keys: + displayname: string of freeform text + avatar_url: string containing an http-scheme URL + +At the current time, this API simply returns the displayname and avatar URL +information, though it is intended to return more fields about the user's +profile once they are defined. Client implementations should take care not to +expect that these are the only two keys returned as future versions of this +specification may yield more keys here. + +Server API +---------- +The server API for profiles is based entirely on the following Federation +Queries. There are no additional EDU or PDU types involved, other than the +implicit ``m.presence`` and ``m.room.member`` events (see section below). + +Querying profile information:: + + Query type: profile + + Arguments: + user_id: the ID of the user whose profile to return + field: (optional) string giving a field name + + Returns: JSON object containing the following keys: + displayname: string of freeform text + avatar_url: string containing an http-scheme URL + +If the query contains the optional ``field`` key, it should give the name of a +result field. If such is present, then the result should contain only a field +of that name, with no others present. If not, the result should contain as much +of the user's profile as the home server has available and can make public. + +Events on Change of Profile Information +--------------------------------------- +Because the profile displayname and avatar information are likely to be used in +many places of a client's display, changes to these fields cause an automatic +propagation event to occur, informing likely-interested parties of the new +values. This change is conveyed using two separate mechanisms: + + - a ``m.room.member`` event is sent to every room the user is a member of, + to update the ``displayname`` and ``avatar_url``. + - a presence status update is sent, again containing the new values of the + ``displayname`` and ``avatar_url`` keys, in addition to the required + ``presence`` key containing the current presence state of the user. + +Both of these should be done automatically by the home server when a user +successfully changes their displayname or avatar URL fields. + +Additionally, when home servers emit room membership events for their own +users, they should include the displayname and avatar URL fields in these +events so that clients already have these details to hand, and do not have to +perform extra roundtrips to query it. Identity From bc1d685a8c32f4b4f0f94e58fed94ed3a8a8beb8 Mon Sep 17 00:00:00 2001 From: "Paul \"LeoNerd\" Evans" Date: Thu, 2 Oct 2014 18:00:31 +0100 Subject: [PATCH 056/106] Remove TODO note about VoIP events as they now have their own entire section --- docs/specification.rst | 3 --- 1 file changed, 3 deletions(-) diff --git a/docs/specification.rst b/docs/specification.rst index d07a667a5e..b6cb07058d 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -1182,9 +1182,6 @@ Room Events .. NOTE:: This section is a work in progress. -.. TODO-doc dave? - - voip events? - This specification outlines several standard event types, all of which are prefixed with ``m.`` From 1aa5cc917874c150e3e4af2483fe86213a2a067f Mon Sep 17 00:00:00 2001 From: "Paul \"LeoNerd\" Evans" Date: Thu, 2 Oct 2014 18:11:04 +0100 Subject: [PATCH 057/106] Federation protocol URLs should have an H2 heading, not H1 --- docs/specification.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/specification.rst b/docs/specification.rst index b6cb07058d..dfaf460175 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -2203,7 +2203,7 @@ destination home server names, and the actual nested content. Protocol URLs -============= +------------- .. WARNING:: This section may be misleading or inaccurate. From 7e1437c6b17c5139303f330dc92f55847b6f3807 Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Fri, 3 Oct 2014 10:34:29 +0100 Subject: [PATCH 058/106] Add more information to TODOs. Explain m.room.join_rules. --- docs/specification.rst | 33 +++++++++++++++++++++------------ 1 file changed, 21 insertions(+), 12 deletions(-) diff --git a/docs/specification.rst b/docs/specification.rst index dfaf460175..a58ec6645f 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -847,9 +847,8 @@ defined in the following state events: Joining rooms ------------- -.. TODO-doc kegan - - TODO: What does the home server have to do to join a user to a room? - See SPEC-30. +.. TODO-doc What does the home server have to do to join a user to a room? + - See SPEC-30. Users need to join a room in order to send and receive events in that room. A user can join a room by making a request to |/join/|_ with:: @@ -886,20 +885,21 @@ received an invite. Inviting users -------------- -.. TODO-doc kegan - - Can invite users to a room if the room config key TODO is set to TODO. Must have required power level. +.. TODO-doc Invite-join dance - Outline invite join dance. What is it? Why is it required? How does it work? - What does the home server have to do? - - TODO: In what circumstances will direct member editing NOT be equivalent to ``/invite``? The purpose of inviting users to a room is to notify them that the room exists so they can choose to become a member of that room. Some rooms require that all users who join a room are previously invited to it (an "invite-only" room). Whether a given room is an "invite-only" room is determined by the room config -key ``TODO``. It can have one of the following values: +key ``m.room.join_rules``. It can have one of the following values: - - TODO Room config invite only value explanation - - TODO Room config free-to-join value explanation +``public`` + This room is free for anyone to join without an invite. + +``invite`` + This room can only be joined if you were invited. Only users who have a membership state of ``join`` in a room can invite new users to said room. The person being invited must not be in the ``join`` state @@ -924,9 +924,14 @@ See the `Room events`_ section for more information on ``m.room.member``. Leaving rooms ------------- -.. TODO-spec kegan - - TODO: Grace period before deletion? - - TODO: Under what conditions should a room NOT be purged? +.. TODO-spec - HS deleting rooms they are no longer a part of. Not implemented. + - This is actually Very Tricky. If all clients a HS is serving leave a room, + the HS will no longer get any new events for that room, because the servers + who get the events are determined on the *membership list*. There should + probably be a way for a HS to lurk on a room even if there are 0 of their + members in the room. + - Grace period before deletion? + - Under what conditions should a room NOT be purged? A user can leave a room to stop receiving events for that room. A user must @@ -1078,6 +1083,10 @@ presence events will also be returned. There are two APIs provided: .. TODO-doc kegan - TODO: JSON response format for both types - TODO: when would you use global? when would you use scoped? + - Room-scoped initial sync is Very Tricky because typically people would + want to sync the room then listen for any new content from that point + onwards. The event stream cannot do this for a single room currently. + Not sure if room-scoped initial sync should be included at this time. Getting events for a room ------------------------- From ba11afafb908fa712aa347e956fec2af9737ad2c Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Fri, 3 Oct 2014 14:39:58 +0100 Subject: [PATCH 059/106] Flesh out room alias section. --- docs/specification.rst | 38 +++++++++++++++++++++++++++++--------- 1 file changed, 29 insertions(+), 9 deletions(-) diff --git a/docs/specification.rst b/docs/specification.rst index a58ec6645f..e6b85dba33 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -705,9 +705,6 @@ Rooms Creation -------- -.. TODO kegan - - TODO-spec: Key for invite these users? - To create a room, a client has to use the |createRoom|_ API. There are various options which can be set when creating a room: @@ -801,12 +798,35 @@ Modifying aliases .. NOTE:: This section is a work in progress. -.. TODO-doc kegan - - path to edit aliases - - PUT /directory/room/ { room_id : foo } - - GET /directory/room/ { room_id : foo, servers: [a.com, b.com] } - - format when retrieving list of aliases. NOT complete list. - - format for adding/removing aliases. +Room aliases can be created by sending a ``PUT /directory/room/``:: + + { + "room_id": + } + +They can be deleted by sending a ``DELETE /directory/room/`` with +no content. Only some privileged users may be able to delete room aliases, e.g. +server admins, the creator of the room alias, etc. This specification does not +outline the privilege level required for deleting room aliases. + +Rooms store a *partial* list of room aliases via the ``m.room.aliases`` state +event. This alias list is partial because it cannot guarantee that the alias +list is in any way accurate or up-to-date, as room aliases can point to +different room IDs over time. Crucially, the aliases in this event are +**purely informational** and SHOULD NOT be treated as accurate. They SHOULD +be checked before they are used or shared with another user. If a room +appears to have a room alias of ``#alias:example.com``, this SHOULD be checked +to make sure that the room's ID matches the ``room_id`` returned from the +request. + +Room aliases can be checked in the same way they are resolved; by sending a +``GET /directory/room/``:: + + { + "room_id": , + "servers": [ , , ] + } + Permissions ----------- From ca0e8dedfba6dd643e9f996baca052b7a0aac401 Mon Sep 17 00:00:00 2001 From: "Paul \"LeoNerd\" Evans" Date: Fri, 3 Oct 2014 14:45:42 +0100 Subject: [PATCH 060/106] Clarify how m.room.alias event works --- docs/specification.rst | 30 ++++++++++++++++++++++++++---- 1 file changed, 26 insertions(+), 4 deletions(-) diff --git a/docs/specification.rst b/docs/specification.rst index a58ec6645f..d8e7547010 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -1338,10 +1338,32 @@ prefixed with ``m.`` Example: ``{ "aliases": ["#foo:example.com"] }`` Description: - A server `may` inform the room that it has added or removed an alias for - the room. This is purely for informational purposes and may become stale. - Clients `should` check that the room alias is still valid before using it. - The ``state_key`` of the event is the homeserver which owns the room alias. + This event is sent by a homeserver directly to inform of changes to the + list of aliases it knows about for that room. As a special-case, the + ``state_key`` of the event is the homeserver which owns the room alias. + For example, an event might look like:: + + { + "type": "m.room.aliases", + "event_id": "012345678ab", + "room_id": "!xAbCdEfG:example.com", + "state_key": "example.com", + "content": { + "aliases": ["#foo:example.com"] + } + } + + The event contains the full list of aliases now stored by the home server + that emitted it; additions or deletions are not explicitly mentioned as + being such. The entire set of known aliases for the room is then the union + of the individual lists declared by all such keys, one from each home + server holding at least one alias. + + Clients `should` check the validity of any room alias given in this list + before presenting it to the user as trusted fact. The lists given by this + event should be considered simply as advice on which aliases might exist, + for which the client can perform the lookup to confirm whether it receives + the correct room ID. ``m.room.message`` Summary: From 02a44664b90a81f4a7d880fdeef1262cbabe4168 Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Fri, 3 Oct 2014 17:38:30 +0100 Subject: [PATCH 061/106] More spec work. --- docs/specification.rst | 25 +++++++++++-------------- 1 file changed, 11 insertions(+), 14 deletions(-) diff --git a/docs/specification.rst b/docs/specification.rst index f2e973de33..eff9dcd03d 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -216,10 +216,6 @@ that are in the room that can be used to join via. | #golf >> !wfeiofh:sport.com | | #bike >> !4rguxf:matrix.org | |________________________________| - -.. TODO kegan - - show the actual API rather than pseudo-API? - Identity -------- @@ -793,8 +789,8 @@ includes: See `Room Events`_ for more information on these events. -Modifying aliases ------------------ +Room aliases +------------ .. NOTE:: This section is a work in progress. @@ -834,9 +830,6 @@ Permissions This section is a work in progress. .. TODO-doc kegan - - What is a power level? How do they work? Defaults / required levels for X. How do they change - as people join and leave rooms? What do you do if you get a clash? Examples. - - List all actions which use power levels (sending msgs, inviting users, banning people, etc...) - Room config - what is the event and what are the keys/values and explanations for them. Link through to respective sections where necessary. How does this tie in with permissions, e.g. give example of creating a read-only room. @@ -847,12 +840,15 @@ action in a room a user must have a suitable power level. Power levels for users are defined in ``m.room.power_levels``, where both a default and specific users' power levels can be set. By default all users have a power level of 0, other than the room creator whose power level defaults to -100. Power levels for users are tracked per-room even if the user is not -present in the room. +100. Users can grant other users increased power levels up to their own power +level. For example, user A with a power level of 50 could increase the power +level of user B to a maximum of level 50. Power levels for users are tracked +per-room even if the user is not present in the room. State events may contain a ``required_power_level`` key, which indicates the minimum power a user must have before they can update that state key. The only -exception to this is when a user leaves a room. +exception to this is when a user leaves a room, which revokes the user's right +to update state events in that room. To perform certain actions there are additional power level requirements defined in the following state events: @@ -861,8 +857,9 @@ defined in the following state events: events. Defaults to 50. - ``m.room.add_state_level`` defines the minimum level for adding new state, rather than updating existing state. Defaults to 50. -- ``m.room.ops_level`` defines the minimum levels to ban and kick other users. - This defaults to a kick and ban levels of 50 each. +- ``m.room.ops_level`` defines the minimum ``ban_level`` and ``kick_level`` to + ban and kick other users respectively. This defaults to a kick and ban levels + of 50 each. Joining rooms From 78a3f43d9d6be03c16ea478671e45de7d3a7dcea Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Mon, 6 Oct 2014 09:23:19 +0100 Subject: [PATCH 062/106] swagger: Added DELETE method for directory server. --- .../swagger_matrix/api-docs-directory | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/docs/client-server/swagger_matrix/api-docs-directory b/docs/client-server/swagger_matrix/api-docs-directory index ce12be8c96..5dda580658 100644 --- a/docs/client-server/swagger_matrix/api-docs-directory +++ b/docs/client-server/swagger_matrix/api-docs-directory @@ -48,6 +48,22 @@ "paramType": "body" } ] + }, + { + "method": "DELETE", + "summary": "Removes a mapping of room alias to room ID.", + "notes": "Only privileged users can perform this action.", + "type": "void", + "nickname": "remove_room_alias", + "parameters": [ + { + "name": "roomAlias", + "description": "The room alias to remove.", + "required": true, + "type": "string", + "paramType": "path" + } + ] } ] } From 51276c60bf113400f38299fc813511642f60d510 Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Mon, 6 Oct 2014 10:32:04 +0100 Subject: [PATCH 063/106] Add information about the initialSync API. Outline and describe the keys from the initial sync API. Hide room-scoped initial sync API for now as it is not implemented and needs more thought before it can be specced. --- docs/specification.rst | 54 +++++++++++++++++++++++++++++++++++------- 1 file changed, 46 insertions(+), 8 deletions(-) diff --git a/docs/specification.rst b/docs/specification.rst index eff9dcd03d..edd8f5dbfb 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -1089,21 +1089,59 @@ When a client logs in, they may have a list of rooms which they have already joined. These rooms may also have a list of events associated with them. The purpose of 'syncing' is to present the current room and event information in a convenient, compact manner. The events returned are not limited to room events; -presence events will also be returned. There are two APIs provided: +presence events will also be returned. A single syncing API is provided: - |initialSync|_ : A global sync which will present room and event information for all rooms the user has joined. +.. TODO-spec room-scoped initial sync - |/rooms//initialSync|_ : A sync scoped to a single room. Presents room and event information for this room only. + - Room-scoped initial sync is Very Tricky because typically people would + want to sync the room then listen for any new content from that point + onwards. The event stream cannot do this for a single room currently. + As a result, commenting room-scoped initial sync at this time. -.. TODO-doc kegan - - TODO: JSON response format for both types - - TODO: when would you use global? when would you use scoped? - - Room-scoped initial sync is Very Tricky because typically people would - want to sync the room then listen for any new content from that point - onwards. The event stream cannot do this for a single room currently. - Not sure if room-scoped initial sync should be included at this time. +The |initialSync|_ API contains the following keys: + +``presence`` + Description: + Contains a list of presence information for users the client is interested + in. + Format: + A JSON array of ``m.presence`` events. + +``end`` + Description: + Contains an event stream token which can be used with the `Event Stream`_. + Format: + A string containing the event stream token. + +``rooms`` + Description: + Contains a list of room information for all rooms the client has joined, + and limited room information on rooms the client has been invited to. + Format: + A JSON array containing Room Information JSON objects. + +Room Information: + Description: + Contains all state events for the room, along with a limited amount of + the most recent non-state events, configured via the ``limit`` query + parameter. Also contains additional keys with room metadata, such as the + ``room_id`` and the client's ``membership`` to the room. + Format: + A JSON object with the following keys: + ``room_id`` + A string containing the ID of the room being described. + ``membership`` + A string representing the client's membership status in this room. + ``messages`` + An event stream JSON object containing a ``chunk`` of recent non-state + events, along with an ``end`` token. *NB: The name of this key will be + changed in a later version.* + ``state`` + A JSON array containing all the current state events for this room. Getting events for a room ------------------------- From 94982392bef6654199160732944257c4117c7a40 Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Mon, 6 Oct 2014 12:41:48 +0100 Subject: [PATCH 064/106] Clarify room permission / power level information. --- docs/specification.rst | 35 +++++++++++++++++++---------------- 1 file changed, 19 insertions(+), 16 deletions(-) diff --git a/docs/specification.rst b/docs/specification.rst index edd8f5dbfb..eea892c900 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -829,21 +829,24 @@ Permissions .. NOTE:: This section is a work in progress. -.. TODO-doc kegan - - Room config - what is the event and what are the keys/values and explanations for them. - Link through to respective sections where necessary. How does this tie in with permissions, e.g. - give example of creating a read-only room. - Permissions for rooms are done via the concept of power levels - to do any -action in a room a user must have a suitable power level. +action in a room a user must have a suitable power level. Power levels are +stored as state events in a given room. Power levels for users are defined in ``m.room.power_levels``, where both a -default and specific users' power levels can be set. By default all users have -a power level of 0, other than the room creator whose power level defaults to -100. Users can grant other users increased power levels up to their own power -level. For example, user A with a power level of 50 could increase the power -level of user B to a maximum of level 50. Power levels for users are tracked -per-room even if the user is not present in the room. +default and specific users' power levels can be set:: + + { + "": , + "": , + "default": 0 + } + +By default all users have a power level of 0, other than the room creator whose +power level defaults to 100. Users can grant other users increased power levels +up to their own power level. For example, user A with a power level of 50 could +increase the power level of user B to a maximum of level 50. Power levels for +users are tracked per-room even if the user is not present in the room. State events may contain a ``required_power_level`` key, which indicates the minimum power a user must have before they can update that state key. The only @@ -853,10 +856,10 @@ to update state events in that room. To perform certain actions there are additional power level requirements defined in the following state events: -- ``m.room.send_event_level`` defines the minimum level for sending non-state - events. Defaults to 50. -- ``m.room.add_state_level`` defines the minimum level for adding new state, - rather than updating existing state. Defaults to 50. +- ``m.room.send_event_level`` defines the minimum ``level`` for sending + non-state events. Defaults to 50. +- ``m.room.add_state_level`` defines the minimum ``level`` for adding new + state, rather than updating existing state. Defaults to 50. - ``m.room.ops_level`` defines the minimum ``ban_level`` and ``kick_level`` to ban and kick other users respectively. This defaults to a kick and ban levels of 50 each. From aaf1d499bfb648b8fa24eb9de0ca9772b80823a3 Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Mon, 6 Oct 2014 13:18:52 +0100 Subject: [PATCH 065/106] Add more section headings. --- docs/specification.rst | 42 +++++++++++++++++++++++++++++++++++++----- 1 file changed, 37 insertions(+), 5 deletions(-) diff --git a/docs/specification.rst b/docs/specification.rst index eea892c900..de3d04f244 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -2378,6 +2378,15 @@ SRV Records .. TODO-doc - Why it is needed +State Conflict Resolution +------------------------- +.. NOTE:: + This section is a work in progress. + +.. TODO-doc + - How do conflicts arise (diagrams?) + - How are they resolved (incl tie breaks) + - How does this work with deleting current state Security ======== @@ -2385,6 +2394,29 @@ Security .. NOTE:: This section is a work in progress. +Server-Server Authentication +---------------------------- + +.. TODO-doc + - Why is this needed. + - High level overview of process. + - Transaction/PDU signing + - How does this work with redactions? (eg hashing required keys only) + +End-to-End Encryption +--------------------- + +.. TODO-doc + - Why is this needed. + - Overview of process + - Implementation + +Lawful Interception +------------------- + +Key Escrow Servers +~~~~~~~~~~~~~~~~~~ + Threat Model ------------ @@ -2531,10 +2563,6 @@ have to wait in milliseconds before they can try again. - Surely we should recommend an algorithm for the rate limiting, rather than letting every homeserver come up with their own idea, causing totally unpredictable performance over federated rooms? - - crypto (s-s auth) - - E2E - - Lawful intercept + Key Escrow - TODO Mark Policy Servers @@ -2543,7 +2571,11 @@ Policy Servers This section is a work in progress. .. TODO-spec - We should mention them in the Architecture section at least... + We should mention them in the Architecture section at least: how they fit + into the picture. + +Enforcing policies +------------------ Content repository From 3ef2c946d58034173f4fb54b4708ac108f1cf3f7 Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Mon, 6 Oct 2014 14:52:46 +0100 Subject: [PATCH 066/106] Update JSFiddles/how-to to support the new registration format. --- docs/client-server/howto.rst | 2 +- jsfiddles/example_app/demo.js | 2 +- jsfiddles/register_login/demo.js | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/client-server/howto.rst b/docs/client-server/howto.rst index ec941edddd..9913e8db1e 100644 --- a/docs/client-server/howto.rst +++ b/docs/client-server/howto.rst @@ -31,7 +31,7 @@ Registration The aim of registration is to get a user ID and access token which you will need when accessing other APIs:: - curl -XPOST -d '{"user_id":"example", "password":"wordpass"}' "http://localhost:8008/_matrix/client/api/v1/register" + curl -XPOST -d '{"user":"example", "password":"wordpass", "type":"m.login.password"}' "http://localhost:8008/_matrix/client/api/v1/register" { "access_token": "QGV4YW1wbGU6bG9jYWxob3N0.AqdSzFmFYrLrTmteXc", diff --git a/jsfiddles/example_app/demo.js b/jsfiddles/example_app/demo.js index ad79fcca26..13c9c2b339 100644 --- a/jsfiddles/example_app/demo.js +++ b/jsfiddles/example_app/demo.js @@ -110,7 +110,7 @@ $('.register').live('click', function() { url: "http://localhost:8008/_matrix/client/api/v1/register", type: "POST", contentType: "application/json; charset=utf-8", - data: JSON.stringify({ user_id: user, password: password }), + data: JSON.stringify({ user: user, password: password, type: "m.login.password" }), dataType: "json", success: function(data) { onLoggedIn(data); diff --git a/jsfiddles/register_login/demo.js b/jsfiddles/register_login/demo.js index fffa9e0551..2e6957b631 100644 --- a/jsfiddles/register_login/demo.js +++ b/jsfiddles/register_login/demo.js @@ -14,7 +14,7 @@ $('.register').live('click', function() { url: "http://localhost:8008/_matrix/client/api/v1/register", type: "POST", contentType: "application/json; charset=utf-8", - data: JSON.stringify({ user_id: user, password: password }), + data: JSON.stringify({ user: user, password: password, type: "m.login.password" }), dataType: "json", success: function(data) { showLoggedIn(data); From c72074b48e1714c2c41f71b0f81474ecafa29144 Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Mon, 6 Oct 2014 14:57:26 +0100 Subject: [PATCH 067/106] Clarify how-to some more. --- docs/client-server/howto.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/client-server/howto.rst b/docs/client-server/howto.rst index 9913e8db1e..37346224af 100644 --- a/docs/client-server/howto.rst +++ b/docs/client-server/howto.rst @@ -39,14 +39,15 @@ when accessing other APIs:: "user_id": "@example:localhost" } -NB: If a ``user_id`` is not specified, one will be randomly generated for you. +NB: If a ``user`` is not specified, one will be randomly generated for you. If you do not specify a ``password``, you will be unable to login to the account if you forget the ``access_token``. Implementation note: The matrix specification does not enforce how users register with a server. It just specifies the URL path and absolute minimum keys. The reference home server uses a username/password to authenticate user, -but other home servers may use different methods. +but other home servers may use different methods. This is why you need to +specify the ``type`` of method. Login ----- From 2fc00508fb23800a3d4494680947a7f402910dd1 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Mon, 6 Oct 2014 17:34:44 +0100 Subject: [PATCH 068/106] Add quick and dirty doc about state resolution --- docs/state_resolution.rst | 51 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 docs/state_resolution.rst diff --git a/docs/state_resolution.rst b/docs/state_resolution.rst new file mode 100644 index 0000000000..fec290dd79 --- /dev/null +++ b/docs/state_resolution.rst @@ -0,0 +1,51 @@ +State Resolution +================ +This section describes why we need state resolution and how it works. + + +Motivation +----------- +We want to be able to associate some shared state with rooms, e.g. a room name +or members list. This is done by having a current state dictionary that maps +from the pair event type and state key to an event. + +However, since the servers involved in the room are distributed we need to be +able to handle the case when two (or more) servers try and update the state at +the same time. This is done via the state resolution algorithm. + + +State Tree +------------ +State events contain a reference to the state it is trying to replace. These +relations form a tree where the current state is one of the leaf nodes. + +Note that state events are events, and so are part of the PDU graph. Thus we +can be sure that (modulo the internet being particularly broken) we will see +all state events eventually. + + +Algorithm requirements +---------------------- +We want the algorithm to have the following properties: +- Since we aren't guaranteed what order we receive state events in, except that + we see parents before children, the state resolution algorithm must not depend + on the order and must always come to the same result. +- If we receive a state event whose parent is the current state, then the + algorithm will select it. +- The algorithm does not depend on internal state, ensuring all servers should + come to the same decision. + +These three properties mean it is enough to keep track of the current state and +compare it with any new proposed state, rather than having to keep track of all +the leafs of the tree and recomputing across the entire state tree. + + +Current Implementation +---------------------- +The current implementation works as follows: Upon receipt of a newly proposed +state change we first find the common ancestor. Then we take the maximum +across each branch of the users' power levels, if one is higher then it is +selected as the current state. Otherwise, we check if one chain is longer than +the other, if so we choose that one. If that also fails, then we concatenate +all the pdu ids and take a SHA1 hash and compare them to select a common +ancestor. From 9ac53ef8cfe595b5606b97c52fb4aaf6fb35e9df Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Tue, 7 Oct 2014 11:38:02 +0100 Subject: [PATCH 069/106] SPEC-3: First hack at defining some of the various event related concepts --- docs/definitions.rst | 53 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 docs/definitions.rst diff --git a/docs/definitions.rst b/docs/definitions.rst new file mode 100644 index 0000000000..b0f95ae9d7 --- /dev/null +++ b/docs/definitions.rst @@ -0,0 +1,53 @@ +Definitions +=========== + +# *Event* -- A JSON object that represents a piece of information to be +distributed to the the room. The object includes a payload and metadata, +including a `type` used to indicate what the payload is for and how to process +them. It also includes one or more references to previous events. + +# *Event graph* -- Events and their references to previous events form a +directed acyclic graph. All events must be a descendant of the first event in a +room, except for a few special circumstances. + +# *State event* -- A state event is an event that has a non-null string valued +`state_key` field. It may also include a `prev_state` key referencing exactly +one state event with the same type and state key, in the same event graph. + +# *State tree* -- A state tree is a tree formed by a collection of state events +that have the same type and state key (all in the same event graph. + +# *State resolution algorithm* -- An algorithm that takes a state tree as input +and selects a single leaf node. + +# *Current state event* -- The leaf node of a given state tree that has been +selected by the state resolution algorithm. + +# *Room state* / *state dictionary* / *current state* -- A mapping of the pair +(event type, state key) to the current state event for that pair. + +# *Room* -- An event graph and its associated state dictionary. An event is in +the room if it is part of the event graph. + +# *Topological ordering* -- The partial ordering that can be extracted from the +event graph due to it being a DAG. + +(The state definitions are purposely slightly ill-defined, since if we allow +deleting events we might end up with multiple state trees for a given event +type and state key pair.) + +Federation specific +------------------- +# *(Persistent data unit) PDU* -- An encoding of an event for distribution of +the server to server protocol. + +# *(Ephemeral data unit) EDU* -- A piece of information that is sent between +servers and doesn't encode an event. + +Client specific +--------------- +# *Child events* -- Events that reference a single event in the same room +independently of the event graph. + +# *Collapsed events* -- Events that have all child events that reference it +included in the JSON object. From 917af4705bcf425f04a5f17f61edfda00651017b Mon Sep 17 00:00:00 2001 From: "Paul \"LeoNerd\" Evans" Date: Tue, 7 Oct 2014 16:22:57 +0100 Subject: [PATCH 070/106] Clarify that room alias domain names will be server-scoped; nonlocal edits are unliekly to work but nonlocal lookups will --- docs/specification.rst | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/docs/specification.rst b/docs/specification.rst index de3d04f244..84722aa281 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -805,6 +805,11 @@ no content. Only some privileged users may be able to delete room aliases, e.g. server admins, the creator of the room alias, etc. This specification does not outline the privilege level required for deleting room aliases. +As room aliases are scoped to a particular home server domain name, it is +likely that a home server will reject attempts to maintain aliases on other +domain names. This specification does not provide a way for home servers to +send update requests to other servers. + Rooms store a *partial* list of room aliases via the ``m.room.aliases`` state event. This alias list is partial because it cannot guarantee that the alias list is in any way accurate or up-to-date, as room aliases can point to @@ -823,6 +828,9 @@ Room aliases can be checked in the same way they are resolved; by sending a "servers": [ , , ] } +Home servers can respond to resolve requests for aliases on other domains than +their own by using the federation API to ask other domain name home servers. + Permissions ----------- From 6045bd89fb50c1b45ffb2a373a8ec5f5b93dd236 Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Wed, 8 Oct 2014 15:16:03 +0100 Subject: [PATCH 071/106] Break unit test. --- tests/test_state.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/test_state.py b/tests/test_state.py index b1624f0b25..c000eedc01 100644 --- a/tests/test_state.py +++ b/tests/test_state.py @@ -71,7 +71,7 @@ class StateTestCase(unittest.TestCase): is_new = yield self.state.handle_new_state(new_pdu) - self.assertTrue(is_new) + self.assertFalse(is_new) self.persistence.get_unresolved_state_tree.assert_called_once_with( new_pdu From 72aef114ab1201f5a5cd734220c9ec738c4e2910 Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Wed, 8 Oct 2014 15:18:19 +0100 Subject: [PATCH 072/106] Fix unit test. --- tests/test_state.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/test_state.py b/tests/test_state.py index c000eedc01..b1624f0b25 100644 --- a/tests/test_state.py +++ b/tests/test_state.py @@ -71,7 +71,7 @@ class StateTestCase(unittest.TestCase): is_new = yield self.state.handle_new_state(new_pdu) - self.assertFalse(is_new) + self.assertTrue(is_new) self.persistence.get_unresolved_state_tree.assert_called_once_with( new_pdu From d224358e21765d42e53674b2078f889dcb28ffb5 Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Thu, 9 Oct 2014 11:08:06 +0100 Subject: [PATCH 073/106] Restructure specification sections. --- docs/specification.rst | 2524 ++++++++++++++++++++-------------------- 1 file changed, 1261 insertions(+), 1263 deletions(-) diff --git a/docs/specification.rst b/docs/specification.rst index 84722aa281..9f7c86f21c 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -19,9 +19,6 @@ WARNING .. contents:: Table of Contents .. sectnum:: -Introduction -============ - Matrix is a new set of open APIs for open-federated Instant Messaging and VoIP functionality, designed to create and support a new global real-time communication ecosystem on the internet. This specification is the ongoing @@ -83,9 +80,11 @@ instant messages, VoIP call setups, or any other objects that need to be reliably and persistently pushed from A to B in an interoperable and federated manner. +Basis +===== Architecture -============ +------------ Clients transmit data to other clients through home servers (HSes). Clients do not communicate with each other directly. @@ -137,7 +136,7 @@ for events defined in the Matrix specification. Events are usually sent in the context of a "Room". Room structure --------------- +~~~~~~~~~~~~~~ A room is a conceptual place where users can send and receive events. Rooms can be created, joined and left. Events are sent to a room, and all participants in @@ -183,7 +182,7 @@ if that means the home server has to request more information from another home server before processing the event. Room Aliases ------------- +~~~~~~~~~~~~ Each room can also have multiple "Room Aliases", which looks like:: @@ -218,7 +217,7 @@ that are in the room that can be used to join via. |________________________________| Identity --------- +~~~~~~~~ Users in Matrix are identified via their user ID. However, existing ID namespaces can also be used in order to identify Matrix users. A Matrix @@ -240,6 +239,97 @@ Usage of an IS is not required in order for a client application to be part of the Matrix ecosystem. However, without one clients will not be able to look up user IDs using 3PIDs. +Presence +~~~~~~~~ +.. NOTE:: + This section is a work in progress. + +Each user has the concept of presence information. This encodes the +"availability" of that user, suitable for display on other user's clients. This +is transmitted as an ``m.presence`` event and is one of the few events which +are sent *outside the context of a room*. The basic piece of presence +information is represented by the ``presence`` key, which is an enum of one of +the following: + + - ``online`` : The default state when the user is connected to an event + stream. + - ``unavailable`` : The user is not reachable at this time. + - ``offline`` : The user is not connected to an event stream. + - ``free_for_chat`` : The user is generally willing to receive messages + moreso than default. + - ``hidden`` : Behaves as offline, but allows the user to see the client + state anyway and generally interact with client features. (Not yet + implemented in synapse). + +This basic ``presence`` field applies to the user as a whole, regardless of how +many client devices they have connected. The home server should synchronise +this status choice among multiple devices to ensure the user gets a consistent +experience. + +In addition, the server maintains a timestamp of the last time it saw an active +action from the user; either sending a message to a room, or changing presence +state from a lower to a higher level of availability (thus: changing state from +``unavailable`` to ``online`` will count as an action for being active, whereas +in the other direction will not). This timestamp is presented via a key called +``last_active_ago``, which gives the relative number of miliseconds since the +message is generated/emitted, that the user was last seen active. + +Home servers can also use the user's choice of presence state as a signal for +how to handle new private one-to-one chat message requests. For example, it +might decide: + + - ``free_for_chat`` : accept anything + - ``online`` : accept from anyone in my addres book list + - ``busy`` : accept from anyone in this "important people" group in my + address book list + +Presence List ++++++++++++++ +Each user's home server stores a "presence list" for that user. This stores a +list of other user IDs the user has chosen to add to it. To be added to this +list, the user being added must receive permission from the list owner. Once +granted, both user's HS(es) store this information. Since such subscriptions +are likely to be bidirectional, HSes may wish to automatically accept requests +when a reverse subscription already exists. + +As a convenience, presence lists should support the ability to collect users +into groups, which could allow things like inviting the entire group to a new +("ad-hoc") chat room, or easy interaction with the profile information ACL +implementation of the HS. + +Presence and Permissions +++++++++++++++++++++++++ +For a viewing user to be allowed to see the presence information of a target +user, either: + + - The target user has allowed the viewing user to add them to their presence + list, or + - The two users share at least one room in common + +In the latter case, this allows for clients to display some minimal sense of +presence information in a user list for a room. + +Profiles +~~~~~~~~ +.. NOTE:: + This section is a work in progress. + +.. TODO-spec + - Metadata extensibility + +Internally within Matrix users are referred to by their user ID, which is +typically a compact unique identifier. Profiles grant users the ability to see +human-readable names for other users that are in some way meaningful to them. +Additionally, profiles can publish additional information, such as the user's +age or location. + +A Profile consists of a display name, an avatar picture, and a set of other +metadata fields that the user may wish to publish (email address, phone +numbers, website URLs, etc...). This specification puts no requirements on the +display name other than it being a valid unicode string. Avatar images are not +stored directly; instead the home server stores an ``http``-scheme URL where +clients may fetch it from. + API Standards ------------- @@ -354,6 +444,89 @@ In contrast, these are invalid requests:: "key": "This is a put but it is missing a txnId." } +Glossary +-------- +.. NOTE:: + This section is a work in progress. + +Backfilling: + The process of synchronising historic state from one home server to another, + to backfill the event storage so that scrollback can be presented to the + client(s). Not to be confused with pagination. + +Context: + A single human-level entity of interest (currently, a chat room) + +EDU (Ephemeral Data Unit): + A message that relates directly to a given pair of home servers that are + exchanging it. EDUs are short-lived messages that related only to one single + pair of servers; they are not persisted for a long time and are not forwarded + on to other servers. Because of this, they have no internal ID nor previous + EDUs reference chain. + +Event: + A record of activity that records a single thing that happened on to a context + (currently, a chat room). These are the "chat messages" that Synapse makes + available. + +PDU (Persistent Data Unit): + A message that relates to a single context, irrespective of the server that + is communicating it. PDUs either encode a single Event, or a single State + change. A PDU is referred to by its PDU ID; the pair of its origin server + and local reference from that server. + +PDU ID: + The pair of PDU Origin and PDU Reference, that together globally uniquely + refers to a specific PDU. + +PDU Origin: + The name of the origin server that generated a given PDU. This may not be the + server from which it has been received, due to the way they are copied around + from server to server. The origin always records the original server that + created it. + +PDU Reference: + A local ID used to refer to a specific PDU from a given origin server. These + references are opaque at the protocol level, but may optionally have some + structured meaning within a given origin server or implementation. + +Presence: + The concept of whether a user is currently online, how available they declare + they are, and so on. See also: doc/model/presence + +Profile: + A set of metadata about a user, such as a display name, provided for the + benefit of other users. See also: doc/model/profiles + +Room ID: + An opaque string (of as-yet undecided format) that identifies a particular + room and used in PDUs referring to it. + +Room Alias: + A human-readable string of the form #name:some.domain that users can use as a + pointer to identify a room; a Directory Server will map this to its Room ID + +State: + A set of metadata maintained about a Context, which is replicated among the + servers in addition to the history of Events. + +User ID: + A string of the form @localpart:domain.name that identifies a user for + wire-protocol purposes. The localpart is meaningless outside of a particular + home server. This takes a human-readable form that end-users can use directly + if they so wish, avoiding the 3PIDs. + +Transaction: + A message which relates to the communication between a given pair of servers. + A transaction contains possibly-empty lists of PDUs and EDUs. + +.. TODO + This glossary contradicts the terms used above - especially on State Events v. "State" + and Non-State Events v. "Events". We need better consistent names. + +Events +====== + Receiving live updates on a client ---------------------------------- @@ -374,886 +547,8 @@ When the client first logs in, they will need to initially synchronise with their home server. This is achieved via the |initialSync|_ API. This API also returns an ``end`` token which can be used with the event stream. - -Registration and Login -====================== - -Clients must register with a home server in order to use Matrix. After -registering, the client will be given an access token which must be used in ALL -requests to that home server as a query parameter 'access_token'. - -If the client has already registered, they need to be able to login to their -account. The home server may provide many different ways of logging in, such as -user/password auth, login via a social network (OAuth2), login by confirming a -token sent to their email address, etc. This specification does not define how -home servers should authorise their users who want to login to their existing -accounts, but instead defines the standard interface which implementations -should follow so that ANY client can login to ANY home server. Clients login -using the |login|_ API. Clients register using the |register|_ API. -Registration follows the same general procedure as login, but the path requests -are sent to and the details contained in them are different. - -In both registration and login cases, the process takes the form of one or more -stages, where at each stage the client submits a set of data for a given stage -type and awaits a response from the server, which will either be a final -success or a request to perform an additional stage. This exchange continues -until the final success. - -In order to determine up-front what the server's requirements are, the client -can request from the server a complete description of all of its acceptable -flows of the registration or login process. It can then inspect the list of -returned flows looking for one for which it believes it can complete all of the -required stages, and perform it. As each home server may have different ways of -logging in, the client needs to know how they should login. All distinct login -stages MUST have a corresponding ``type``. A ``type`` is a namespaced string -which details the mechanism for logging in. - -A client may be able to login via multiple valid login flows, and should choose -a single flow when logging in. A flow is a series of login stages. The home -server MUST respond with all the valid login flows when requested by a simple -``GET`` request directly to the ``/login`` or ``/register`` paths:: - - { - "flows": [ - { - "type": "", - "stages": [ "", "" ] - }, - { - "type": "", - "stages": [ "", "" ] - }, - { - "type": "" - } - ] - } - -The client can now select which flow it wishes to use, and begin making -``POST`` requests to the ``/login`` or ``/register`` paths with JSON body -content containing the name of the stage as the ``type`` key, along with -whatever additional parameters are required for that login or registration type -(see below). After the flow is completed, the client's fully-qualified user -ID and a new access token MUST be returned:: - - { - "user_id": "@user:matrix.org", - "access_token": "abcdef0123456789" - } - -The ``user_id`` key is particularly useful if the home server wishes to support -localpart entry of usernames (e.g. "user" rather than "@user:matrix.org"), as -the client may not be able to determine its ``user_id`` in this case. - -If the flow has multiple stages to it, the home server may wish to create a -session to store context between requests. If a home server responds with a -``session`` key to a request, clients MUST submit it in subsequent requests -until the flow is completed:: - - { - "session": "" - } - -This specification defines the following login types: - - ``m.login.password`` - - ``m.login.oauth2`` - - ``m.login.email.code`` - - ``m.login.email.url`` - - ``m.login.email.identity`` - -Password-based --------------- -:Type: - ``m.login.password`` -:Description: - Login is supported via a username and password. - -To respond to this type, reply with:: - - { - "type": "m.login.password", - "user": "", - "password": "" - } - -The home server MUST respond with either new credentials, the next stage of the -login process, or a standard error response. - -OAuth2-based ------------- -:Type: - ``m.login.oauth2`` -:Description: - Login is supported via OAuth2 URLs. This login consists of multiple requests. - -To respond to this type, reply with:: - - { - "type": "m.login.oauth2", - "user": "" - } - -The server MUST respond with:: - - { - "uri": - } - -The home server acts as a 'confidential' client for the purposes of OAuth2. If -the uri is a ``sevice selection URI``, it MUST point to a webpage which prompts -the user to choose which service to authorize with. On selection of a service, -this MUST link through to an ``Authorization Request URI``. If there is only 1 -service which the home server accepts when logging in, this indirection can be -skipped and the "uri" key can be the ``Authorization Request URI``. - -The client then visits the ``Authorization Request URI``, which then shows the -OAuth2 Allow/Deny prompt. Hitting 'Allow' returns the ``redirect URI`` with the -auth code. Home servers can choose any path for the ``redirect URI``. The -client should visit the ``redirect URI``, which will then finish the OAuth2 -login process, granting the home server an access token for the chosen service. -When the home server gets this access token, it verifies that the cilent has -authorised with the 3rd party, and can now complete the login. The OAuth2 -``redirect URI`` (with auth code) MUST respond with either new credentials, the -next stage of the login process, or a standard error response. - -For example, if a home server accepts OAuth2 from Google, it would return the -Authorization Request URI for Google:: - - { - "uri": "https://accounts.google.com/o/oauth2/auth?response_type=code& - client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=photos" - } - -The client then visits this URI and authorizes the home server. The client then -visits the REDIRECT_URI with the auth code= query parameter which returns:: - - { - "user_id": "@user:matrix.org", - "access_token": "0123456789abcdef" - } - -Email-based (code) ------------------- -:Type: - ``m.login.email.code`` -:Description: - Login is supported by typing in a code which is sent in an email. This login - consists of multiple requests. - -To respond to this type, reply with:: - - { - "type": "m.login.email.code", - "user": "", - "email": "" - } - -After validating the email address, the home server MUST send an email -containing an authentication code and return:: - - { - "type": "m.login.email.code", - "session": "" - } - -The second request in this login stage involves sending this authentication -code:: - - { - "type": "m.login.email.code", - "session": "", - "code": "" - } - -The home server MUST respond to this with either new credentials, the next -stage of the login process, or a standard error response. - -Email-based (url) ------------------ -:Type: - ``m.login.email.url`` -:Description: - Login is supported by clicking on a URL in an email. This login consists of - multiple requests. - -To respond to this type, reply with:: - - { - "type": "m.login.email.url", - "user": "", - "email": "" - } - -After validating the email address, the home server MUST send an email -containing an authentication URL and return:: - - { - "type": "m.login.email.url", - "session": "" - } - -The email contains a URL which must be clicked. After it has been clicked, the -client should perform another request:: - - { - "type": "m.login.email.url", - "session": "" - } - -The home server MUST respond to this with either new credentials, the next -stage of the login process, or a standard error response. - -A common client implementation will be to periodically poll until the link is -clicked. If the link has not been visited yet, a standard error response with -an errcode of ``M_LOGIN_EMAIL_URL_NOT_YET`` should be returned. - - -Email-based (identity server) ------------------------------ -:Type: - ``m.login.email.identity`` -:Description: - Login is supported by authorising an email address with an identity server. - -Prior to submitting this, the client should authenticate with an identity -server. After authenticating, the session information should be submitted to -the home server. - -To respond to this type, reply with:: - - { - "type": "m.login.email.identity", - "threepidCreds": [ - { - "sid": "", - "clientSecret": "", - "idServer": "" - } - ] - } - - - -N-Factor Authentication ------------------------ -Multiple login stages can be combined to create N-factor authentication during -login. - -This can be achieved by responding with the ``next`` login type on completion -of a previous login stage:: - - { - "next": "" - } - -If a home server implements N-factor authentication, it MUST respond with all -``stages`` when initially queried for their login requirements:: - - { - "type": "<1st login type>", - "stages": [ <1st login type>, <2nd login type>, ... , ] - } - -This can be represented conceptually as:: - - _______________________ - | Login Stage 1 | - | type: "" | - | ___________________ | - | |_Request_1_________| | <-- Returns "session" key which is used throughout. - | ___________________ | - | |_Request_2_________| | <-- Returns a "next" value of "login type2" - |_______________________| - | - | - _________V_____________ - | Login Stage 2 | - | type: "" | - | ___________________ | - | |_Request_1_________| | - | ___________________ | - | |_Request_2_________| | - | ___________________ | - | |_Request_3_________| | <-- Returns a "next" value of "login type3" - |_______________________| - | - | - _________V_____________ - | Login Stage 3 | - | type: "" | - | ___________________ | - | |_Request_1_________| | <-- Returns user credentials - |_______________________| - -Fallback --------- -Clients cannot be expected to be able to know how to process every single login -type. If a client determines it does not know how to handle a given login type, -it should request a login fallback page:: - - GET matrix/client/api/v1/login/fallback - -This MUST return an HTML page which can perform the entire login process. - - -Rooms -===== - -Creation --------- -To create a room, a client has to use the |createRoom|_ API. There are various -options which can be set when creating a room: - -``visibility`` - Type: - String - Optional: - Yes - Value: - Either ``public`` or ``private``. - Description: - A ``public`` visibility indicates that the room will be shown in the public - room list. A ``private`` visibility will hide the room from the public room - list. Rooms default to ``private`` visibility if this key is not included. - -``room_alias_name`` - Type: - String - Optional: - Yes - Value: - The room alias localpart. - Description: - If this is included, a room alias will be created and mapped to the newly - created room. The alias will belong on the same home server which created - the room, e.g. ``!qadnasoi:domain.com >>> #room_alias_name:domain.com`` - -``name`` - Type: - String - Optional: - Yes - Value: - The ``name`` value for the ``m.room.name`` state event. - Description: - If this is included, an ``m.room.name`` event will be sent into the room to - indicate the name of the room. See `Room Events`_ for more information on - ``m.room.name``. - -``topic`` - Type: - String - Optional: - Yes - Value: - The ``topic`` value for the ``m.room.topic`` state event. - Description: - If this is included, an ``m.room.topic`` event will be sent into the room - to indicate the topic for the room. See `Room Events`_ for more information - on ``m.room.topic``. - -``invite`` - Type: - List - Optional: - Yes - Value: - A list of user ids to invite. - Description: - This will tell the server to invite everyone in the list to the newly - created room. - -Example:: - - { - "visibility": "public", - "room_alias_name": "thepub", - "name": "The Grand Duke Pub", - "topic": "All about happy hour" - } - -The home server will create a ``m.room.create`` event when the room is created, -which serves as the root of the PDU graph for this room. This event also has a -``creator`` key which contains the user ID of the room creator. It will also -generate several other events in order to manage permissions in this room. This -includes: - - - ``m.room.power_levels`` : Sets the power levels of users. - - ``m.room.join_rules`` : Whether the room is "invite-only" or not. - - ``m.room.add_state_level``: The power level required in order to add new - state to the room (as opposed to updating exisiting state) - - ``m.room.send_event_level`` : The power level required in order to send a - message in this room. - - ``m.room.ops_level`` : The power level required in order to kick or ban a - user from the room or redact an event in the room. - -See `Room Events`_ for more information on these events. - -Room aliases ------------- -.. NOTE:: - This section is a work in progress. - -Room aliases can be created by sending a ``PUT /directory/room/``:: - - { - "room_id": - } - -They can be deleted by sending a ``DELETE /directory/room/`` with -no content. Only some privileged users may be able to delete room aliases, e.g. -server admins, the creator of the room alias, etc. This specification does not -outline the privilege level required for deleting room aliases. - -As room aliases are scoped to a particular home server domain name, it is -likely that a home server will reject attempts to maintain aliases on other -domain names. This specification does not provide a way for home servers to -send update requests to other servers. - -Rooms store a *partial* list of room aliases via the ``m.room.aliases`` state -event. This alias list is partial because it cannot guarantee that the alias -list is in any way accurate or up-to-date, as room aliases can point to -different room IDs over time. Crucially, the aliases in this event are -**purely informational** and SHOULD NOT be treated as accurate. They SHOULD -be checked before they are used or shared with another user. If a room -appears to have a room alias of ``#alias:example.com``, this SHOULD be checked -to make sure that the room's ID matches the ``room_id`` returned from the -request. - -Room aliases can be checked in the same way they are resolved; by sending a -``GET /directory/room/``:: - - { - "room_id": , - "servers": [ , , ] - } - -Home servers can respond to resolve requests for aliases on other domains than -their own by using the federation API to ask other domain name home servers. - - -Permissions ------------ -.. NOTE:: - This section is a work in progress. - -Permissions for rooms are done via the concept of power levels - to do any -action in a room a user must have a suitable power level. Power levels are -stored as state events in a given room. - -Power levels for users are defined in ``m.room.power_levels``, where both a -default and specific users' power levels can be set:: - - { - "": , - "": , - "default": 0 - } - -By default all users have a power level of 0, other than the room creator whose -power level defaults to 100. Users can grant other users increased power levels -up to their own power level. For example, user A with a power level of 50 could -increase the power level of user B to a maximum of level 50. Power levels for -users are tracked per-room even if the user is not present in the room. - -State events may contain a ``required_power_level`` key, which indicates the -minimum power a user must have before they can update that state key. The only -exception to this is when a user leaves a room, which revokes the user's right -to update state events in that room. - -To perform certain actions there are additional power level requirements -defined in the following state events: - -- ``m.room.send_event_level`` defines the minimum ``level`` for sending - non-state events. Defaults to 50. -- ``m.room.add_state_level`` defines the minimum ``level`` for adding new - state, rather than updating existing state. Defaults to 50. -- ``m.room.ops_level`` defines the minimum ``ban_level`` and ``kick_level`` to - ban and kick other users respectively. This defaults to a kick and ban levels - of 50 each. - - -Joining rooms -------------- -.. TODO-doc What does the home server have to do to join a user to a room? - - See SPEC-30. - -Users need to join a room in order to send and receive events in that room. A -user can join a room by making a request to |/join/|_ with:: - - {} - -Alternatively, a user can make a request to |/rooms//join|_ with the -same request content. This is only provided for symmetry with the other -membership APIs: ``/rooms//invite`` and ``/rooms//leave``. If -a room alias was specified, it will be automatically resolved to a room ID, -which will then be joined. The room ID that was joined will be returned in -response:: - - { - "room_id": "!roomid:domain" - } - -The membership state for the joining user can also be modified directly to be -``join`` by sending the following request to -``/rooms//state/m.room.member/``:: - - { - "membership": "join" - } - -See the `Room events`_ section for more information on ``m.room.member``. - -After the user has joined a room, they will receive subsequent events in that -room. This room will now appear as an entry in the |initialSync|_ API. - -Some rooms enforce that a user is *invited* to a room before they can join that -room. Other rooms will allow anyone to join the room even if they have not -received an invite. - -Inviting users --------------- -.. TODO-doc Invite-join dance - - Outline invite join dance. What is it? Why is it required? How does it work? - - What does the home server have to do? - -The purpose of inviting users to a room is to notify them that the room exists -so they can choose to become a member of that room. Some rooms require that all -users who join a room are previously invited to it (an "invite-only" room). -Whether a given room is an "invite-only" room is determined by the room config -key ``m.room.join_rules``. It can have one of the following values: - -``public`` - This room is free for anyone to join without an invite. - -``invite`` - This room can only be joined if you were invited. - -Only users who have a membership state of ``join`` in a room can invite new -users to said room. The person being invited must not be in the ``join`` state -in the room. The fully-qualified user ID must be specified when inviting a -user, as the user may reside on a different home server. To invite a user, send -the following request to |/rooms//invite|_, which will manage the -entire invitation process:: - - { - "user_id": "" - } - -Alternatively, the membership state for this user in this room can be modified -directly by sending the following request to -``/rooms//state/m.room.member/``:: - - { - "membership": "invite" - } - -See the `Room events`_ section for more information on ``m.room.member``. - -Leaving rooms -------------- -.. TODO-spec - HS deleting rooms they are no longer a part of. Not implemented. - - This is actually Very Tricky. If all clients a HS is serving leave a room, - the HS will no longer get any new events for that room, because the servers - who get the events are determined on the *membership list*. There should - probably be a way for a HS to lurk on a room even if there are 0 of their - members in the room. - - Grace period before deletion? - - Under what conditions should a room NOT be purged? - - -A user can leave a room to stop receiving events for that room. A user must -have joined the room before they are eligible to leave the room. If the room is -an "invite-only" room, they will need to be re-invited before they can re-join -the room. To leave a room, a request should be made to -|/rooms//leave|_ with:: - - {} - -Alternatively, the membership state for this user in this room can be modified -directly by sending the following request to -``/rooms//state/m.room.member/``:: - - { - "membership": "leave" - } - -See the `Room events`_ section for more information on ``m.room.member``. - -Once a user has left a room, that room will no longer appear on the -|initialSync|_ API. - -If all members in a room leave, that room becomes eligible for deletion. - -Banning users in a room ------------------------ -A user may decide to ban another user in a room. 'Banning' forces the target -user to leave the room and prevents them from re-joining the room. A banned -user will not be treated as a joined user, and so will not be able to send or -receive events in the room. In order to ban someone, the user performing the -ban MUST have the required power level. To ban a user, a request should be made -to |/rooms//ban|_ with:: - - { - "user_id": "" - } - -Banning a user adjusts the banned member's membership state to ``ban`` and -adjusts the power level of this event to a level higher than the banned person. -Like with other membership changes, a user can directly adjust the target -member's state, by making a request to -``/rooms//state/m.room.member/``:: - - { - "membership": "ban" - } - -Events in a room ----------------- -Room events can be split into two categories: - -:State Events: - These are events which replace events that came before it, depending on a set - of unique keys. These keys are the event ``type`` and a ``state_key``. - Events with the same set of keys will be overwritten. Typically, state events - are used to store state, hence their name. - -:Non-state events: - These are events which cannot be overwritten after sending. The list of - events continues to grow as more events are sent. As this list grows, it - becomes necessary to provide a mechanism for navigating this list. Pagination - APIs are used to view the list of historical non-state events. Typically, - non-state events are used to send messages. - -This specification outlines several events, all with the event type prefix -``m.``. However, applications may wish to add their own type of event, and this -can be achieved using the REST API detailed in the following sections. If new -events are added, the event ``type`` key SHOULD follow the Java package naming -convention, e.g. ``com.example.myapp.event``. This ensures event types are -suitably namespaced for each application and reduces the risk of clashes. - -State events ------------- -State events can be sent by ``PUT`` ing to -|/rooms//state//|_. These events will be -overwritten if ````, ```` and ```` all match. -If the state event has no ``state_key``, it can be omitted from the path. These -requests **cannot use transaction IDs** like other ``PUT`` paths because they -cannot be differentiated from the ``state_key``. Furthermore, ``POST`` is -unsupported on state paths. Valid requests look like:: - - PUT /rooms/!roomid:domain/state/m.example.event - { "key" : "without a state key" } - - PUT /rooms/!roomid:domain/state/m.another.example.event/foo - { "key" : "with 'foo' as the state key" } - -In contrast, these requests are invalid:: - - POST /rooms/!roomid:domain/state/m.example.event/ - { "key" : "cannot use POST here" } - - PUT /rooms/!roomid:domain/state/m.another.example.event/foo/11 - { "key" : "txnIds are not supported" } - -Care should be taken to avoid setting the wrong ``state key``:: - - PUT /rooms/!roomid:domain/state/m.another.example.event/11 - { "key" : "with '11' as the state key, but was probably intended to be a txnId" } - -The ``state_key`` is often used to store state about individual users, by using -the user ID as the ``state_key`` value. For example:: - - PUT /rooms/!roomid:domain/state/m.favorite.animal.event/%40my_user%3Adomain.com - { "animal" : "cat", "reason": "fluffy" } - -In some cases, there may be no need for a ``state_key``, so it can be omitted:: - - PUT /rooms/!roomid:domain/state/m.room.bgd.color - { "color": "red", "hex": "#ff0000" } - -See `Room Events`_ for the ``m.`` event specification. - -Non-state events ----------------- -Non-state events can be sent by sending a request to -|/rooms//send/|_. These requests *can* use transaction -IDs and ``PUT``/``POST`` methods. Non-state events allow access to historical -events and pagination, making it best suited for sending messages. For -example:: - - POST /rooms/!roomid:domain/send/m.custom.example.message - { "text": "Hello world!" } - - PUT /rooms/!roomid:domain/send/m.custom.example.message/11 - { "text": "Goodbye world!" } - -See `Room Events`_ for the ``m.`` event specification. - -Syncing rooms -------------- -.. NOTE:: - This section is a work in progress. - -When a client logs in, they may have a list of rooms which they have already -joined. These rooms may also have a list of events associated with them. The -purpose of 'syncing' is to present the current room and event information in a -convenient, compact manner. The events returned are not limited to room events; -presence events will also be returned. A single syncing API is provided: - - - |initialSync|_ : A global sync which will present room and event information - for all rooms the user has joined. - -.. TODO-spec room-scoped initial sync - - |/rooms//initialSync|_ : A sync scoped to a single room. Presents - room and event information for this room only. - - Room-scoped initial sync is Very Tricky because typically people would - want to sync the room then listen for any new content from that point - onwards. The event stream cannot do this for a single room currently. - As a result, commenting room-scoped initial sync at this time. - -The |initialSync|_ API contains the following keys: - -``presence`` - Description: - Contains a list of presence information for users the client is interested - in. - Format: - A JSON array of ``m.presence`` events. - -``end`` - Description: - Contains an event stream token which can be used with the `Event Stream`_. - Format: - A string containing the event stream token. - -``rooms`` - Description: - Contains a list of room information for all rooms the client has joined, - and limited room information on rooms the client has been invited to. - Format: - A JSON array containing Room Information JSON objects. - -Room Information: - Description: - Contains all state events for the room, along with a limited amount of - the most recent non-state events, configured via the ``limit`` query - parameter. Also contains additional keys with room metadata, such as the - ``room_id`` and the client's ``membership`` to the room. - Format: - A JSON object with the following keys: - ``room_id`` - A string containing the ID of the room being described. - ``membership`` - A string representing the client's membership status in this room. - ``messages`` - An event stream JSON object containing a ``chunk`` of recent non-state - events, along with an ``end`` token. *NB: The name of this key will be - changed in a later version.* - ``state`` - A JSON array containing all the current state events for this room. - -Getting events for a room -------------------------- -There are several APIs provided to ``GET`` events for a room: - -``/rooms//state//`` - Description: - Get the state event identified. - Response format: - A JSON object representing the state event **content**. - Example: - ``/rooms/!room:domain.com/state/m.room.name`` returns ``{ "name": "Room name" }`` - -|/rooms//state|_ - Description: - Get all state events for a room. - Response format: - ``[ { state event }, { state event }, ... ]`` - Example: - TODO-doc - - -|/rooms//members|_ - Description: - Get all ``m.room.member`` state events. - Response format: - ``{ "start": "", "end": "", "chunk": [ { m.room.member event }, ... ] }`` - Example: - TODO-doc - -|/rooms//messages|_ - Description: - Get all ``m.room.message`` and ``m.room.member`` events. This API supports - pagination using ``from`` and ``to`` query parameters, coupled with the - ``start`` and ``end`` tokens from an |initialSync|_ API. - Response format: - ``{ "start": "", "end": "" }`` - Example: - TODO-doc - -|/rooms//initialSync|_ - Description: - Get all relevant events for a room. This includes state events, paginated - non-state events and presence events. - Response format: - `` { TODO-doc } `` - Example: - TODO-doc - -Redactions ----------- -Since events are extensible it is possible for malicious users and/or servers -to add keys that are, for example offensive or illegal. Since some events -cannot be simply deleted, e.g. membership events, we instead 'redact' events. -This involves removing all keys from an event that are not required by the -protocol. This stripped down event is thereafter returned anytime a client or -remote server requests it. - -Events that have been redacted include a ``redacted_because`` key whose value -is the event that caused it to be redacted, which may include a reason. - -Redacting an event cannot be undone, allowing server owners to delete the -offending content from the databases. - -Currently, only room admins can redact events by sending a ``m.room.redaction`` -event, but server admins also need to be able to redact events by a similar -mechanism. - -Upon receipt of a redaction event, the server should strip off any keys not in -the following list: - - - ``event_id`` - - ``type`` - - ``room_id`` - - ``user_id`` - - ``state_key`` - - ``prev_state`` - - ``content`` - -The content object should also be stripped of all keys, unless it is one of -one of the following event types: - - - ``m.room.member`` allows key ``membership`` - - ``m.room.create`` allows key ``creator`` - - ``m.room.join_rules`` allows key ``join_rule`` - - ``m.room.power_levels`` allows keys that are user ids or ``default`` - - ``m.room.add_state_level`` allows key ``level`` - - ``m.room.send_event_level`` allows key ``level`` - - ``m.room.ops_levels`` allows keys ``kick_level``, ``ban_level`` - and ``redact_level`` - - ``m.room.aliases`` allows key ``aliases`` - -The redaction event should be added under the key ``redacted_because``. - - -When a client receives a redaction event it should change the redacted event -in the same way a server does. - - Room Events -=========== +----------- .. NOTE:: This section is a work in progress. @@ -1483,7 +778,7 @@ prefixed with ``m.`` level key. m.room.message msgtypes ------------------------ +~~~~~~~~~~~~~~~~~~~~~~~ .. TODO-spec How a client should handle unknown message types. @@ -1589,187 +884,29 @@ The following keys can be attached to any ``m.room.message``: - ``sender_ts`` : integer - A timestamp (ms resolution) representing the wall-clock time when the message was sent from the client. -Presence -======== -.. NOTE:: - This section is a work in progress. +Events on Change of Profile Information +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Because the profile displayname and avatar information are likely to be used in +many places of a client's display, changes to these fields cause an automatic +propagation event to occur, informing likely-interested parties of the new +values. This change is conveyed using two separate mechanisms: -Each user has the concept of presence information. This encodes the -"availability" of that user, suitable for display on other user's clients. This -is transmitted as an ``m.presence`` event and is one of the few events which -are sent *outside the context of a room*. The basic piece of presence -information is represented by the ``presence`` key, which is an enum of one of -the following: + - a ``m.room.member`` event is sent to every room the user is a member of, + to update the ``displayname`` and ``avatar_url``. + - a presence status update is sent, again containing the new values of the + ``displayname`` and ``avatar_url`` keys, in addition to the required + ``presence`` key containing the current presence state of the user. - - ``online`` : The default state when the user is connected to an event - stream. - - ``unavailable`` : The user is not reachable at this time. - - ``offline`` : The user is not connected to an event stream. - - ``free_for_chat`` : The user is generally willing to receive messages - moreso than default. - - ``hidden`` : Behaves as offline, but allows the user to see the client - state anyway and generally interact with client features. (Not yet - implemented in synapse). - -This basic ``presence`` field applies to the user as a whole, regardless of how -many client devices they have connected. The home server should synchronise -this status choice among multiple devices to ensure the user gets a consistent -experience. - -In addition, the server maintains a timestamp of the last time it saw an active -action from the user; either sending a message to a room, or changing presence -state from a lower to a higher level of availability (thus: changing state from -``unavailable`` to ``online`` will count as an action for being active, whereas -in the other direction will not). This timestamp is presented via a key called -``last_active_ago``, which gives the relative number of miliseconds since the -message is generated/emitted, that the user was last seen active. - -Home servers can also use the user's choice of presence state as a signal for -how to handle new private one-to-one chat message requests. For example, it -might decide: - - - ``free_for_chat`` : accept anything - - ``online`` : accept from anyone in my addres book list - - ``busy`` : accept from anyone in this "important people" group in my - address book list - -Presence List -------------- -Each user's home server stores a "presence list" for that user. This stores a -list of other user IDs the user has chosen to add to it. To be added to this -list, the user being added must receive permission from the list owner. Once -granted, both user's HS(es) store this information. Since such subscriptions -are likely to be bidirectional, HSes may wish to automatically accept requests -when a reverse subscription already exists. - -As a convenience, presence lists should support the ability to collect users -into groups, which could allow things like inviting the entire group to a new -("ad-hoc") chat room, or easy interaction with the profile information ACL -implementation of the HS. - -Presence and Permissions ------------------------- -For a viewing user to be allowed to see the presence information of a target -user, either: - - - The target user has allowed the viewing user to add them to their presence - list, or - - The two users share at least one room in common - -In the latter case, this allows for clients to display some minimal sense of -presence information in a user list for a room. - -Client API ----------- -The client API for presence is on the following set of REST calls. - -Fetching basic status:: - - GET $PREFIX/presence/:user_id/status - - Returned content: JSON object containing the following keys: - presence: "offline"|"unavailable"|"online"|"free_for_chat" - status_msg: (optional) string of freeform text - last_active_ago: miliseconds since the last activity by the user - -Setting basic status:: - - PUT $PREFIX/presence/:user_id/status - - Content: JSON object containing the following keys: - presence and status_msg: as above - -When setting the status, the activity time is updated to reflect that activity; -the client does not need to specify the ``last_active_ago`` field. - -Fetching the presence list:: - - GET $PREFIX/presence/list - - Returned content: JSON array containing objects; each object containing the - following keys: - user_id: observed user ID - presence: "offline"|"unavailable"|"online"|"free_for_chat" - status_msg: (optional) string of freeform text - last_active_ago: miliseconds since the last activity by the user - -Maintaining the presence list:: - - POST $PREFIX/presence/list - - Content: JSON object containing either or both of the following keys: - invite: JSON array of strings giving user IDs to send invites to - drop: JSON array of strings giving user IDs to remove from the list - -.. TODO-spec - - Define how users receive presence invites, and how they accept/decline them - -Server API ----------- -The server API for presence is based entirely on exchange of the following -EDUs. There are no PDUs or Federation Queries involved. - -Performing a presence update and poll subscription request:: - - EDU type: m.presence - - Content keys: - push: (optional): list of push operations. - Each should be an object with the following keys: - user_id: string containing a User ID - presence: "offline"|"unavailable"|"online"|"free_for_chat" - status_msg: (optional) string of freeform text - last_active_ago: miliseconds since the last activity by the user - - poll: (optional): list of strings giving User IDs - - unpoll: (optional): list of strings giving User IDs - -The presence of this combined message is two-fold: it informs the recipient -server of the current status of one or more users on the sending server (by the -``push`` key), and it maintains the list of users on the recipient server that -the sending server is interested in receiving updates for, by adding (by the -``poll`` key) or removing them (by the ``unpoll`` key). The ``poll`` and -``unpoll`` lists apply *changes* to the implied list of users; any existing IDs -that the server sent as ``poll`` operations in a previous message are not -removed until explicitly requested by a later ``unpoll``. - -On receipt of a message containing a non-empty ``poll`` list, the receiving -server should immediately send the sending server a presence update EDU of its -own, containing in a ``push`` list the current state of every user that was in -the orginal EDU's ``poll`` list. - -Sending a presence invite:: - - EDU type: m.presence_invite - - Content keys: - observed_user: string giving the User ID of the user whose presence is - requested (i.e. the recipient of the invite) - observer_user: string giving the User ID of the user who is requesting to - observe the presence (i.e. the sender of the invite) - -Accepting a presence invite:: - - EDU type: m.presence_accept - - Content keys - as for m.presence_invite - -Rejecting a presence invite:: - - EDU type: m.presence_deny - - Content keys - as for m.presence_invite - -.. TODO-doc - - Explain the timing-based roundtrip reduction mechanism for presence - messages - - Explain the zero-byte presence inference logic - See also: docs/client-server/model/presence +Both of these should be done automatically by the home server when a user +successfully changes their displayname or avatar URL fields. +Additionally, when home servers emit room membership events for their own +users, they should include the displayname and avatar URL fields in these +events so that clients already have these details to hand, and do not have to +perform extra roundtrips to query it. Voice over IP -============= +------------- Matrix can also be used to set up VoIP calls. This is part of the core specification, although is still in a very early stage. Voice (and video) over Matrix is based on the WebRTC standards. @@ -1779,7 +916,7 @@ must only send call events to rooms with exactly two participants as currently the WebRTC standard is based around two-party communication. Events ------- +~~~~~~ ``m.call.invite`` This event is sent by the caller when they wish to establish a call. @@ -1850,7 +987,7 @@ either once the call has has been established or before to abort the call. messages Message Exchange ----------------- +~~~~~~~~~~~~~~~~ A call is set up with messages exchanged as follows: :: @@ -1879,7 +1016,7 @@ Calls are negotiated according to the WebRTC specification. Glare ------ +~~~~~ This specification aims to address the problem of two users calling each other at roughly the same time and their invites crossing on the wire. It is a far better experience for the users if their calls are connected if it is clear @@ -1903,31 +1040,933 @@ The call setup should appear seamless to the user as if they had simply placed a call and the other party had accepted. Thusly, any media stream that had been setup for use on a call should be transferred and used for the call that replaces it. - -Profiles -======== +Client-Server API +================= + +Registration and Login +---------------------- + +Clients must register with a home server in order to use Matrix. After +registering, the client will be given an access token which must be used in ALL +requests to that home server as a query parameter 'access_token'. + +If the client has already registered, they need to be able to login to their +account. The home server may provide many different ways of logging in, such as +user/password auth, login via a social network (OAuth2), login by confirming a +token sent to their email address, etc. This specification does not define how +home servers should authorise their users who want to login to their existing +accounts, but instead defines the standard interface which implementations +should follow so that ANY client can login to ANY home server. Clients login +using the |login|_ API. Clients register using the |register|_ API. +Registration follows the same general procedure as login, but the path requests +are sent to and the details contained in them are different. + +In both registration and login cases, the process takes the form of one or more +stages, where at each stage the client submits a set of data for a given stage +type and awaits a response from the server, which will either be a final +success or a request to perform an additional stage. This exchange continues +until the final success. + +In order to determine up-front what the server's requirements are, the client +can request from the server a complete description of all of its acceptable +flows of the registration or login process. It can then inspect the list of +returned flows looking for one for which it believes it can complete all of the +required stages, and perform it. As each home server may have different ways of +logging in, the client needs to know how they should login. All distinct login +stages MUST have a corresponding ``type``. A ``type`` is a namespaced string +which details the mechanism for logging in. + +A client may be able to login via multiple valid login flows, and should choose +a single flow when logging in. A flow is a series of login stages. The home +server MUST respond with all the valid login flows when requested by a simple +``GET`` request directly to the ``/login`` or ``/register`` paths:: + + { + "flows": [ + { + "type": "", + "stages": [ "", "" ] + }, + { + "type": "", + "stages": [ "", "" ] + }, + { + "type": "" + } + ] + } + +The client can now select which flow it wishes to use, and begin making +``POST`` requests to the ``/login`` or ``/register`` paths with JSON body +content containing the name of the stage as the ``type`` key, along with +whatever additional parameters are required for that login or registration type +(see below). After the flow is completed, the client's fully-qualified user +ID and a new access token MUST be returned:: + + { + "user_id": "@user:matrix.org", + "access_token": "abcdef0123456789" + } + +The ``user_id`` key is particularly useful if the home server wishes to support +localpart entry of usernames (e.g. "user" rather than "@user:matrix.org"), as +the client may not be able to determine its ``user_id`` in this case. + +If the flow has multiple stages to it, the home server may wish to create a +session to store context between requests. If a home server responds with a +``session`` key to a request, clients MUST submit it in subsequent requests +until the flow is completed:: + + { + "session": "" + } + +This specification defines the following login types: + - ``m.login.password`` + - ``m.login.oauth2`` + - ``m.login.email.code`` + - ``m.login.email.url`` + - ``m.login.email.identity`` + +Password-based +~~~~~~~~~~~~~~ +:Type: + ``m.login.password`` +:Description: + Login is supported via a username and password. + +To respond to this type, reply with:: + + { + "type": "m.login.password", + "user": "", + "password": "" + } + +The home server MUST respond with either new credentials, the next stage of the +login process, or a standard error response. + +OAuth2-based +~~~~~~~~~~~~ +:Type: + ``m.login.oauth2`` +:Description: + Login is supported via OAuth2 URLs. This login consists of multiple requests. + +To respond to this type, reply with:: + + { + "type": "m.login.oauth2", + "user": "" + } + +The server MUST respond with:: + + { + "uri": + } + +The home server acts as a 'confidential' client for the purposes of OAuth2. If +the uri is a ``sevice selection URI``, it MUST point to a webpage which prompts +the user to choose which service to authorize with. On selection of a service, +this MUST link through to an ``Authorization Request URI``. If there is only 1 +service which the home server accepts when logging in, this indirection can be +skipped and the "uri" key can be the ``Authorization Request URI``. + +The client then visits the ``Authorization Request URI``, which then shows the +OAuth2 Allow/Deny prompt. Hitting 'Allow' returns the ``redirect URI`` with the +auth code. Home servers can choose any path for the ``redirect URI``. The +client should visit the ``redirect URI``, which will then finish the OAuth2 +login process, granting the home server an access token for the chosen service. +When the home server gets this access token, it verifies that the cilent has +authorised with the 3rd party, and can now complete the login. The OAuth2 +``redirect URI`` (with auth code) MUST respond with either new credentials, the +next stage of the login process, or a standard error response. + +For example, if a home server accepts OAuth2 from Google, it would return the +Authorization Request URI for Google:: + + { + "uri": "https://accounts.google.com/o/oauth2/auth?response_type=code& + client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=photos" + } + +The client then visits this URI and authorizes the home server. The client then +visits the REDIRECT_URI with the auth code= query parameter which returns:: + + { + "user_id": "@user:matrix.org", + "access_token": "0123456789abcdef" + } + +Email-based (code) +~~~~~~~~~~~~~~~~~~ +:Type: + ``m.login.email.code`` +:Description: + Login is supported by typing in a code which is sent in an email. This login + consists of multiple requests. + +To respond to this type, reply with:: + + { + "type": "m.login.email.code", + "user": "", + "email": "" + } + +After validating the email address, the home server MUST send an email +containing an authentication code and return:: + + { + "type": "m.login.email.code", + "session": "" + } + +The second request in this login stage involves sending this authentication +code:: + + { + "type": "m.login.email.code", + "session": "", + "code": "" + } + +The home server MUST respond to this with either new credentials, the next +stage of the login process, or a standard error response. + +Email-based (url) +~~~~~~~~~~~~~~~~~ +:Type: + ``m.login.email.url`` +:Description: + Login is supported by clicking on a URL in an email. This login consists of + multiple requests. + +To respond to this type, reply with:: + + { + "type": "m.login.email.url", + "user": "", + "email": "" + } + +After validating the email address, the home server MUST send an email +containing an authentication URL and return:: + + { + "type": "m.login.email.url", + "session": "" + } + +The email contains a URL which must be clicked. After it has been clicked, the +client should perform another request:: + + { + "type": "m.login.email.url", + "session": "" + } + +The home server MUST respond to this with either new credentials, the next +stage of the login process, or a standard error response. + +A common client implementation will be to periodically poll until the link is +clicked. If the link has not been visited yet, a standard error response with +an errcode of ``M_LOGIN_EMAIL_URL_NOT_YET`` should be returned. + + +Email-based (identity server) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +:Type: + ``m.login.email.identity`` +:Description: + Login is supported by authorising an email address with an identity server. + +Prior to submitting this, the client should authenticate with an identity +server. After authenticating, the session information should be submitted to +the home server. + +To respond to this type, reply with:: + + { + "type": "m.login.email.identity", + "threepidCreds": [ + { + "sid": "", + "clientSecret": "", + "idServer": "" + } + ] + } + + + +N-Factor Authentication +~~~~~~~~~~~~~~~~~~~~~~~ +Multiple login stages can be combined to create N-factor authentication during +login. + +This can be achieved by responding with the ``next`` login type on completion +of a previous login stage:: + + { + "next": "" + } + +If a home server implements N-factor authentication, it MUST respond with all +``stages`` when initially queried for their login requirements:: + + { + "type": "<1st login type>", + "stages": [ <1st login type>, <2nd login type>, ... , ] + } + +This can be represented conceptually as:: + + _______________________ + | Login Stage 1 | + | type: "" | + | ___________________ | + | |_Request_1_________| | <-- Returns "session" key which is used throughout. + | ___________________ | + | |_Request_2_________| | <-- Returns a "next" value of "login type2" + |_______________________| + | + | + _________V_____________ + | Login Stage 2 | + | type: "" | + | ___________________ | + | |_Request_1_________| | + | ___________________ | + | |_Request_2_________| | + | ___________________ | + | |_Request_3_________| | <-- Returns a "next" value of "login type3" + |_______________________| + | + | + _________V_____________ + | Login Stage 3 | + | type: "" | + | ___________________ | + | |_Request_1_________| | <-- Returns user credentials + |_______________________| + +Fallback +~~~~~~~~ +Clients cannot be expected to be able to know how to process every single login +type. If a client determines it does not know how to handle a given login type, +it should request a login fallback page:: + + GET matrix/client/api/v1/login/fallback + +This MUST return an HTML page which can perform the entire login process. + + +Rooms +----- + +Creation +~~~~~~~~ +To create a room, a client has to use the |createRoom|_ API. There are various +options which can be set when creating a room: + +``visibility`` + Type: + String + Optional: + Yes + Value: + Either ``public`` or ``private``. + Description: + A ``public`` visibility indicates that the room will be shown in the public + room list. A ``private`` visibility will hide the room from the public room + list. Rooms default to ``private`` visibility if this key is not included. + +``room_alias_name`` + Type: + String + Optional: + Yes + Value: + The room alias localpart. + Description: + If this is included, a room alias will be created and mapped to the newly + created room. The alias will belong on the same home server which created + the room, e.g. ``!qadnasoi:domain.com >>> #room_alias_name:domain.com`` + +``name`` + Type: + String + Optional: + Yes + Value: + The ``name`` value for the ``m.room.name`` state event. + Description: + If this is included, an ``m.room.name`` event will be sent into the room to + indicate the name of the room. See `Room Events`_ for more information on + ``m.room.name``. + +``topic`` + Type: + String + Optional: + Yes + Value: + The ``topic`` value for the ``m.room.topic`` state event. + Description: + If this is included, an ``m.room.topic`` event will be sent into the room + to indicate the topic for the room. See `Room Events`_ for more information + on ``m.room.topic``. + +``invite`` + Type: + List + Optional: + Yes + Value: + A list of user ids to invite. + Description: + This will tell the server to invite everyone in the list to the newly + created room. + +Example:: + + { + "visibility": "public", + "room_alias_name": "thepub", + "name": "The Grand Duke Pub", + "topic": "All about happy hour" + } + +The home server will create a ``m.room.create`` event when the room is created, +which serves as the root of the PDU graph for this room. This event also has a +``creator`` key which contains the user ID of the room creator. It will also +generate several other events in order to manage permissions in this room. This +includes: + + - ``m.room.power_levels`` : Sets the power levels of users. + - ``m.room.join_rules`` : Whether the room is "invite-only" or not. + - ``m.room.add_state_level``: The power level required in order to add new + state to the room (as opposed to updating exisiting state) + - ``m.room.send_event_level`` : The power level required in order to send a + message in this room. + - ``m.room.ops_level`` : The power level required in order to kick or ban a + user from the room or redact an event in the room. + +See `Room Events`_ for more information on these events. + +Room aliases +~~~~~~~~~~~~ .. NOTE:: This section is a work in progress. +Room aliases can be created by sending a ``PUT /directory/room/``:: + + { + "room_id": + } + +They can be deleted by sending a ``DELETE /directory/room/`` with +no content. Only some privileged users may be able to delete room aliases, e.g. +server admins, the creator of the room alias, etc. This specification does not +outline the privilege level required for deleting room aliases. + +As room aliases are scoped to a particular home server domain name, it is +likely that a home server will reject attempts to maintain aliases on other +domain names. This specification does not provide a way for home servers to +send update requests to other servers. + +Rooms store a *partial* list of room aliases via the ``m.room.aliases`` state +event. This alias list is partial because it cannot guarantee that the alias +list is in any way accurate or up-to-date, as room aliases can point to +different room IDs over time. Crucially, the aliases in this event are +**purely informational** and SHOULD NOT be treated as accurate. They SHOULD +be checked before they are used or shared with another user. If a room +appears to have a room alias of ``#alias:example.com``, this SHOULD be checked +to make sure that the room's ID matches the ``room_id`` returned from the +request. + +Room aliases can be checked in the same way they are resolved; by sending a +``GET /directory/room/``:: + + { + "room_id": , + "servers": [ , , ] + } + +Home servers can respond to resolve requests for aliases on other domains than +their own by using the federation API to ask other domain name home servers. + + +Permissions +~~~~~~~~~~~ +.. NOTE:: + This section is a work in progress. + +Permissions for rooms are done via the concept of power levels - to do any +action in a room a user must have a suitable power level. Power levels are +stored as state events in a given room. + +Power levels for users are defined in ``m.room.power_levels``, where both a +default and specific users' power levels can be set:: + + { + "": , + "": , + "default": 0 + } + +By default all users have a power level of 0, other than the room creator whose +power level defaults to 100. Users can grant other users increased power levels +up to their own power level. For example, user A with a power level of 50 could +increase the power level of user B to a maximum of level 50. Power levels for +users are tracked per-room even if the user is not present in the room. + +State events may contain a ``required_power_level`` key, which indicates the +minimum power a user must have before they can update that state key. The only +exception to this is when a user leaves a room, which revokes the user's right +to update state events in that room. + +To perform certain actions there are additional power level requirements +defined in the following state events: + +- ``m.room.send_event_level`` defines the minimum ``level`` for sending + non-state events. Defaults to 50. +- ``m.room.add_state_level`` defines the minimum ``level`` for adding new + state, rather than updating existing state. Defaults to 50. +- ``m.room.ops_level`` defines the minimum ``ban_level`` and ``kick_level`` to + ban and kick other users respectively. This defaults to a kick and ban levels + of 50 each. + + +Joining rooms +~~~~~~~~~~~~~ +.. TODO-doc What does the home server have to do to join a user to a room? + - See SPEC-30. + +Users need to join a room in order to send and receive events in that room. A +user can join a room by making a request to |/join/|_ with:: + + {} + +Alternatively, a user can make a request to |/rooms//join|_ with the +same request content. This is only provided for symmetry with the other +membership APIs: ``/rooms//invite`` and ``/rooms//leave``. If +a room alias was specified, it will be automatically resolved to a room ID, +which will then be joined. The room ID that was joined will be returned in +response:: + + { + "room_id": "!roomid:domain" + } + +The membership state for the joining user can also be modified directly to be +``join`` by sending the following request to +``/rooms//state/m.room.member/``:: + + { + "membership": "join" + } + +See the `Room events`_ section for more information on ``m.room.member``. + +After the user has joined a room, they will receive subsequent events in that +room. This room will now appear as an entry in the |initialSync|_ API. + +Some rooms enforce that a user is *invited* to a room before they can join that +room. Other rooms will allow anyone to join the room even if they have not +received an invite. + +Inviting users +~~~~~~~~~~~~~~ +.. TODO-doc Invite-join dance + - Outline invite join dance. What is it? Why is it required? How does it work? + - What does the home server have to do? + +The purpose of inviting users to a room is to notify them that the room exists +so they can choose to become a member of that room. Some rooms require that all +users who join a room are previously invited to it (an "invite-only" room). +Whether a given room is an "invite-only" room is determined by the room config +key ``m.room.join_rules``. It can have one of the following values: + +``public`` + This room is free for anyone to join without an invite. + +``invite`` + This room can only be joined if you were invited. + +Only users who have a membership state of ``join`` in a room can invite new +users to said room. The person being invited must not be in the ``join`` state +in the room. The fully-qualified user ID must be specified when inviting a +user, as the user may reside on a different home server. To invite a user, send +the following request to |/rooms//invite|_, which will manage the +entire invitation process:: + + { + "user_id": "" + } + +Alternatively, the membership state for this user in this room can be modified +directly by sending the following request to +``/rooms//state/m.room.member/``:: + + { + "membership": "invite" + } + +See the `Room events`_ section for more information on ``m.room.member``. + +Leaving rooms +~~~~~~~~~~~~~ +.. TODO-spec - HS deleting rooms they are no longer a part of. Not implemented. + - This is actually Very Tricky. If all clients a HS is serving leave a room, + the HS will no longer get any new events for that room, because the servers + who get the events are determined on the *membership list*. There should + probably be a way for a HS to lurk on a room even if there are 0 of their + members in the room. + - Grace period before deletion? + - Under what conditions should a room NOT be purged? + + +A user can leave a room to stop receiving events for that room. A user must +have joined the room before they are eligible to leave the room. If the room is +an "invite-only" room, they will need to be re-invited before they can re-join +the room. To leave a room, a request should be made to +|/rooms//leave|_ with:: + + {} + +Alternatively, the membership state for this user in this room can be modified +directly by sending the following request to +``/rooms//state/m.room.member/``:: + + { + "membership": "leave" + } + +See the `Room events`_ section for more information on ``m.room.member``. + +Once a user has left a room, that room will no longer appear on the +|initialSync|_ API. + +If all members in a room leave, that room becomes eligible for deletion. + +Banning users in a room +~~~~~~~~~~~~~~~~~~~~~~~ +A user may decide to ban another user in a room. 'Banning' forces the target +user to leave the room and prevents them from re-joining the room. A banned +user will not be treated as a joined user, and so will not be able to send or +receive events in the room. In order to ban someone, the user performing the +ban MUST have the required power level. To ban a user, a request should be made +to |/rooms//ban|_ with:: + + { + "user_id": "" + } + +Banning a user adjusts the banned member's membership state to ``ban`` and +adjusts the power level of this event to a level higher than the banned person. +Like with other membership changes, a user can directly adjust the target +member's state, by making a request to +``/rooms//state/m.room.member/``:: + + { + "membership": "ban" + } + +Events in a room +~~~~~~~~~~~~~~~~ +Room events can be split into two categories: + +:State Events: + These are events which replace events that came before it, depending on a set + of unique keys. These keys are the event ``type`` and a ``state_key``. + Events with the same set of keys will be overwritten. Typically, state events + are used to store state, hence their name. + +:Non-state events: + These are events which cannot be overwritten after sending. The list of + events continues to grow as more events are sent. As this list grows, it + becomes necessary to provide a mechanism for navigating this list. Pagination + APIs are used to view the list of historical non-state events. Typically, + non-state events are used to send messages. + +This specification outlines several events, all with the event type prefix +``m.``. However, applications may wish to add their own type of event, and this +can be achieved using the REST API detailed in the following sections. If new +events are added, the event ``type`` key SHOULD follow the Java package naming +convention, e.g. ``com.example.myapp.event``. This ensures event types are +suitably namespaced for each application and reduces the risk of clashes. + +State events +~~~~~~~~~~~~ +State events can be sent by ``PUT`` ing to +|/rooms//state//|_. These events will be +overwritten if ````, ```` and ```` all match. +If the state event has no ``state_key``, it can be omitted from the path. These +requests **cannot use transaction IDs** like other ``PUT`` paths because they +cannot be differentiated from the ``state_key``. Furthermore, ``POST`` is +unsupported on state paths. Valid requests look like:: + + PUT /rooms/!roomid:domain/state/m.example.event + { "key" : "without a state key" } + + PUT /rooms/!roomid:domain/state/m.another.example.event/foo + { "key" : "with 'foo' as the state key" } + +In contrast, these requests are invalid:: + + POST /rooms/!roomid:domain/state/m.example.event/ + { "key" : "cannot use POST here" } + + PUT /rooms/!roomid:domain/state/m.another.example.event/foo/11 + { "key" : "txnIds are not supported" } + +Care should be taken to avoid setting the wrong ``state key``:: + + PUT /rooms/!roomid:domain/state/m.another.example.event/11 + { "key" : "with '11' as the state key, but was probably intended to be a txnId" } + +The ``state_key`` is often used to store state about individual users, by using +the user ID as the ``state_key`` value. For example:: + + PUT /rooms/!roomid:domain/state/m.favorite.animal.event/%40my_user%3Adomain.com + { "animal" : "cat", "reason": "fluffy" } + +In some cases, there may be no need for a ``state_key``, so it can be omitted:: + + PUT /rooms/!roomid:domain/state/m.room.bgd.color + { "color": "red", "hex": "#ff0000" } + +See `Room Events`_ for the ``m.`` event specification. + +Non-state events +~~~~~~~~~~~~~~~~ +Non-state events can be sent by sending a request to +|/rooms//send/|_. These requests *can* use transaction +IDs and ``PUT``/``POST`` methods. Non-state events allow access to historical +events and pagination, making it best suited for sending messages. For +example:: + + POST /rooms/!roomid:domain/send/m.custom.example.message + { "text": "Hello world!" } + + PUT /rooms/!roomid:domain/send/m.custom.example.message/11 + { "text": "Goodbye world!" } + +See `Room Events`_ for the ``m.`` event specification. + +Syncing rooms +~~~~~~~~~~~~~ +.. NOTE:: + This section is a work in progress. + +When a client logs in, they may have a list of rooms which they have already +joined. These rooms may also have a list of events associated with them. The +purpose of 'syncing' is to present the current room and event information in a +convenient, compact manner. The events returned are not limited to room events; +presence events will also be returned. A single syncing API is provided: + + - |initialSync|_ : A global sync which will present room and event information + for all rooms the user has joined. + +.. TODO-spec room-scoped initial sync + - |/rooms//initialSync|_ : A sync scoped to a single room. Presents + room and event information for this room only. + - Room-scoped initial sync is Very Tricky because typically people would + want to sync the room then listen for any new content from that point + onwards. The event stream cannot do this for a single room currently. + As a result, commenting room-scoped initial sync at this time. + +The |initialSync|_ API contains the following keys: + +``presence`` + Description: + Contains a list of presence information for users the client is interested + in. + Format: + A JSON array of ``m.presence`` events. + +``end`` + Description: + Contains an event stream token which can be used with the `Event Stream`_. + Format: + A string containing the event stream token. + +``rooms`` + Description: + Contains a list of room information for all rooms the client has joined, + and limited room information on rooms the client has been invited to. + Format: + A JSON array containing Room Information JSON objects. + +Room Information: + Description: + Contains all state events for the room, along with a limited amount of + the most recent non-state events, configured via the ``limit`` query + parameter. Also contains additional keys with room metadata, such as the + ``room_id`` and the client's ``membership`` to the room. + Format: + A JSON object with the following keys: + ``room_id`` + A string containing the ID of the room being described. + ``membership`` + A string representing the client's membership status in this room. + ``messages`` + An event stream JSON object containing a ``chunk`` of recent non-state + events, along with an ``end`` token. *NB: The name of this key will be + changed in a later version.* + ``state`` + A JSON array containing all the current state events for this room. + +Getting events for a room +~~~~~~~~~~~~~~~~~~~~~~~~~ +There are several APIs provided to ``GET`` events for a room: + +``/rooms//state//`` + Description: + Get the state event identified. + Response format: + A JSON object representing the state event **content**. + Example: + ``/rooms/!room:domain.com/state/m.room.name`` returns ``{ "name": "Room name" }`` + +|/rooms//state|_ + Description: + Get all state events for a room. + Response format: + ``[ { state event }, { state event }, ... ]`` + Example: + TODO-doc + + +|/rooms//members|_ + Description: + Get all ``m.room.member`` state events. + Response format: + ``{ "start": "", "end": "", "chunk": [ { m.room.member event }, ... ] }`` + Example: + TODO-doc + +|/rooms//messages|_ + Description: + Get all ``m.room.message`` and ``m.room.member`` events. This API supports + pagination using ``from`` and ``to`` query parameters, coupled with the + ``start`` and ``end`` tokens from an |initialSync|_ API. + Response format: + ``{ "start": "", "end": "" }`` + Example: + TODO-doc + +|/rooms//initialSync|_ + Description: + Get all relevant events for a room. This includes state events, paginated + non-state events and presence events. + Response format: + `` { TODO-doc } `` + Example: + TODO-doc + +Redactions +~~~~~~~~~~ +Since events are extensible it is possible for malicious users and/or servers +to add keys that are, for example offensive or illegal. Since some events +cannot be simply deleted, e.g. membership events, we instead 'redact' events. +This involves removing all keys from an event that are not required by the +protocol. This stripped down event is thereafter returned anytime a client or +remote server requests it. + +Events that have been redacted include a ``redacted_because`` key whose value +is the event that caused it to be redacted, which may include a reason. + +Redacting an event cannot be undone, allowing server owners to delete the +offending content from the databases. + +Currently, only room admins can redact events by sending a ``m.room.redaction`` +event, but server admins also need to be able to redact events by a similar +mechanism. + +Upon receipt of a redaction event, the server should strip off any keys not in +the following list: + + - ``event_id`` + - ``type`` + - ``room_id`` + - ``user_id`` + - ``state_key`` + - ``prev_state`` + - ``content`` + +The content object should also be stripped of all keys, unless it is one of +one of the following event types: + + - ``m.room.member`` allows key ``membership`` + - ``m.room.create`` allows key ``creator`` + - ``m.room.join_rules`` allows key ``join_rule`` + - ``m.room.power_levels`` allows keys that are user ids or ``default`` + - ``m.room.add_state_level`` allows key ``level`` + - ``m.room.send_event_level`` allows key ``level`` + - ``m.room.ops_levels`` allows keys ``kick_level``, ``ban_level`` + and ``redact_level`` + - ``m.room.aliases`` allows key ``aliases`` + +The redaction event should be added under the key ``redacted_because``. + + +When a client receives a redaction event it should change the redacted event +in the same way a server does. + +Presence +~~~~~~~~ +The client API for presence is on the following set of REST calls. + +Fetching basic status:: + + GET $PREFIX/presence/:user_id/status + + Returned content: JSON object containing the following keys: + presence: "offline"|"unavailable"|"online"|"free_for_chat" + status_msg: (optional) string of freeform text + last_active_ago: miliseconds since the last activity by the user + +Setting basic status:: + + PUT $PREFIX/presence/:user_id/status + + Content: JSON object containing the following keys: + presence and status_msg: as above + +When setting the status, the activity time is updated to reflect that activity; +the client does not need to specify the ``last_active_ago`` field. + +Fetching the presence list:: + + GET $PREFIX/presence/list + + Returned content: JSON array containing objects; each object containing the + following keys: + user_id: observed user ID + presence: "offline"|"unavailable"|"online"|"free_for_chat" + status_msg: (optional) string of freeform text + last_active_ago: miliseconds since the last activity by the user + +Maintaining the presence list:: + + POST $PREFIX/presence/list + + Content: JSON object containing either or both of the following keys: + invite: JSON array of strings giving user IDs to send invites to + drop: JSON array of strings giving user IDs to remove from the list + .. TODO-spec - - Metadata extensibility + - Define how users receive presence invites, and how they accept/decline them -Internally within Matrix users are referred to by their user ID, which is -typically a compact unique identifier. Profiles grant users the ability to see -human-readable names for other users that are in some way meaningful to them. -Additionally, profiles can publish additional information, such as the user's -age or location. - -A Profile consists of a display name, an avatar picture, and a set of other -metadata fields that the user may wish to publish (email address, phone -numbers, website URLs, etc...). This specification puts no requirements on the -display name other than it being a valid unicode string. Avatar images are not -stored directly; instead the home server stores an ``http``-scheme URL where -clients may fetch it from. - -Client API ----------- +Profiles +~~~~~~~~ The client API for profile management consists of the following REST calls. Fetching a user account displayname:: @@ -1979,62 +2018,61 @@ profile once they are defined. Client implementations should take care not to expect that these are the only two keys returned as future versions of this specification may yield more keys here. -Server API ----------- -The server API for profiles is based entirely on the following Federation -Queries. There are no additional EDU or PDU types involved, other than the -implicit ``m.presence`` and ``m.room.member`` events (see section below). +Security +-------- -Querying profile information:: +Rate limiting +~~~~~~~~~~~~~ +Home servers SHOULD implement rate limiting to reduce the risk of being +overloaded. If a request is refused due to rate limiting, it should return a +standard error response of the form:: - Query type: profile + { + "errcode": "M_LIMIT_EXCEEDED", + "error": "string", + "retry_after_ms": integer (optional) + } - Arguments: - user_id: the ID of the user whose profile to return - field: (optional) string giving a field name +The ``retry_after_ms`` key SHOULD be included to tell the client how long they +have to wait in milliseconds before they can try again. - Returns: JSON object containing the following keys: - displayname: string of freeform text - avatar_url: string containing an http-scheme URL +.. TODO-spec + - Surely we should recommend an algorithm for the rate limiting, rather than letting every + homeserver come up with their own idea, causing totally unpredictable performance over + federated rooms? -If the query contains the optional ``field`` key, it should give the name of a -result field. If such is present, then the result should contain only a field -of that name, with no others present. If not, the result should contain as much -of the user's profile as the home server has available and can make public. +End-to-End Encryption +~~~~~~~~~~~~~~~~~~~~~ -Events on Change of Profile Information ---------------------------------------- -Because the profile displayname and avatar information are likely to be used in -many places of a client's display, changes to these fields cause an automatic -propagation event to occur, informing likely-interested parties of the new -values. This change is conveyed using two separate mechanisms: +.. TODO-doc + - Why is this needed. + - Overview of process + - Implementation - - a ``m.room.member`` event is sent to every room the user is a member of, - to update the ``displayname`` and ``avatar_url``. - - a presence status update is sent, again containing the new values of the - ``displayname`` and ``avatar_url`` keys, in addition to the required - ``presence`` key containing the current presence state of the user. - -Both of these should be done automatically by the home server when a user -successfully changes their displayname or avatar URL fields. - -Additionally, when home servers emit room membership events for their own -users, they should include the displayname and avatar URL fields in these -events so that clients already have these details to hand, and do not have to -perform extra roundtrips to query it. - - -Identity -======== +Content repository +------------------ .. NOTE:: This section is a work in progress. -.. TODO-doc Dave - - 3PIDs and identity server, functions +.. TODO-spec + - path to upload + - format for thumbnail paths, mention what it is protecting against. + - content size limit and associated M_ERROR. -Federation -========== +Address book repository +----------------------- +.. NOTE:: + This section is a work in progress. + +.. TODO-spec + - format: POST(?) wodges of json, some possible processing, then return wodges of json on GET. + - processing may remove dupes, merge contacts, pepper with extra info (e.g. matrix-ability of + contacts), etc. + - Standard json format for contacts? Piggy back off vcards? + +Federation API +=============== Federation is the term used to describe how to communicate between Matrix home servers. Federation is a mechanism by which two home servers can exchange @@ -2396,11 +2434,91 @@ State Conflict Resolution - How are they resolved (incl tie breaks) - How does this work with deleting current state -Security -======== +Presence +-------- +The server API for presence is based entirely on exchange of the following +EDUs. There are no PDUs or Federation Queries involved. -.. NOTE:: - This section is a work in progress. +Performing a presence update and poll subscription request:: + + EDU type: m.presence + + Content keys: + push: (optional): list of push operations. + Each should be an object with the following keys: + user_id: string containing a User ID + presence: "offline"|"unavailable"|"online"|"free_for_chat" + status_msg: (optional) string of freeform text + last_active_ago: miliseconds since the last activity by the user + + poll: (optional): list of strings giving User IDs + + unpoll: (optional): list of strings giving User IDs + +The presence of this combined message is two-fold: it informs the recipient +server of the current status of one or more users on the sending server (by the +``push`` key), and it maintains the list of users on the recipient server that +the sending server is interested in receiving updates for, by adding (by the +``poll`` key) or removing them (by the ``unpoll`` key). The ``poll`` and +``unpoll`` lists apply *changes* to the implied list of users; any existing IDs +that the server sent as ``poll`` operations in a previous message are not +removed until explicitly requested by a later ``unpoll``. + +On receipt of a message containing a non-empty ``poll`` list, the receiving +server should immediately send the sending server a presence update EDU of its +own, containing in a ``push`` list the current state of every user that was in +the orginal EDU's ``poll`` list. + +Sending a presence invite:: + + EDU type: m.presence_invite + + Content keys: + observed_user: string giving the User ID of the user whose presence is + requested (i.e. the recipient of the invite) + observer_user: string giving the User ID of the user who is requesting to + observe the presence (i.e. the sender of the invite) + +Accepting a presence invite:: + + EDU type: m.presence_accept + + Content keys - as for m.presence_invite + +Rejecting a presence invite:: + + EDU type: m.presence_deny + + Content keys - as for m.presence_invite + +.. TODO-doc + - Explain the timing-based roundtrip reduction mechanism for presence + messages + - Explain the zero-byte presence inference logic + See also: docs/client-server/model/presence + +Profiles +-------- +The server API for profiles is based entirely on the following Federation +Queries. There are no additional EDU or PDU types involved, other than the +implicit ``m.presence`` and ``m.room.member`` events (see section below). + +Querying profile information:: + + Query type: profile + + Arguments: + user_id: the ID of the user whose profile to return + field: (optional) string giving a field name + + Returns: JSON object containing the following keys: + displayname: string of freeform text + avatar_url: string containing an http-scheme URL + +If the query contains the optional ``field`` key, it should give the name of a +result field. If such is present, then the result should contain only a field +of that name, with no others present. If not, the result should contain as much +of the user's profile as the home server has available and can make public. Server-Server Authentication ---------------------------- @@ -2411,19 +2529,7 @@ Server-Server Authentication - Transaction/PDU signing - How does this work with redactions? (eg hashing required keys only) -End-to-End Encryption ---------------------- -.. TODO-doc - - Why is this needed. - - Overview of process - - Implementation - -Lawful Interception -------------------- - -Key Escrow Servers -~~~~~~~~~~~~~~~~~~ Threat Model ------------ @@ -2552,26 +2658,20 @@ Threat: Disclosure to Servers Within Chatroom An attacker could take control of a server within a chatroom to expose message contents or metadata for messages in that room. -Rate limiting -------------- -Home servers SHOULD implement rate limiting to reduce the risk of being -overloaded. If a request is refused due to rate limiting, it should return a -standard error response of the form:: - { - "errcode": "M_LIMIT_EXCEEDED", - "error": "string", - "retry_after_ms": integer (optional) - } +Identity Servers +================ +.. NOTE:: + This section is a work in progress. -The ``retry_after_ms`` key SHOULD be included to tell the client how long they -have to wait in milliseconds before they can try again. +.. TODO-doc Dave + - 3PIDs and identity server, functions -.. TODO-spec - - Surely we should recommend an algorithm for the rate limiting, rather than letting every - homeserver come up with their own idea, causing totally unpredictable performance over - federated rooms? +Lawful Interception +------------------- +Key Escrow Servers +~~~~~~~~~~~~~~~~~~ Policy Servers ============== @@ -2586,108 +2686,6 @@ Enforcing policies ------------------ -Content repository -================== -.. NOTE:: - This section is a work in progress. - -.. TODO-spec - - path to upload - - format for thumbnail paths, mention what it is protecting against. - - content size limit and associated M_ERROR. - - -Address book repository -======================= -.. NOTE:: - This section is a work in progress. - -.. TODO-spec - - format: POST(?) wodges of json, some possible processing, then return wodges of json on GET. - - processing may remove dupes, merge contacts, pepper with extra info (e.g. matrix-ability of - contacts), etc. - - Standard json format for contacts? Piggy back off vcards? - - -Glossary -======== -.. NOTE:: - This section is a work in progress. - -Backfilling: - The process of synchronising historic state from one home server to another, - to backfill the event storage so that scrollback can be presented to the - client(s). Not to be confused with pagination. - -Context: - A single human-level entity of interest (currently, a chat room) - -EDU (Ephemeral Data Unit): - A message that relates directly to a given pair of home servers that are - exchanging it. EDUs are short-lived messages that related only to one single - pair of servers; they are not persisted for a long time and are not forwarded - on to other servers. Because of this, they have no internal ID nor previous - EDUs reference chain. - -Event: - A record of activity that records a single thing that happened on to a context - (currently, a chat room). These are the "chat messages" that Synapse makes - available. - -PDU (Persistent Data Unit): - A message that relates to a single context, irrespective of the server that - is communicating it. PDUs either encode a single Event, or a single State - change. A PDU is referred to by its PDU ID; the pair of its origin server - and local reference from that server. - -PDU ID: - The pair of PDU Origin and PDU Reference, that together globally uniquely - refers to a specific PDU. - -PDU Origin: - The name of the origin server that generated a given PDU. This may not be the - server from which it has been received, due to the way they are copied around - from server to server. The origin always records the original server that - created it. - -PDU Reference: - A local ID used to refer to a specific PDU from a given origin server. These - references are opaque at the protocol level, but may optionally have some - structured meaning within a given origin server or implementation. - -Presence: - The concept of whether a user is currently online, how available they declare - they are, and so on. See also: doc/model/presence - -Profile: - A set of metadata about a user, such as a display name, provided for the - benefit of other users. See also: doc/model/profiles - -Room ID: - An opaque string (of as-yet undecided format) that identifies a particular - room and used in PDUs referring to it. - -Room Alias: - A human-readable string of the form #name:some.domain that users can use as a - pointer to identify a room; a Directory Server will map this to its Room ID - -State: - A set of metadata maintained about a Context, which is replicated among the - servers in addition to the history of Events. - -User ID: - A string of the form @localpart:domain.name that identifies a user for - wire-protocol purposes. The localpart is meaningless outside of a particular - home server. This takes a human-readable form that end-users can use directly - if they so wish, avoiding the 3PIDs. - -Transaction: - A message which relates to the communication between a given pair of servers. - A transaction contains possibly-empty lists of PDUs and EDUs. - -.. TODO - This glossary contradicts the terms used above - especially on State Events v. "State" - and Non-State Events v. "Events". We need better consistent names. .. Links through the external API docs are below .. ============================================= From 83c53113af50b8c838e5a6795f049f63178641c9 Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Thu, 9 Oct 2014 15:51:05 +0100 Subject: [PATCH 074/106] Break a test. --- tests/test_state.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/test_state.py b/tests/test_state.py index b1624f0b25..c000eedc01 100644 --- a/tests/test_state.py +++ b/tests/test_state.py @@ -71,7 +71,7 @@ class StateTestCase(unittest.TestCase): is_new = yield self.state.handle_new_state(new_pdu) - self.assertTrue(is_new) + self.assertFalse(is_new) self.persistence.get_unresolved_state_tree.assert_called_once_with( new_pdu From 3db09c4d1576c96c41c825f04aab6deeaadb18de Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Thu, 9 Oct 2014 15:53:40 +0100 Subject: [PATCH 075/106] Still broken. --- tests/test_state.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tests/test_state.py b/tests/test_state.py index c000eedc01..5714d85b36 100644 --- a/tests/test_state.py +++ b/tests/test_state.py @@ -71,7 +71,8 @@ class StateTestCase(unittest.TestCase): is_new = yield self.state.handle_new_state(new_pdu) - self.assertFalse(is_new) + self.assertTrue(is_new) + self.assertTrue(False) self.persistence.get_unresolved_state_tree.assert_called_once_with( new_pdu From 868eb478d8b0a5691c540a74a06bafe8864abf9a Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Thu, 9 Oct 2014 15:55:07 +0100 Subject: [PATCH 076/106] Fixed test. --- tests/test_state.py | 1 - 1 file changed, 1 deletion(-) diff --git a/tests/test_state.py b/tests/test_state.py index 5714d85b36..b1624f0b25 100644 --- a/tests/test_state.py +++ b/tests/test_state.py @@ -72,7 +72,6 @@ class StateTestCase(unittest.TestCase): is_new = yield self.state.handle_new_state(new_pdu) self.assertTrue(is_new) - self.assertTrue(False) self.persistence.get_unresolved_state_tree.assert_called_once_with( new_pdu From 81b956c70dd872bea184af59d8f1f5d47f28fe32 Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Thu, 9 Oct 2014 18:08:19 +0100 Subject: [PATCH 077/106] Add spec-additions.rst with info on recaptcha and common event fields. --- docs/spec-additions.rst | 89 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 89 insertions(+) create mode 100644 docs/spec-additions.rst diff --git a/docs/spec-additions.rst b/docs/spec-additions.rst new file mode 100644 index 0000000000..8e3ffa56b6 --- /dev/null +++ b/docs/spec-additions.rst @@ -0,0 +1,89 @@ +In C-S API > Registration/Login: + +Captcha-based +~~~~~~~~~~~~~ +:Type: + ``m.login.recaptcha`` +:Description: + Login is supported by responding to a captcha, in this case Google's + Recaptcha. + +To respond to this type, reply with:: + + { + "type": "m.login.recaptcha", + "challenge": "", + "response": "" + } + +The Recaptcha parameters can be obtained in Javascript by calling:: + + Recaptcha.get_challenge(); + Recaptcha.get_response(); + +The home server MUST respond with either new credentials, the next stage of the +login process, or a standard error response. + + + + +In Events: + +Common event fields +------------------- +All events MUST have the following fields: + +``event_id`` + Type: + String. + Description: + Represents the globally unique ID for this event. + +``type`` + Type: + String. + Description: + Contains the event type, e.g. ``m.room.message`` + +``content`` + Type: + JSON Object. + Description: + Contains the content of the event. When interacting with the REST API, this is the HTTP body. + +``room_id`` + Type: + String. + Description: + Contains the ID of the room associated with this event. + +``user_id`` + Type: + String. + Description: + Contains the fully-qualified ID of the user who *sent* this event. + +State events have the additional fields: + +``state_key`` + Type: + String. + Description: + Contains the state key for this state event. If there is no state key for this state event, this + will be an empty string. The presence of ``state_key`` makes this event a state event. + +``required_power_level`` + Type: + Integer. + Description: + Contains the minimum power level a user must have before they can update this event. + +``prev_content`` + Type: + JSON Object. + Description: + Optional. Contains the previous ``content`` for this event. If there is no previous content, this + key will be missing. + +.. TODO-spec + How do "age" and "ts" fit in to all this? Which do we expose? From e1170d4edbc3563730028047c23a4169e6420c59 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Thu, 9 Oct 2014 20:38:00 +0200 Subject: [PATCH 078/106] move matrix-generic content to new matrix-doc git project --- docs/README.rst | 6 + docs/client-server/howto.rst | 637 ---- docs/definitions.rst | 53 - docs/human-id-rules.rst | 79 - .../documentation_style.rst | 43 - docs/spec-additions.rst | 89 - docs/specification-NOTHAVE.rst | 30 - docs/specification.rst | 2739 ----------------- docs/state_resolution.rst | 51 - 9 files changed, 6 insertions(+), 3721 deletions(-) create mode 100644 docs/README.rst delete mode 100644 docs/client-server/howto.rst delete mode 100644 docs/definitions.rst delete mode 100644 docs/human-id-rules.rst delete mode 100644 docs/implementation-notes/documentation_style.rst delete mode 100644 docs/spec-additions.rst delete mode 100644 docs/specification-NOTHAVE.rst delete mode 100644 docs/specification.rst delete mode 100644 docs/state_resolution.rst diff --git a/docs/README.rst b/docs/README.rst new file mode 100644 index 0000000000..3012da8b19 --- /dev/null +++ b/docs/README.rst @@ -0,0 +1,6 @@ +All matrix-generic documentation now lives in its own project at + +github.com/matrix-org/matrix-doc.git + +Only Synapse implementation-specific documentation lives here now +(together with some older stuff will be shortly migrated over to matrix-doc) diff --git a/docs/client-server/howto.rst b/docs/client-server/howto.rst deleted file mode 100644 index 37346224af..0000000000 --- a/docs/client-server/howto.rst +++ /dev/null @@ -1,637 +0,0 @@ -.. TODO kegan - Room config (specifically: message history, - public rooms). /register seems super simplistic compared to /login, maybe it - would be better if /register used the same technique as /login? /register should - be "user" not "user_id". - - -How to use the client-server API -================================ - -This guide focuses on how the client-server APIs *provided by the reference -home server* can be used. Since this is specific to a home server -implementation, there may be variations in relation to registering/logging in -which are not covered in extensive detail in this guide. - -If you haven't already, get a home server up and running on -``http://localhost:8008``. - - -Accounts -======== -Before you can send and receive messages, you must **register** for an account. -If you already have an account, you must **login** into it. - -`Try out the fiddle`__ - -.. __: http://jsfiddle.net/gh/get/jquery/1.8.3/matrix-org/synapse/tree/master/jsfiddles/register_login - -Registration ------------- -The aim of registration is to get a user ID and access token which you will need -when accessing other APIs:: - - curl -XPOST -d '{"user":"example", "password":"wordpass", "type":"m.login.password"}' "http://localhost:8008/_matrix/client/api/v1/register" - - { - "access_token": "QGV4YW1wbGU6bG9jYWxob3N0.AqdSzFmFYrLrTmteXc", - "home_server": "localhost", - "user_id": "@example:localhost" - } - -NB: If a ``user`` is not specified, one will be randomly generated for you. -If you do not specify a ``password``, you will be unable to login to the account -if you forget the ``access_token``. - -Implementation note: The matrix specification does not enforce how users -register with a server. It just specifies the URL path and absolute minimum -keys. The reference home server uses a username/password to authenticate user, -but other home servers may use different methods. This is why you need to -specify the ``type`` of method. - -Login ------ -The aim when logging in is to get an access token for your existing user ID:: - - curl -XGET "http://localhost:8008/_matrix/client/api/v1/login" - - { - "flows": [ - { - "type": "m.login.password" - } - ] - } - - curl -XPOST -d '{"type":"m.login.password", "user":"example", "password":"wordpass"}' "http://localhost:8008/_matrix/client/api/v1/login" - - { - "access_token": "QGV4YW1wbGU6bG9jYWxob3N0.vRDLTgxefmKWQEtgGd", - "home_server": "localhost", - "user_id": "@example:localhost" - } - -Implementation note: Different home servers may implement different methods for -logging in to an existing account. In order to check that you know how to login -to this home server, you must perform a ``GET`` first and make sure you -recognise the login type. If you do not know how to login, you can -``GET /login/fallback`` which will return a basic webpage which you can use to -login. The reference home server implementation support username/password login, -but other home servers may support different login methods (e.g. OAuth2). - - -Communicating -============= - -In order to communicate with another user, you must **create a room** with that -user and **send a message** to that room. - -`Try out the fiddle`__ - -.. __: http://jsfiddle.net/gh/get/jquery/1.8.3/matrix-org/synapse/tree/master/jsfiddles/create_room_send_msg - -Creating a room ---------------- -If you want to send a message to someone, you have to be in a room with them. To -create a room:: - - curl -XPOST -d '{"room_alias_name":"tutorial"}' "http://localhost:8008/_matrix/client/api/v1/createRoom?access_token=YOUR_ACCESS_TOKEN" - - { - "room_alias": "#tutorial:localhost", - "room_id": "!CvcvRuDYDzTOzfKKgh:localhost" - } - -The "room alias" is a human-readable string which can be shared with other users -so they can join a room, rather than the room ID which is a randomly generated -string. You can have multiple room aliases per room. - -.. TODO(kegan) - How to add/remove aliases from an existing room. - - -Sending messages ----------------- -You can now send messages to this room:: - - curl -XPOST -d '{"msgtype":"m.text", "body":"hello"}' "http://localhost:8008/_matrix/client/api/v1/rooms/%21CvcvRuDYDzTOzfKKgh%3Alocalhost/send/m.room.message?access_token=YOUR_ACCESS_TOKEN" - - { - "event_id": "YUwRidLecu" - } - -The event ID returned is a unique ID which identifies this message. - -NB: There are no limitations to the types of messages which can be exchanged. -The only requirement is that ``"msgtype"`` is specified. The Matrix -specification outlines the following standard types: ``m.text``, ``m.image``, -``m.audio``, ``m.video``, ``m.location``, ``m.emote``. See the specification for -more information on these types. - -Users and rooms -=============== - -Each room can be configured to allow or disallow certain rules. In particular, -these rules may specify if you require an **invitation** from someone already in -the room in order to **join the room**. In addition, you may also be able to -join a room **via a room alias** if one was set up. - -`Try out the fiddle`__ - -.. __: http://jsfiddle.net/gh/get/jquery/1.8.3/matrix-org/synapse/tree/master/jsfiddles/room_memberships - -Inviting a user to a room -------------------------- -You can directly invite a user to a room like so:: - - curl -XPOST -d '{"user_id":"@myfriend:localhost"}' "http://localhost:8008/_matrix/client/api/v1/rooms/%21CvcvRuDYDzTOzfKKgh%3Alocalhost/invite?access_token=YOUR_ACCESS_TOKEN" - -This informs ``@myfriend:localhost`` of the room ID -``!CvcvRuDYDzTOzfKKgh:localhost`` and allows them to join the room. - -Joining a room via an invite ----------------------------- -If you receive an invite, you can join the room:: - - curl -XPOST -d '{}' "http://localhost:8008/_matrix/client/api/v1/rooms/%21CvcvRuDYDzTOzfKKgh%3Alocalhost/join?access_token=YOUR_ACCESS_TOKEN" - -NB: Only the person invited (``@myfriend:localhost``) can change the membership -state to ``"join"``. Repeatedly joining a room does nothing. - -Joining a room via an alias ---------------------------- -Alternatively, if you know the room alias for this room and the room config -allows it, you can directly join a room via the alias:: - - curl -XPOST -d '{}' "http://localhost:8008/_matrix/client/api/v1/join/%23tutorial%3Alocalhost?access_token=YOUR_ACCESS_TOKEN" - - { - "room_id": "!CvcvRuDYDzTOzfKKgh:localhost" - } - -You will need to use the room ID when sending messages, not the room alias. - -NB: If the room is configured to be an invite-only room, you will still require -an invite in order to join the room even though you know the room alias. As a -result, it is more common to see a room alias in relation to a public room, -which do not require invitations. - -Getting events -============== -An event is some interesting piece of data that a client may be interested in. -It can be a message in a room, a room invite, etc. There are many different ways -of getting events, depending on what the client already knows. - -`Try out the fiddle`__ - -.. __: http://jsfiddle.net/gh/get/jquery/1.8.3/matrix-org/synapse/tree/master/jsfiddles/event_stream - -Getting all state ------------------ -If the client doesn't know any information on the rooms the user is -invited/joined on, they can get all the user's state for all rooms:: - - curl -XGET "http://localhost:8008/_matrix/client/api/v1/initialSync?access_token=YOUR_ACCESS_TOKEN" - - { - "end": "s39_18_0", - "presence": [ - { - "content": { - "last_active_ago": 1061436, - "user_id": "@example:localhost" - }, - "type": "m.presence" - } - ], - "rooms": [ - { - "membership": "join", - "messages": { - "chunk": [ - { - "content": { - "@example:localhost": 10, - "default": 0 - }, - "event_id": "wAumPSTsWF", - "required_power_level": 10, - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "", - "ts": 1409665585188, - "type": "m.room.power_levels", - "user_id": "@example:localhost" - }, - { - "content": { - "join_rule": "public" - }, - "event_id": "jrLVqKHKiI", - "required_power_level": 10, - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "", - "ts": 1409665585188, - "type": "m.room.join_rules", - "user_id": "@example:localhost" - }, - { - "content": { - "level": 10 - }, - "event_id": "WpmTgsNWUZ", - "required_power_level": 10, - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "", - "ts": 1409665585188, - "type": "m.room.add_state_level", - "user_id": "@example:localhost" - }, - { - "content": { - "level": 0 - }, - "event_id": "qUMBJyKsTQ", - "required_power_level": 10, - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "", - "ts": 1409665585188, - "type": "m.room.send_event_level", - "user_id": "@example:localhost" - }, - { - "content": { - "ban_level": 5, - "kick_level": 5 - }, - "event_id": "YAaDmKvoUW", - "required_power_level": 10, - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "", - "ts": 1409665585188, - "type": "m.room.ops_levels", - "user_id": "@example:localhost" - }, - { - "content": { - "avatar_url": null, - "displayname": null, - "membership": "join" - }, - "event_id": "RJbPMtCutf", - "membership": "join", - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "@example:localhost", - "ts": 1409665586730, - "type": "m.room.member", - "user_id": "@example:localhost" - }, - { - "content": { - "body": "hello", - "hsob_ts": 1409665660439, - "msgtype": "m.text" - }, - "event_id": "YUwRidLecu", - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "ts": 1409665660439, - "type": "m.room.message", - "user_id": "@example:localhost" - }, - { - "content": { - "membership": "invite" - }, - "event_id": "YjNuBKnPsb", - "membership": "invite", - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "@myfriend:localhost", - "ts": 1409666426819, - "type": "m.room.member", - "user_id": "@example:localhost" - }, - { - "content": { - "avatar_url": null, - "displayname": null, - "membership": "join", - "prev": "join" - }, - "event_id": "KWwdDjNZnm", - "membership": "join", - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "@example:localhost", - "ts": 1409666551582, - "type": "m.room.member", - "user_id": "@example:localhost" - }, - { - "content": { - "avatar_url": null, - "displayname": null, - "membership": "join" - }, - "event_id": "JFLVteSvQc", - "membership": "join", - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "@example:localhost", - "ts": 1409666587265, - "type": "m.room.member", - "user_id": "@example:localhost" - } - ], - "end": "s39_18_0", - "start": "t1-11_18_0" - }, - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state": [ - { - "content": { - "creator": "@example:localhost" - }, - "event_id": "dMUoqVTZca", - "required_power_level": 10, - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "", - "ts": 1409665585188, - "type": "m.room.create", - "user_id": "@example:localhost" - }, - { - "content": { - "@example:localhost": 10, - "default": 0 - }, - "event_id": "wAumPSTsWF", - "required_power_level": 10, - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "", - "ts": 1409665585188, - "type": "m.room.power_levels", - "user_id": "@example:localhost" - }, - { - "content": { - "join_rule": "public" - }, - "event_id": "jrLVqKHKiI", - "required_power_level": 10, - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "", - "ts": 1409665585188, - "type": "m.room.join_rules", - "user_id": "@example:localhost" - }, - { - "content": { - "level": 10 - }, - "event_id": "WpmTgsNWUZ", - "required_power_level": 10, - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "", - "ts": 1409665585188, - "type": "m.room.add_state_level", - "user_id": "@example:localhost" - }, - { - "content": { - "level": 0 - }, - "event_id": "qUMBJyKsTQ", - "required_power_level": 10, - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "", - "ts": 1409665585188, - "type": "m.room.send_event_level", - "user_id": "@example:localhost" - }, - { - "content": { - "ban_level": 5, - "kick_level": 5 - }, - "event_id": "YAaDmKvoUW", - "required_power_level": 10, - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "", - "ts": 1409665585188, - "type": "m.room.ops_levels", - "user_id": "@example:localhost" - }, - { - "content": { - "membership": "invite" - }, - "event_id": "YjNuBKnPsb", - "membership": "invite", - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "@myfriend:localhost", - "ts": 1409666426819, - "type": "m.room.member", - "user_id": "@example:localhost" - }, - { - "content": { - "avatar_url": null, - "displayname": null, - "membership": "join" - }, - "event_id": "JFLVteSvQc", - "membership": "join", - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "@example:localhost", - "ts": 1409666587265, - "type": "m.room.member", - "user_id": "@example:localhost" - } - ] - } - ] - } - -This returns all the room information the user is invited/joined on, as well as -all of the presences relevant for these rooms. This can be a LOT of data. You -may just want the most recent event for each room. This can be achieved by -applying query parameters to ``limit`` this request:: - - curl -XGET "http://localhost:8008/_matrix/client/api/v1/initialSync?limit=1&access_token=YOUR_ACCESS_TOKEN" - - { - "end": "s39_18_0", - "presence": [ - { - "content": { - "last_active_ago": 1279484, - "user_id": "@example:localhost" - }, - "type": "m.presence" - } - ], - "rooms": [ - { - "membership": "join", - "messages": { - "chunk": [ - { - "content": { - "avatar_url": null, - "displayname": null, - "membership": "join" - }, - "event_id": "JFLVteSvQc", - "membership": "join", - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "@example:localhost", - "ts": 1409666587265, - "type": "m.room.member", - "user_id": "@example:localhost" - } - ], - "end": "s39_18_0", - "start": "t10-30_18_0" - }, - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state": [ - { - "content": { - "creator": "@example:localhost" - }, - "event_id": "dMUoqVTZca", - "required_power_level": 10, - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "", - "ts": 1409665585188, - "type": "m.room.create", - "user_id": "@example:localhost" - }, - { - "content": { - "@example:localhost": 10, - "default": 0 - }, - "event_id": "wAumPSTsWF", - "required_power_level": 10, - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "", - "ts": 1409665585188, - "type": "m.room.power_levels", - "user_id": "@example:localhost" - }, - { - "content": { - "join_rule": "public" - }, - "event_id": "jrLVqKHKiI", - "required_power_level": 10, - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "", - "ts": 1409665585188, - "type": "m.room.join_rules", - "user_id": "@example:localhost" - }, - { - "content": { - "level": 10 - }, - "event_id": "WpmTgsNWUZ", - "required_power_level": 10, - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "", - "ts": 1409665585188, - "type": "m.room.add_state_level", - "user_id": "@example:localhost" - }, - { - "content": { - "level": 0 - }, - "event_id": "qUMBJyKsTQ", - "required_power_level": 10, - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "", - "ts": 1409665585188, - "type": "m.room.send_event_level", - "user_id": "@example:localhost" - }, - { - "content": { - "ban_level": 5, - "kick_level": 5 - }, - "event_id": "YAaDmKvoUW", - "required_power_level": 10, - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "", - "ts": 1409665585188, - "type": "m.room.ops_levels", - "user_id": "@example:localhost" - }, - { - "content": { - "membership": "invite" - }, - "event_id": "YjNuBKnPsb", - "membership": "invite", - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "@myfriend:localhost", - "ts": 1409666426819, - "type": "m.room.member", - "user_id": "@example:localhost" - }, - { - "content": { - "avatar_url": null, - "displayname": null, - "membership": "join" - }, - "event_id": "JFLVteSvQc", - "membership": "join", - "room_id": "!MkDbyRqnvTYnoxjLYx:localhost", - "state_key": "@example:localhost", - "ts": 1409666587265, - "type": "m.room.member", - "user_id": "@example:localhost" - } - ] - } - ] - } - -Getting live state ------------------- -Once you know which rooms the client has previously interacted with, you need to -listen for incoming events. This can be done like so:: - - curl -XGET "http://localhost:8008/_matrix/client/api/v1/events?access_token=YOUR_ACCESS_TOKEN" - - { - "chunk": [], - "end": "s39_18_0", - "start": "s39_18_0" - } - -This will block waiting for an incoming event, timing out after several seconds. -Even if there are no new events (as in the example above), there will be some -pagination stream response keys. The client should make subsequent requests -using the value of the ``"end"`` key (in this case ``s39_18_0``) as the ``from`` -query parameter e.g. ``http://localhost:8008/_matrix/client/api/v1/events?access -_token=YOUR_ACCESS_TOKEN&from=s39_18_0``. This value should be stored so when the -client reopens your app after a period of inactivity, you can resume from where -you got up to in the event stream. If it has been a long period of inactivity, -there may be LOTS of events waiting for the user. In this case, you may wish to -get all state instead and then resume getting live state from a newer end token. - -NB: The timeout can be changed by adding a ``timeout`` query parameter, which is -in milliseconds. A timeout of 0 will not block. - - -Example application -------------------- -The following example demonstrates registration and login, live event streaming, -creating and joining rooms, sending messages, getting member lists and getting -historical messages for a room. This covers most functionality of a messaging -application. - -`Try out the fiddle`__ - -.. __: http://jsfiddle.net/gh/get/jquery/1.8.3/matrix-org/synapse/tree/master/jsfiddles/example_app diff --git a/docs/definitions.rst b/docs/definitions.rst deleted file mode 100644 index b0f95ae9d7..0000000000 --- a/docs/definitions.rst +++ /dev/null @@ -1,53 +0,0 @@ -Definitions -=========== - -# *Event* -- A JSON object that represents a piece of information to be -distributed to the the room. The object includes a payload and metadata, -including a `type` used to indicate what the payload is for and how to process -them. It also includes one or more references to previous events. - -# *Event graph* -- Events and their references to previous events form a -directed acyclic graph. All events must be a descendant of the first event in a -room, except for a few special circumstances. - -# *State event* -- A state event is an event that has a non-null string valued -`state_key` field. It may also include a `prev_state` key referencing exactly -one state event with the same type and state key, in the same event graph. - -# *State tree* -- A state tree is a tree formed by a collection of state events -that have the same type and state key (all in the same event graph. - -# *State resolution algorithm* -- An algorithm that takes a state tree as input -and selects a single leaf node. - -# *Current state event* -- The leaf node of a given state tree that has been -selected by the state resolution algorithm. - -# *Room state* / *state dictionary* / *current state* -- A mapping of the pair -(event type, state key) to the current state event for that pair. - -# *Room* -- An event graph and its associated state dictionary. An event is in -the room if it is part of the event graph. - -# *Topological ordering* -- The partial ordering that can be extracted from the -event graph due to it being a DAG. - -(The state definitions are purposely slightly ill-defined, since if we allow -deleting events we might end up with multiple state trees for a given event -type and state key pair.) - -Federation specific -------------------- -# *(Persistent data unit) PDU* -- An encoding of an event for distribution of -the server to server protocol. - -# *(Ephemeral data unit) EDU* -- A piece of information that is sent between -servers and doesn't encode an event. - -Client specific ---------------- -# *Child events* -- Events that reference a single event in the same room -independently of the event graph. - -# *Collapsed events* -- Events that have all child events that reference it -included in the JSON object. diff --git a/docs/human-id-rules.rst b/docs/human-id-rules.rst deleted file mode 100644 index 3a1ff39892..0000000000 --- a/docs/human-id-rules.rst +++ /dev/null @@ -1,79 +0,0 @@ -This document outlines the format for human-readable IDs within matrix. - -Overview --------- -UTF-8 is quickly becoming the standard character encoding set on the web. As -such, Matrix requires that all strings MUST be encoded as UTF-8. However, -using Unicode as the character set for human-readable IDs is troublesome. There -are many different characters which appear identical to each other, but would -identify different users. In addition, there are non-printable characters which -cannot be rendered by the end-user. This opens up a security vulnerability with -phishing/spoofing of IDs, commonly known as a homograph attack. - -Web browers encountered this problem when International Domain Names were -introduced. A variety of checks were put in place in order to protect users. If -an address failed the check, the raw punycode would be displayed to disambiguate -the address. Similar checks are performed by home servers in Matrix. However, -Matrix does not use punycode representations, and so does not show raw punycode -on a failed check. Instead, home servers must outright reject these misleading -IDs. - -Types of human-readable IDs ---------------------------- -There are two main human-readable IDs in question: - -- Room aliases -- User IDs - -Room aliases look like ``#localpart:domain``. These aliases point to opaque -non human-readable room IDs. These pointers can change, so there is already an -issue present with the same ID pointing to a different destination at a later -date. - -User IDs look like ``@localpart:domain``. These represent actual end-users, and -unlike room aliases, there is no layer of indirection. This presents a much -greater concern with homograph attacks. - -Checks ------- -- Similar to web browsers. -- blacklisted chars (e.g. non-printable characters) -- mix of language sets from 'preferred' language not allowed. -- Language sets from CLDR dataset. -- Treated in segments (localpart, domain) -- Additional restrictions for ease of processing IDs. - - Room alias localparts MUST NOT have ``#`` or ``:``. - - User ID localparts MUST NOT have ``@`` or ``:``. - -Rejecting ---------- -- Home servers MUST reject room aliases which do not pass the check, both on - GETs and PUTs. -- Home servers MUST reject user ID localparts which do not pass the check, both - on creation and on events. -- Any home server whose domain does not pass this check, MUST use their punycode - domain name instead of the IDN, to prevent other home servers rejecting you. -- Error code is ``M_FAILED_HUMAN_ID_CHECK``. (generic enough for both failing - due to homograph attacks, and failing due to including ``:`` s, etc) -- Error message MAY go into further information about which characters were - rejected and why. -- Error message SHOULD contain a ``failed_keys`` key which contains an array - of strings which represent the keys which failed the check e.g:: - - failed_keys: [ user_id, room_alias ] - -Other considerations --------------------- -- Basic security: Informational key on the event attached by HS to say "unsafe - ID". Problem: clients can just ignore it, and since it will appear only very - rarely, easy to forget when implementing clients. -- Moderate security: Requires client handshake. Forces clients to implement - a check, else they cannot communicate with the misleading ID. However, this is - extra overhead in both client implementations and round-trips. -- High security: Outright rejection of the ID at the point of creation / - receiving event. Point of creation rejection is preferable to avoid the ID - entering the system in the first place. However, malicious HSes can just allow - the ID. Hence, other home servers must reject them if they see them in events. - Client never sees the problem ID, provided the HS is correctly implemented. -- High security decided; client doesn't need to worry about it, no additional - protocol complexity aside from rejection of an event. \ No newline at end of file diff --git a/docs/implementation-notes/documentation_style.rst b/docs/implementation-notes/documentation_style.rst deleted file mode 100644 index c365d09dff..0000000000 --- a/docs/implementation-notes/documentation_style.rst +++ /dev/null @@ -1,43 +0,0 @@ -=================== -Documentation Style -=================== - -A brief single sentence to describe what this file contains; in this case a -description of the style to write documentation in. - - -Sections -======== - -Each section should be separated from the others by two blank lines. Headings -should be underlined using a row of equals signs (===). Paragraphs should be -separated by a single blank line, and wrap to no further than 80 columns. - -[[TODO(username): if you want to leave some unanswered questions, notes for -further consideration, or other kinds of comment, use a TODO section. Make sure -to notate it with your name so we know who to ask about it!]] - -Subsections ------------ - -If required, subsections can use a row of dashes to underline their header. A -single blank line between subsections of a single section. - - -Bullet Lists -============ - - * Bullet lists can use asterisks with a single space either side. - - * Another blank line between list elements. - - -Definition Lists -================ - -Terms: - Start in the first column, ending with a colon - -Definitions: - Take a two space indent, following immediately from the term without a blank - line before it, but having a blank line afterwards. diff --git a/docs/spec-additions.rst b/docs/spec-additions.rst deleted file mode 100644 index 8e3ffa56b6..0000000000 --- a/docs/spec-additions.rst +++ /dev/null @@ -1,89 +0,0 @@ -In C-S API > Registration/Login: - -Captcha-based -~~~~~~~~~~~~~ -:Type: - ``m.login.recaptcha`` -:Description: - Login is supported by responding to a captcha, in this case Google's - Recaptcha. - -To respond to this type, reply with:: - - { - "type": "m.login.recaptcha", - "challenge": "", - "response": "" - } - -The Recaptcha parameters can be obtained in Javascript by calling:: - - Recaptcha.get_challenge(); - Recaptcha.get_response(); - -The home server MUST respond with either new credentials, the next stage of the -login process, or a standard error response. - - - - -In Events: - -Common event fields -------------------- -All events MUST have the following fields: - -``event_id`` - Type: - String. - Description: - Represents the globally unique ID for this event. - -``type`` - Type: - String. - Description: - Contains the event type, e.g. ``m.room.message`` - -``content`` - Type: - JSON Object. - Description: - Contains the content of the event. When interacting with the REST API, this is the HTTP body. - -``room_id`` - Type: - String. - Description: - Contains the ID of the room associated with this event. - -``user_id`` - Type: - String. - Description: - Contains the fully-qualified ID of the user who *sent* this event. - -State events have the additional fields: - -``state_key`` - Type: - String. - Description: - Contains the state key for this state event. If there is no state key for this state event, this - will be an empty string. The presence of ``state_key`` makes this event a state event. - -``required_power_level`` - Type: - Integer. - Description: - Contains the minimum power level a user must have before they can update this event. - -``prev_content`` - Type: - JSON Object. - Description: - Optional. Contains the previous ``content`` for this event. If there is no previous content, this - key will be missing. - -.. TODO-spec - How do "age" and "ts" fit in to all this? Which do we expose? diff --git a/docs/specification-NOTHAVE.rst b/docs/specification-NOTHAVE.rst deleted file mode 100644 index 369594f6ae..0000000000 --- a/docs/specification-NOTHAVE.rst +++ /dev/null @@ -1,30 +0,0 @@ -Matrix Specification NOTHAVEs -============================= - -This document contains sections of the main specification that have been -temporarily removed, because they specify intentions or aspirations that have -in no way yet been implemented. Rather than outright-deleting them, they have -been moved here so as to stand as an initial version for such time as they -become extant. - - -Presence -======== - -Idle Time ---------- -As well as the basic ``presence`` field, the presence information can also show -a sense of an "idle timer". This should be maintained individually by the -user's clients, and the home server can take the highest reported time as that -to report. When a user is offline, the home server can still report when the -user was last seen online. - -Device Type ------------ - -Client devices that may limit the user experience somewhat (such as "mobile" -devices with limited ability to type on a real keyboard or read large amounts of -text) should report this to the home server, as this is also useful information -to report as "presence" if the user cannot be expected to provide a good typed -response to messages. - diff --git a/docs/specification.rst b/docs/specification.rst deleted file mode 100644 index 9f7c86f21c..0000000000 --- a/docs/specification.rst +++ /dev/null @@ -1,2739 +0,0 @@ -Matrix Specification -==================== - -WARNING -======= - -.. WARNING:: - The Matrix specification is still very much evolving: the API is not yet frozen - and this document is in places incomplete, stale, and may contain security - issues. Needless to say, we have made every effort to highlight the problem - areas that we're aware of. - - We're publishing it at this point because it's complete enough to be more than - useful and provide a canonical reference to how Matrix is evolving. Our end - goal is to mirror WHATWG's `Living Standard `_ - approach except right now Matrix is more in the process of being born than actually being - living! - -.. contents:: Table of Contents -.. sectnum:: - -Matrix is a new set of open APIs for open-federated Instant Messaging and VoIP -functionality, designed to create and support a new global real-time -communication ecosystem on the internet. This specification is the ongoing -result of standardising the APIs used by the various components of the Matrix -ecosystem to communicate with one another. - -The principles that Matrix attempts to follow are: - -- Pragmatic Web-friendly APIs (i.e. JSON over REST) -- Keep It Simple & Stupid - - + provide a simple architecture with minimal third-party dependencies. - -- Fully open: - - + Fully open federation - anyone should be able to participate in the global - Matrix network - + Fully open standard - publicly documented standard with no IP or patent - licensing encumbrances - + Fully open source reference implementation - liberally-licensed example - implementations with no IP or patent licensing encumbrances - -- Empowering the end-user - - + The user should be able to choose the server and clients they use - + The user should be control how private their communication is - + The user should know precisely where their data is stored - -- Fully decentralised - no single points of control over conversations or the - network as a whole -- Learning from history to avoid repeating it - - + Trying to take the best aspects of XMPP, SIP, IRC, SMTP, IMAP and NNTP - whilst trying to avoid their failings - -The functionality that Matrix provides includes: - -- Creation and management of fully distributed chat rooms with no - single points of control or failure -- Eventually-consistent cryptographically secure synchronisation of room - state across a global open network of federated servers and services -- Sending and receiving extensible messages in a room with (optional) - end-to-end encryption -- Extensible user management (inviting, joining, leaving, kicking, banning) - mediated by a power-level based user privilege system. -- Extensible room state management (room naming, aliasing, topics, bans) -- Extensible user profile management (avatars, displaynames, etc) -- Managing user accounts (registration, login, logout) -- Use of 3rd Party IDs (3PIDs) such as email addresses, phone numbers, - Facebook accounts to authenticate, identify and discover users on Matrix. -- Trusted federation of Identity servers for: - - + Publishing user public keys for PKI - + Mapping of 3PIDs to Matrix IDs - -The end goal of Matrix is to be a ubiquitous messaging layer for synchronising -arbitrary data between sets of people, devices and services - be that for -instant messages, VoIP call setups, or any other objects that need to be -reliably and persistently pushed from A to B in an interoperable and federated -manner. - -Basis -===== - -Architecture ------------- - -Clients transmit data to other clients through home servers (HSes). Clients do -not communicate with each other directly. - -:: - - How data flows between clients - ============================== - - { Matrix client A } { Matrix client B } - ^ | ^ | - | events | | events | - | V | V - +------------------+ +------------------+ - | |---------( HTTP )---------->| | - | Home Server | | Home Server | - | |<--------( HTTP )-----------| | - +------------------+ Federation +------------------+ - -A "Client" typically represents a human using a web application or mobile app. -Clients use the "Client-to-Server" (C-S) API to communicate with their home -server, which stores their profile data and their record of the conversations -in which they participate. Each client is associated with a user account (and -may optionally support multiple user accounts). A user account is represented -by a unique "User ID". This ID is namespaced to the home server which allocated -the account and looks like:: - - @localpart:domain - -The ``localpart`` of a user ID may be a user name, or an opaque ID identifying -this user. They are case-insensitive. - -.. TODO-spec - - Need to specify precise grammar for Matrix IDs - -A "Home Server" is a server which provides C-S APIs and has the ability to -federate with other HSes. It is typically responsible for multiple clients. -"Federation" is the term used to describe the sharing of data between two or -more home servers. - -Data in Matrix is encapsulated in an "event". An event is an action within the -system. Typically each action (e.g. sending a message) correlates with exactly -one event. Each event has a ``type`` which is used to differentiate different -kinds of data. ``type`` values MUST be uniquely globally namespaced following -Java's `package naming conventions -`, e.g. -``com.example.myapp.event``. The special top-level namespace ``m.`` is reserved -for events defined in the Matrix specification. Events are usually sent in the -context of a "Room". - -Room structure -~~~~~~~~~~~~~~ - -A room is a conceptual place where users can send and receive events. Rooms can -be created, joined and left. Events are sent to a room, and all participants in -that room with sufficient access will receive the event. Rooms are uniquely -identified internally via a "Room ID", which look like:: - - !opaque_id:domain - -There is exactly one room ID for each room. Whilst the room ID does contain a -domain, it is simply for globally namespacing room IDs. The room does NOT -reside on the domain specified. Room IDs are not meant to be human readable. -They ARE case-sensitive. - -The following diagram shows an ``m.room.message`` event being sent in the room -``!qporfwt:matrix.org``:: - - { @alice:matrix.org } { @bob:domain.com } - | ^ - | | - Room ID: !qporfwt:matrix.org Room ID: !qporfwt:matrix.org - Event type: m.room.message Event type: m.room.message - Content: { JSON object } Content: { JSON object } - | | - V | - +------------------+ +------------------+ - | Home Server | | Home Server | - | matrix.org |<-------Federation------->| domain.com | - +------------------+ +------------------+ - | ................................. | - |______| Shared State |_______| - | Room ID: !qporfwt:matrix.org | - | Servers: matrix.org, domain.com | - | Members: | - | - @alice:matrix.org | - | - @bob:domain.com | - |.................................| - -Federation maintains shared state between multiple home servers, such that when -an event is sent to a room, the home server knows where to forward the event on -to, and how to process the event. State is scoped to a single room, and -federation ensures that all home servers have the information they need, even -if that means the home server has to request more information from another home -server before processing the event. - -Room Aliases -~~~~~~~~~~~~ - -Each room can also have multiple "Room Aliases", which looks like:: - - #room_alias:domain - - .. TODO - - Need to specify precise grammar for Room Aliases - -A room alias "points" to a room ID and is the human-readable label by which -rooms are publicised and discovered. The room ID the alias is pointing to can -be obtained by visiting the domain specified. They are case-insensitive. Note -that the mapping from a room alias to a room ID is not fixed, and may change -over time to point to a different room ID. For this reason, Clients SHOULD -resolve the room alias to a room ID once and then use that ID on subsequent -requests. - -When resolving a room alias the server will also respond with a list of servers -that are in the room that can be used to join via. - -:: - - GET - #matrix:domain.com !aaabaa:matrix.org - | ^ - | | - _______V____________________|____ - | domain.com | - | Mappings: | - | #matrix >> !aaabaa:matrix.org | - | #golf >> !wfeiofh:sport.com | - | #bike >> !4rguxf:matrix.org | - |________________________________| - -Identity -~~~~~~~~ - -Users in Matrix are identified via their user ID. However, existing 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 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 can then be used by other Matrix -users in order to discover other users, according to a strict set of privacy -permissions. - -In order to ensure that the mapping from 3PID to user ID is genuine, a globally -federated cluster of trusted "Identity Servers" (IS) are used to perform -authentication of the 3PID. Identity servers are also used to preserve the -mapping indefinitely, by replicating the mappings across multiple ISes. - -Usage of an IS is not required in order for a client application to be part of -the Matrix ecosystem. However, without one clients will not be able to look up -user IDs using 3PIDs. - -Presence -~~~~~~~~ -.. NOTE:: - This section is a work in progress. - -Each user has the concept of presence information. This encodes the -"availability" of that user, suitable for display on other user's clients. This -is transmitted as an ``m.presence`` event and is one of the few events which -are sent *outside the context of a room*. The basic piece of presence -information is represented by the ``presence`` key, which is an enum of one of -the following: - - - ``online`` : The default state when the user is connected to an event - stream. - - ``unavailable`` : The user is not reachable at this time. - - ``offline`` : The user is not connected to an event stream. - - ``free_for_chat`` : The user is generally willing to receive messages - moreso than default. - - ``hidden`` : Behaves as offline, but allows the user to see the client - state anyway and generally interact with client features. (Not yet - implemented in synapse). - -This basic ``presence`` field applies to the user as a whole, regardless of how -many client devices they have connected. The home server should synchronise -this status choice among multiple devices to ensure the user gets a consistent -experience. - -In addition, the server maintains a timestamp of the last time it saw an active -action from the user; either sending a message to a room, or changing presence -state from a lower to a higher level of availability (thus: changing state from -``unavailable`` to ``online`` will count as an action for being active, whereas -in the other direction will not). This timestamp is presented via a key called -``last_active_ago``, which gives the relative number of miliseconds since the -message is generated/emitted, that the user was last seen active. - -Home servers can also use the user's choice of presence state as a signal for -how to handle new private one-to-one chat message requests. For example, it -might decide: - - - ``free_for_chat`` : accept anything - - ``online`` : accept from anyone in my addres book list - - ``busy`` : accept from anyone in this "important people" group in my - address book list - -Presence List -+++++++++++++ -Each user's home server stores a "presence list" for that user. This stores a -list of other user IDs the user has chosen to add to it. To be added to this -list, the user being added must receive permission from the list owner. Once -granted, both user's HS(es) store this information. Since such subscriptions -are likely to be bidirectional, HSes may wish to automatically accept requests -when a reverse subscription already exists. - -As a convenience, presence lists should support the ability to collect users -into groups, which could allow things like inviting the entire group to a new -("ad-hoc") chat room, or easy interaction with the profile information ACL -implementation of the HS. - -Presence and Permissions -++++++++++++++++++++++++ -For a viewing user to be allowed to see the presence information of a target -user, either: - - - The target user has allowed the viewing user to add them to their presence - list, or - - The two users share at least one room in common - -In the latter case, this allows for clients to display some minimal sense of -presence information in a user list for a room. - -Profiles -~~~~~~~~ -.. NOTE:: - This section is a work in progress. - -.. TODO-spec - - Metadata extensibility - -Internally within Matrix users are referred to by their user ID, which is -typically a compact unique identifier. Profiles grant users the ability to see -human-readable names for other users that are in some way meaningful to them. -Additionally, profiles can publish additional information, such as the user's -age or location. - -A Profile consists of a display name, an avatar picture, and a set of other -metadata fields that the user may wish to publish (email address, phone -numbers, website URLs, etc...). This specification puts no requirements on the -display name other than it being a valid unicode string. Avatar images are not -stored directly; instead the home server stores an ``http``-scheme URL where -clients may fetch it from. - -API Standards -------------- - -The mandatory baseline for communication in Matrix is exchanging JSON objects -over RESTful HTTP APIs. HTTPS is mandated as the baseline for server-server -(federation) communication. HTTPS is recommended for client-server -communication, although HTTP may be supported as a fallback to support basic -HTTP clients. More efficient optional transports for client-server -communication will in future be supported as optional extensions - e.g. a -packed binary encoding over stream-cipher encrypted TCP socket for -low-bandwidth/low-roundtrip mobile usage. - -.. TODO - We need to specify capability negotiation for extensible transports - -For the default HTTP transport, all API calls use a Content-Type of -``application/json``. In addition, all strings MUST be encoded as UTF-8. - -Clients are authenticated using opaque ``access_token`` strings (see -`Registration and Login`_ for details), passed as a query string parameter on -all requests. - -.. TODO - Need to specify any HMAC or access_token lifetime/ratcheting tricks - -Any errors which occur on the Matrix API level MUST return a "standard error -response". This is a JSON object which looks like:: - - { - "errcode": "", - "error": "" - } - -The ``error`` string will be a human-readable error message, usually a sentence -explaining what went wrong. The ``errcode`` string will be a unique string -which can be used to handle an error message e.g. ``M_FORBIDDEN``. These error -codes should have their namespace first in ALL CAPS, followed by a single _. -For example, if there was a custom namespace ``com.mydomain.here``, and a -``FORBIDDEN`` code, the error code should look like -``COM.MYDOMAIN.HERE_FORBIDDEN``. There may be additional keys depending on the -error, but the keys ``error`` and ``errcode`` MUST always be present. - -Some standard error codes are below: - -:``M_FORBIDDEN``: - Forbidden access, e.g. joining a room without permission, failed login. - -:``M_UNKNOWN_TOKEN``: - The access token specified was not recognised. - -:``M_BAD_JSON``: - Request contained valid JSON, but it was malformed in some way, e.g. missing - required keys, invalid values for keys. - -:``M_NOT_JSON``: - Request did not contain valid JSON. - -:``M_NOT_FOUND``: - No resource was found for this request. - -:``M_LIMIT_EXCEEDED``: - Too many requests have been sent in a short period of time. Wait a while then - try again. - -Some requests have unique error codes: - -:``M_USER_IN_USE``: - Encountered when trying to register a user ID which has been taken. - -:``M_ROOM_IN_USE``: - Encountered when trying to create a room which has been taken. - -:``M_BAD_PAGINATION``: - Encountered when specifying bad pagination query parameters. - -:``M_LOGIN_EMAIL_URL_NOT_YET``: - Encountered when polling for an email link which has not been clicked yet. - -The C-S API typically uses ``HTTP POST`` to submit requests. This means these -requests are not idempotent. The C-S API also allows ``HTTP PUT`` to make -requests idempotent. In order to use a ``PUT``, paths should be suffixed with -``/{txnId}``. ``{txnId}`` is a unique client-generated transaction ID which -identifies the request, and is scoped to a given Client (identified by that -client's ``access_token``). Crucially, it **only** serves to identify new -requests from retransmits. After the request has finished, the ``{txnId}`` -value should be changed (how is not specified; a monotonically increasing -integer is recommended). It is preferable to use ``HTTP PUT`` to make sure -requests to send messages do not get sent more than once should clients need to -retransmit requests. - -Valid requests look like:: - - POST /some/path/here?access_token=secret - { - "key": "This is a post." - } - - PUT /some/path/here/11?access_token=secret - { - "key": "This is a put with a txnId of 11." - } - -In contrast, these are invalid requests:: - - POST /some/path/here/11?access_token=secret - { - "key": "This is a post, but it has a txnId." - } - - PUT /some/path/here?access_token=secret - { - "key": "This is a put but it is missing a txnId." - } - -Glossary --------- -.. NOTE:: - This section is a work in progress. - -Backfilling: - The process of synchronising historic state from one home server to another, - to backfill the event storage so that scrollback can be presented to the - client(s). Not to be confused with pagination. - -Context: - A single human-level entity of interest (currently, a chat room) - -EDU (Ephemeral Data Unit): - A message that relates directly to a given pair of home servers that are - exchanging it. EDUs are short-lived messages that related only to one single - pair of servers; they are not persisted for a long time and are not forwarded - on to other servers. Because of this, they have no internal ID nor previous - EDUs reference chain. - -Event: - A record of activity that records a single thing that happened on to a context - (currently, a chat room). These are the "chat messages" that Synapse makes - available. - -PDU (Persistent Data Unit): - A message that relates to a single context, irrespective of the server that - is communicating it. PDUs either encode a single Event, or a single State - change. A PDU is referred to by its PDU ID; the pair of its origin server - and local reference from that server. - -PDU ID: - The pair of PDU Origin and PDU Reference, that together globally uniquely - refers to a specific PDU. - -PDU Origin: - The name of the origin server that generated a given PDU. This may not be the - server from which it has been received, due to the way they are copied around - from server to server. The origin always records the original server that - created it. - -PDU Reference: - A local ID used to refer to a specific PDU from a given origin server. These - references are opaque at the protocol level, but may optionally have some - structured meaning within a given origin server or implementation. - -Presence: - The concept of whether a user is currently online, how available they declare - they are, and so on. See also: doc/model/presence - -Profile: - A set of metadata about a user, such as a display name, provided for the - benefit of other users. See also: doc/model/profiles - -Room ID: - An opaque string (of as-yet undecided format) that identifies a particular - room and used in PDUs referring to it. - -Room Alias: - A human-readable string of the form #name:some.domain that users can use as a - pointer to identify a room; a Directory Server will map this to its Room ID - -State: - A set of metadata maintained about a Context, which is replicated among the - servers in addition to the history of Events. - -User ID: - A string of the form @localpart:domain.name that identifies a user for - wire-protocol purposes. The localpart is meaningless outside of a particular - home server. This takes a human-readable form that end-users can use directly - if they so wish, avoiding the 3PIDs. - -Transaction: - A message which relates to the communication between a given pair of servers. - A transaction contains possibly-empty lists of PDUs and EDUs. - -.. TODO - This glossary contradicts the terms used above - especially on State Events v. "State" - and Non-State Events v. "Events". We need better consistent names. - -Events -====== - -Receiving live updates on a client ----------------------------------- - -Clients can receive new events by long-polling the home server. This will hold -open the HTTP connection for a short period of time waiting for new events, -returning early if an event occurs. This is called the `Event Stream`_. All -events which are visible to the client will appear in the event stream. When -the request returns, an ``end`` token is included in the response. This token -can be used in the next request to continue where the client left off. - -.. TODO-spec - How do we filter the event stream? - Do we ever return multiple events in a single request? Don't we get lots of request - setup RTT latency if we only do one event per request? Do we ever support streaming - requests? Why not websockets? - -When the client first logs in, they will need to initially synchronise with -their home server. This is achieved via the |initialSync|_ API. This API also -returns an ``end`` token which can be used with the event stream. - -Room Events ------------ -.. NOTE:: - This section is a work in progress. - -This specification outlines several standard event types, all of which are -prefixed with ``m.`` - -``m.room.name`` - Summary: - Set the human-readable name for the room. - Type: - State event - JSON format: - ``{ "name" : "string" }`` - Example: - ``{ "name" : "My Room" }`` - Description: - A room has an opaque room ID which is not human-friendly to read. A room - alias is human-friendly, but not all rooms have room aliases. The room name - is a human-friendly string designed to be displayed to the end-user. The - room name is not *unique*, as multiple rooms can have the same room name - set. The room name can also be set when creating a room using |createRoom|_ - with the ``name`` key. - -``m.room.topic`` - Summary: - Set a topic for the room. - Type: - State event - JSON format: - ``{ "topic" : "string" }`` - Example: - ``{ "topic" : "Welcome to the real world." }`` - Description: - A topic is a short message detailing what is currently being discussed in - the room. It can also be used as a way to display extra information about - the room, which may not be suitable for the room name. The room topic can - also be set when creating a room using |createRoom|_ with the ``topic`` - key. - -``m.room.member`` - Summary: - The current membership state of a user in the room. - Type: - State event - JSON format: - ``{ "membership" : "enum[ invite|join|leave|ban ]" }`` - Example: - ``{ "membership" : "join" }`` - Description: - Adjusts the membership state for a user in a room. It is preferable to use - the membership APIs (``/rooms//invite`` etc) when performing - membership actions rather than adjusting the state directly as there are a - restricted set of valid transformations. For example, user A cannot force - user B to join a room, and trying to force this state change directly will - fail. See the `Rooms`_ section for how to use the membership APIs. - -``m.room.create`` - Summary: - The first event in the room. - Type: - State event - JSON format: - ``{ "creator": "string"}`` - Example: - ``{ "creator": "@user:example.com" }`` - Description: - This is the first event in a room and cannot be changed. It acts as the - root of all other events. - -``m.room.join_rules`` - Summary: - Descripes how/if people are allowed to join. - Type: - State event - JSON format: - ``{ "join_rule": "enum [ public|knock|invite|private ]" }`` - Example: - ``{ "join_rule": "public" }`` - Description: - TODO-doc : Use docs/models/rooms.rst - -``m.room.power_levels`` - Summary: - Defines the power levels of users in the room. - Type: - State event - JSON format: - ``{ "": , ..., "default": }`` - Example: - ``{ "@user:example.com": 5, "@user2:example.com": 10, "default": 0 }`` - Description: - If a user is in the list, then they have the associated power level. - Otherwise they have the default level. If not ``default`` key is supplied, - it is assumed to be 0. - -``m.room.add_state_level`` - Summary: - Defines the minimum power level a user needs to add state. - Type: - State event - JSON format: - ``{ "level": }`` - Example: - ``{ "level": 5 }`` - Description: - To add a new piece of state to the room a user must have the given power - level. This does not apply to updating current state, which is goverened - by the ``required_power_level`` event key. - -``m.room.send_event_level`` - Summary: - Defines the minimum power level a user needs to send an event. - Type: - State event - JSON format: - ``{ "level": }`` - Example: - ``{ "level": 0 }`` - Description: - To send a new event into the room a user must have at least this power - level. This allows ops to make the room read only by increasing this level, - or muting individual users by lowering their power level below this - threshold. - -``m.room.ops_levels`` - Summary: - Defines the minimum power levels that a user must have before they can - kick and/or ban other users. - Type: - State event - JSON format: - ``{ "ban_level": , "kick_level": , "redact_level": }`` - Example: - ``{ "ban_level": 5, "kick_level": 5 }`` - Description: - This defines who can ban and/or kick people in the room. Most of the time - ``ban_level`` will be greater than or equal to ``kick_level`` since - banning is more severe than kicking. - -``m.room.aliases`` - Summary: - These state events are used to inform the room about what room aliases it - has. - Type: - State event - JSON format: - ``{ "aliases": ["string", ...] }`` - Example: - ``{ "aliases": ["#foo:example.com"] }`` - Description: - This event is sent by a homeserver directly to inform of changes to the - list of aliases it knows about for that room. As a special-case, the - ``state_key`` of the event is the homeserver which owns the room alias. - For example, an event might look like:: - - { - "type": "m.room.aliases", - "event_id": "012345678ab", - "room_id": "!xAbCdEfG:example.com", - "state_key": "example.com", - "content": { - "aliases": ["#foo:example.com"] - } - } - - The event contains the full list of aliases now stored by the home server - that emitted it; additions or deletions are not explicitly mentioned as - being such. The entire set of known aliases for the room is then the union - of the individual lists declared by all such keys, one from each home - server holding at least one alias. - - Clients `should` check the validity of any room alias given in this list - before presenting it to the user as trusted fact. The lists given by this - event should be considered simply as advice on which aliases might exist, - for which the client can perform the lookup to confirm whether it receives - the correct room ID. - -``m.room.message`` - Summary: - A message. - Type: - Non-state event - JSON format: - ``{ "msgtype": "string" }`` - Example: - ``{ "msgtype": "m.text", "body": "Testing" }`` - Description: - This event is used when sending messages in a room. Messages are not - limited to be text. The ``msgtype`` key outlines the type of message, e.g. - text, audio, image, video, etc. Whilst not required, the ``body`` key - SHOULD be used with every kind of ``msgtype`` as a fallback mechanism when - a client cannot render the message. For more information on the types of - messages which can be sent, see `m.room.message msgtypes`_. - -``m.room.message.feedback`` - Summary: - A receipt for a message. - Type: - Non-state event - JSON format: - ``{ "type": "enum [ delivered|read ]", "target_event_id": "string" }`` - Example: - ``{ "type": "delivered", "target_event_id": "e3b2icys" }`` - Description: - Feedback events are events sent to acknowledge a message in some way. There - are two supported acknowledgements: ``delivered`` (sent when the event has - been received) and ``read`` (sent when the event has been observed by the - end-user). The ``target_event_id`` should reference the ``m.room.message`` - event being acknowledged. - -``m.room.redaction`` - Summary: - Indicates a previous event has been redacted. - Type: - Non-state event - JSON format: - ``{ "reason": "string" }`` - Description: - Events can be redacted by either room or server admins. Redacting an event - means that all keys not required by the protocol are stripped off, allowing - admins to remove offensive or illegal content that may have been attached - to any event. This cannot be undone, allowing server owners to physically - delete the offending data. There is also a concept of a moderator hiding a - non-state event, which can be undone, but cannot be applied to state - events. - The event that has been redacted is specified in the ``redacts`` event - level key. - -m.room.message msgtypes -~~~~~~~~~~~~~~~~~~~~~~~ - -.. TODO-spec - How a client should handle unknown message types. - -Each ``m.room.message`` MUST have a ``msgtype`` key which identifies the type -of message being sent. Each type has their own required and optional keys, as -outlined below: - -``m.text`` - Required keys: - - ``body`` : "string" - The body of the message. - Optional keys: - None. - Example: - ``{ "msgtype": "m.text", "body": "I am a fish" }`` - -``m.emote`` - Required keys: - - ``body`` : "string" - The emote action to perform. - Optional keys: - None. - Example: - ``{ "msgtype": "m.emote", "body": "tries to come up with a witty explanation" }`` - -``m.image`` - Required keys: - - ``url`` : "string" - The URL to the image. - Optional keys: - - ``info`` : "string" - info : JSON object (ImageInfo) - The image info for - image referred to in ``url``. - - ``thumbnail_url`` : "string" - The URL to the thumbnail. - - ``thumbnail_info`` : JSON object (ImageInfo) - The image info for the - image referred to in ``thumbnail_url``. - - ``body`` : "string" - The alt text of the image, or some kind of content - description for accessibility e.g. "image attachment". - - ImageInfo: - Information about an image:: - - { - "size" : integer (size of image in bytes), - "w" : integer (width of image in pixels), - "h" : integer (height of image in pixels), - "mimetype" : "string (e.g. image/jpeg)", - } - -``m.audio`` - Required keys: - - ``url`` : "string" - The URL to the audio. - Optional keys: - - ``info`` : JSON object (AudioInfo) - The audio info for the audio - referred to in ``url``. - - ``body`` : "string" - A description of the audio e.g. "Bee Gees - Stayin' - Alive", or some kind of content description for accessibility e.g. - "audio attachment". - AudioInfo: - Information about a piece of audio:: - - { - "mimetype" : "string (e.g. audio/aac)", - "size" : integer (size of audio in bytes), - "duration" : integer (duration of audio in milliseconds), - } - -``m.video`` - Required keys: - - ``url`` : "string" - The URL to the video. - Optional keys: - - ``info`` : JSON object (VideoInfo) - The video info for the video - referred to in ``url``. - - ``body`` : "string" - A description of the video e.g. "Gangnam style", or - some kind of content description for accessibility e.g. "video - attachment". - - VideoInfo: - Information about a video:: - - { - "mimetype" : "string (e.g. video/mp4)", - "size" : integer (size of video in bytes), - "duration" : integer (duration of video in milliseconds), - "w" : integer (width of video in pixels), - "h" : integer (height of video in pixels), - "thumbnail_url" : "string (URL to image)", - "thumbanil_info" : JSON object (ImageInfo) - } - -``m.location`` - Required keys: - - ``geo_uri`` : "string" - The geo URI representing the location. - Optional keys: - - ``thumbnail_url`` : "string" - The URL to a thumnail of the location - being represented. - - ``thumbnail_info`` : JSON object (ImageInfo) - The image info for the - image referred to in ``thumbnail_url``. - - ``body`` : "string" - A description of the location e.g. "Big Ben, - London, UK", or some kind of content description for accessibility e.g. - "location attachment". - -The following keys can be attached to any ``m.room.message``: - - Optional keys: - - ``sender_ts`` : integer - A timestamp (ms resolution) representing the - wall-clock time when the message was sent from the client. - -Events on Change of Profile Information -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Because the profile displayname and avatar information are likely to be used in -many places of a client's display, changes to these fields cause an automatic -propagation event to occur, informing likely-interested parties of the new -values. This change is conveyed using two separate mechanisms: - - - a ``m.room.member`` event is sent to every room the user is a member of, - to update the ``displayname`` and ``avatar_url``. - - a presence status update is sent, again containing the new values of the - ``displayname`` and ``avatar_url`` keys, in addition to the required - ``presence`` key containing the current presence state of the user. - -Both of these should be done automatically by the home server when a user -successfully changes their displayname or avatar URL fields. - -Additionally, when home servers emit room membership events for their own -users, they should include the displayname and avatar URL fields in these -events so that clients already have these details to hand, and do not have to -perform extra roundtrips to query it. - -Voice over IP -------------- -Matrix can also be used to set up VoIP calls. This is part of the core -specification, although is still in a very early stage. Voice (and video) over -Matrix is based on the WebRTC standards. - -Call events are sent to a room, like any other event. This means that clients -must only send call events to rooms with exactly two participants as currently -the WebRTC standard is based around two-party communication. - -Events -~~~~~~ -``m.call.invite`` -This event is sent by the caller when they wish to establish a call. - - Required keys: - - ``call_id`` : "string" - A unique identifier for the call - - ``offer`` : "offer object" - The session description - - ``version`` : "integer" - The version of the VoIP specification this - message adheres to. This specification is version 0. - - ``lifetime`` : "integer" - The time in milliseconds that the invite is - valid for. Once the invite age exceeds this value, clients should discard - it. They should also no longer show the call as awaiting an answer in the - UI. - - Optional keys: - None. - Example: - ``{ "version" : 0, "call_id": "12345", "offer": { "type" : "offer", "sdp" : "v=0\r\no=- 6584580628695956864 2 IN IP4 127.0.0.1[...]" } }`` - -``Offer Object`` - Required keys: - - ``type`` : "string" - The type of session description, in this case - 'offer' - - ``sdp`` : "string" - The SDP text of the session description - -``m.call.candidates`` -This event is sent by callers after sending an invite and by the callee after -answering. Its purpose is to give the other party additional ICE candidates to -try using to communicate. - - Required keys: - - ``call_id`` : "string" - The ID of the call this event relates to - - ``version`` : "integer" - The version of the VoIP specification this - messages adheres to. his specification is version 0. - - ``candidates`` : "array of candidate objects" - Array of object - describing the candidates. - -``Candidate Object`` - - Required Keys: - - ``sdpMid`` : "string" - The SDP media type this candidate is intended - for. - - ``sdpMLineIndex`` : "integer" - The index of the SDP 'm' line this - candidate is intended for - - ``candidate`` : "string" - The SDP 'a' line of the candidate - -``m.call.answer`` - - Required keys: - - ``call_id`` : "string" - The ID of the call this event relates to - - ``version`` : "integer" - The version of the VoIP specification this - messages - - ``answer`` : "answer object" - Object giving the SDK answer - -``Answer Object`` - - Required keys: - - ``type`` : "string" - The type of session description. 'answer' in this - case. - - ``sdp`` : "string" - The SDP text of the session description - -``m.call.hangup`` -Sent by either party to signal their termination of the call. This can be sent -either once the call has has been established or before to abort the call. - - Required keys: - - ``call_id`` : "string" - The ID of the call this event relates to - - ``version`` : "integer" - The version of the VoIP specification this - messages - -Message Exchange -~~~~~~~~~~~~~~~~ -A call is set up with messages exchanged as follows: - -:: - - Caller Callee - m.call.invite -----------> - m.call.candidate --------> - [more candidates events] - User answers call - <------ m.call.answer - [...] - <------ m.call.hangup - -Or a rejected call: - -:: - - Caller Callee - m.call.invite -----------> - m.call.candidate --------> - [more candidates events] - User rejects call - <------- m.call.hangup - -Calls are negotiated according to the WebRTC specification. - - -Glare -~~~~~ -This specification aims to address the problem of two users calling each other -at roughly the same time and their invites crossing on the wire. It is a far -better experience for the users if their calls are connected if it is clear -that their intention is to set up a call with one another. - -In Matrix, calls are to rooms rather than users (even if those rooms may only -contain one other user) so we consider calls which are to the same room. - -The rules for dealing with such a situation are as follows: - - - If an invite to a room is received whilst the client is preparing to send an - invite to the same room, the client should cancel its outgoing call and - instead automatically accept the incoming call on behalf of the user. - - If an invite to a room is received after the client has sent an invite to - the same room and is waiting for a response, the client should perform a - lexicographical comparison of the call IDs of the two calls and use the - lesser of the two calls, aborting the greater. If the incoming call is the - lesser, the client should accept this call on behalf of the user. - -The call setup should appear seamless to the user as if they had simply placed -a call and the other party had accepted. Thusly, any media stream that had been -setup for use on a call should be transferred and used for the call that -replaces it. - -Client-Server API -================= - -Registration and Login ----------------------- - -Clients must register with a home server in order to use Matrix. After -registering, the client will be given an access token which must be used in ALL -requests to that home server as a query parameter 'access_token'. - -If the client has already registered, they need to be able to login to their -account. The home server may provide many different ways of logging in, such as -user/password auth, login via a social network (OAuth2), login by confirming a -token sent to their email address, etc. This specification does not define how -home servers should authorise their users who want to login to their existing -accounts, but instead defines the standard interface which implementations -should follow so that ANY client can login to ANY home server. Clients login -using the |login|_ API. Clients register using the |register|_ API. -Registration follows the same general procedure as login, but the path requests -are sent to and the details contained in them are different. - -In both registration and login cases, the process takes the form of one or more -stages, where at each stage the client submits a set of data for a given stage -type and awaits a response from the server, which will either be a final -success or a request to perform an additional stage. This exchange continues -until the final success. - -In order to determine up-front what the server's requirements are, the client -can request from the server a complete description of all of its acceptable -flows of the registration or login process. It can then inspect the list of -returned flows looking for one for which it believes it can complete all of the -required stages, and perform it. As each home server may have different ways of -logging in, the client needs to know how they should login. All distinct login -stages MUST have a corresponding ``type``. A ``type`` is a namespaced string -which details the mechanism for logging in. - -A client may be able to login via multiple valid login flows, and should choose -a single flow when logging in. A flow is a series of login stages. The home -server MUST respond with all the valid login flows when requested by a simple -``GET`` request directly to the ``/login`` or ``/register`` paths:: - - { - "flows": [ - { - "type": "", - "stages": [ "", "" ] - }, - { - "type": "", - "stages": [ "", "" ] - }, - { - "type": "" - } - ] - } - -The client can now select which flow it wishes to use, and begin making -``POST`` requests to the ``/login`` or ``/register`` paths with JSON body -content containing the name of the stage as the ``type`` key, along with -whatever additional parameters are required for that login or registration type -(see below). After the flow is completed, the client's fully-qualified user -ID and a new access token MUST be returned:: - - { - "user_id": "@user:matrix.org", - "access_token": "abcdef0123456789" - } - -The ``user_id`` key is particularly useful if the home server wishes to support -localpart entry of usernames (e.g. "user" rather than "@user:matrix.org"), as -the client may not be able to determine its ``user_id`` in this case. - -If the flow has multiple stages to it, the home server may wish to create a -session to store context between requests. If a home server responds with a -``session`` key to a request, clients MUST submit it in subsequent requests -until the flow is completed:: - - { - "session": "" - } - -This specification defines the following login types: - - ``m.login.password`` - - ``m.login.oauth2`` - - ``m.login.email.code`` - - ``m.login.email.url`` - - ``m.login.email.identity`` - -Password-based -~~~~~~~~~~~~~~ -:Type: - ``m.login.password`` -:Description: - Login is supported via a username and password. - -To respond to this type, reply with:: - - { - "type": "m.login.password", - "user": "", - "password": "" - } - -The home server MUST respond with either new credentials, the next stage of the -login process, or a standard error response. - -OAuth2-based -~~~~~~~~~~~~ -:Type: - ``m.login.oauth2`` -:Description: - Login is supported via OAuth2 URLs. This login consists of multiple requests. - -To respond to this type, reply with:: - - { - "type": "m.login.oauth2", - "user": "" - } - -The server MUST respond with:: - - { - "uri": - } - -The home server acts as a 'confidential' client for the purposes of OAuth2. If -the uri is a ``sevice selection URI``, it MUST point to a webpage which prompts -the user to choose which service to authorize with. On selection of a service, -this MUST link through to an ``Authorization Request URI``. If there is only 1 -service which the home server accepts when logging in, this indirection can be -skipped and the "uri" key can be the ``Authorization Request URI``. - -The client then visits the ``Authorization Request URI``, which then shows the -OAuth2 Allow/Deny prompt. Hitting 'Allow' returns the ``redirect URI`` with the -auth code. Home servers can choose any path for the ``redirect URI``. The -client should visit the ``redirect URI``, which will then finish the OAuth2 -login process, granting the home server an access token for the chosen service. -When the home server gets this access token, it verifies that the cilent has -authorised with the 3rd party, and can now complete the login. The OAuth2 -``redirect URI`` (with auth code) MUST respond with either new credentials, the -next stage of the login process, or a standard error response. - -For example, if a home server accepts OAuth2 from Google, it would return the -Authorization Request URI for Google:: - - { - "uri": "https://accounts.google.com/o/oauth2/auth?response_type=code& - client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=photos" - } - -The client then visits this URI and authorizes the home server. The client then -visits the REDIRECT_URI with the auth code= query parameter which returns:: - - { - "user_id": "@user:matrix.org", - "access_token": "0123456789abcdef" - } - -Email-based (code) -~~~~~~~~~~~~~~~~~~ -:Type: - ``m.login.email.code`` -:Description: - Login is supported by typing in a code which is sent in an email. This login - consists of multiple requests. - -To respond to this type, reply with:: - - { - "type": "m.login.email.code", - "user": "", - "email": "" - } - -After validating the email address, the home server MUST send an email -containing an authentication code and return:: - - { - "type": "m.login.email.code", - "session": "" - } - -The second request in this login stage involves sending this authentication -code:: - - { - "type": "m.login.email.code", - "session": "", - "code": "" - } - -The home server MUST respond to this with either new credentials, the next -stage of the login process, or a standard error response. - -Email-based (url) -~~~~~~~~~~~~~~~~~ -:Type: - ``m.login.email.url`` -:Description: - Login is supported by clicking on a URL in an email. This login consists of - multiple requests. - -To respond to this type, reply with:: - - { - "type": "m.login.email.url", - "user": "", - "email": "" - } - -After validating the email address, the home server MUST send an email -containing an authentication URL and return:: - - { - "type": "m.login.email.url", - "session": "" - } - -The email contains a URL which must be clicked. After it has been clicked, the -client should perform another request:: - - { - "type": "m.login.email.url", - "session": "" - } - -The home server MUST respond to this with either new credentials, the next -stage of the login process, or a standard error response. - -A common client implementation will be to periodically poll until the link is -clicked. If the link has not been visited yet, a standard error response with -an errcode of ``M_LOGIN_EMAIL_URL_NOT_YET`` should be returned. - - -Email-based (identity server) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -:Type: - ``m.login.email.identity`` -:Description: - Login is supported by authorising an email address with an identity server. - -Prior to submitting this, the client should authenticate with an identity -server. After authenticating, the session information should be submitted to -the home server. - -To respond to this type, reply with:: - - { - "type": "m.login.email.identity", - "threepidCreds": [ - { - "sid": "", - "clientSecret": "", - "idServer": "" - } - ] - } - - - -N-Factor Authentication -~~~~~~~~~~~~~~~~~~~~~~~ -Multiple login stages can be combined to create N-factor authentication during -login. - -This can be achieved by responding with the ``next`` login type on completion -of a previous login stage:: - - { - "next": "" - } - -If a home server implements N-factor authentication, it MUST respond with all -``stages`` when initially queried for their login requirements:: - - { - "type": "<1st login type>", - "stages": [ <1st login type>, <2nd login type>, ... , ] - } - -This can be represented conceptually as:: - - _______________________ - | Login Stage 1 | - | type: "" | - | ___________________ | - | |_Request_1_________| | <-- Returns "session" key which is used throughout. - | ___________________ | - | |_Request_2_________| | <-- Returns a "next" value of "login type2" - |_______________________| - | - | - _________V_____________ - | Login Stage 2 | - | type: "" | - | ___________________ | - | |_Request_1_________| | - | ___________________ | - | |_Request_2_________| | - | ___________________ | - | |_Request_3_________| | <-- Returns a "next" value of "login type3" - |_______________________| - | - | - _________V_____________ - | Login Stage 3 | - | type: "" | - | ___________________ | - | |_Request_1_________| | <-- Returns user credentials - |_______________________| - -Fallback -~~~~~~~~ -Clients cannot be expected to be able to know how to process every single login -type. If a client determines it does not know how to handle a given login type, -it should request a login fallback page:: - - GET matrix/client/api/v1/login/fallback - -This MUST return an HTML page which can perform the entire login process. - - -Rooms ------ - -Creation -~~~~~~~~ -To create a room, a client has to use the |createRoom|_ API. There are various -options which can be set when creating a room: - -``visibility`` - Type: - String - Optional: - Yes - Value: - Either ``public`` or ``private``. - Description: - A ``public`` visibility indicates that the room will be shown in the public - room list. A ``private`` visibility will hide the room from the public room - list. Rooms default to ``private`` visibility if this key is not included. - -``room_alias_name`` - Type: - String - Optional: - Yes - Value: - The room alias localpart. - Description: - If this is included, a room alias will be created and mapped to the newly - created room. The alias will belong on the same home server which created - the room, e.g. ``!qadnasoi:domain.com >>> #room_alias_name:domain.com`` - -``name`` - Type: - String - Optional: - Yes - Value: - The ``name`` value for the ``m.room.name`` state event. - Description: - If this is included, an ``m.room.name`` event will be sent into the room to - indicate the name of the room. See `Room Events`_ for more information on - ``m.room.name``. - -``topic`` - Type: - String - Optional: - Yes - Value: - The ``topic`` value for the ``m.room.topic`` state event. - Description: - If this is included, an ``m.room.topic`` event will be sent into the room - to indicate the topic for the room. See `Room Events`_ for more information - on ``m.room.topic``. - -``invite`` - Type: - List - Optional: - Yes - Value: - A list of user ids to invite. - Description: - This will tell the server to invite everyone in the list to the newly - created room. - -Example:: - - { - "visibility": "public", - "room_alias_name": "thepub", - "name": "The Grand Duke Pub", - "topic": "All about happy hour" - } - -The home server will create a ``m.room.create`` event when the room is created, -which serves as the root of the PDU graph for this room. This event also has a -``creator`` key which contains the user ID of the room creator. It will also -generate several other events in order to manage permissions in this room. This -includes: - - - ``m.room.power_levels`` : Sets the power levels of users. - - ``m.room.join_rules`` : Whether the room is "invite-only" or not. - - ``m.room.add_state_level``: The power level required in order to add new - state to the room (as opposed to updating exisiting state) - - ``m.room.send_event_level`` : The power level required in order to send a - message in this room. - - ``m.room.ops_level`` : The power level required in order to kick or ban a - user from the room or redact an event in the room. - -See `Room Events`_ for more information on these events. - -Room aliases -~~~~~~~~~~~~ -.. NOTE:: - This section is a work in progress. - -Room aliases can be created by sending a ``PUT /directory/room/``:: - - { - "room_id": - } - -They can be deleted by sending a ``DELETE /directory/room/`` with -no content. Only some privileged users may be able to delete room aliases, e.g. -server admins, the creator of the room alias, etc. This specification does not -outline the privilege level required for deleting room aliases. - -As room aliases are scoped to a particular home server domain name, it is -likely that a home server will reject attempts to maintain aliases on other -domain names. This specification does not provide a way for home servers to -send update requests to other servers. - -Rooms store a *partial* list of room aliases via the ``m.room.aliases`` state -event. This alias list is partial because it cannot guarantee that the alias -list is in any way accurate or up-to-date, as room aliases can point to -different room IDs over time. Crucially, the aliases in this event are -**purely informational** and SHOULD NOT be treated as accurate. They SHOULD -be checked before they are used or shared with another user. If a room -appears to have a room alias of ``#alias:example.com``, this SHOULD be checked -to make sure that the room's ID matches the ``room_id`` returned from the -request. - -Room aliases can be checked in the same way they are resolved; by sending a -``GET /directory/room/``:: - - { - "room_id": , - "servers": [ , , ] - } - -Home servers can respond to resolve requests for aliases on other domains than -their own by using the federation API to ask other domain name home servers. - - -Permissions -~~~~~~~~~~~ -.. NOTE:: - This section is a work in progress. - -Permissions for rooms are done via the concept of power levels - to do any -action in a room a user must have a suitable power level. Power levels are -stored as state events in a given room. - -Power levels for users are defined in ``m.room.power_levels``, where both a -default and specific users' power levels can be set:: - - { - "": , - "": , - "default": 0 - } - -By default all users have a power level of 0, other than the room creator whose -power level defaults to 100. Users can grant other users increased power levels -up to their own power level. For example, user A with a power level of 50 could -increase the power level of user B to a maximum of level 50. Power levels for -users are tracked per-room even if the user is not present in the room. - -State events may contain a ``required_power_level`` key, which indicates the -minimum power a user must have before they can update that state key. The only -exception to this is when a user leaves a room, which revokes the user's right -to update state events in that room. - -To perform certain actions there are additional power level requirements -defined in the following state events: - -- ``m.room.send_event_level`` defines the minimum ``level`` for sending - non-state events. Defaults to 50. -- ``m.room.add_state_level`` defines the minimum ``level`` for adding new - state, rather than updating existing state. Defaults to 50. -- ``m.room.ops_level`` defines the minimum ``ban_level`` and ``kick_level`` to - ban and kick other users respectively. This defaults to a kick and ban levels - of 50 each. - - -Joining rooms -~~~~~~~~~~~~~ -.. TODO-doc What does the home server have to do to join a user to a room? - - See SPEC-30. - -Users need to join a room in order to send and receive events in that room. A -user can join a room by making a request to |/join/|_ with:: - - {} - -Alternatively, a user can make a request to |/rooms//join|_ with the -same request content. This is only provided for symmetry with the other -membership APIs: ``/rooms//invite`` and ``/rooms//leave``. If -a room alias was specified, it will be automatically resolved to a room ID, -which will then be joined. The room ID that was joined will be returned in -response:: - - { - "room_id": "!roomid:domain" - } - -The membership state for the joining user can also be modified directly to be -``join`` by sending the following request to -``/rooms//state/m.room.member/``:: - - { - "membership": "join" - } - -See the `Room events`_ section for more information on ``m.room.member``. - -After the user has joined a room, they will receive subsequent events in that -room. This room will now appear as an entry in the |initialSync|_ API. - -Some rooms enforce that a user is *invited* to a room before they can join that -room. Other rooms will allow anyone to join the room even if they have not -received an invite. - -Inviting users -~~~~~~~~~~~~~~ -.. TODO-doc Invite-join dance - - Outline invite join dance. What is it? Why is it required? How does it work? - - What does the home server have to do? - -The purpose of inviting users to a room is to notify them that the room exists -so they can choose to become a member of that room. Some rooms require that all -users who join a room are previously invited to it (an "invite-only" room). -Whether a given room is an "invite-only" room is determined by the room config -key ``m.room.join_rules``. It can have one of the following values: - -``public`` - This room is free for anyone to join without an invite. - -``invite`` - This room can only be joined if you were invited. - -Only users who have a membership state of ``join`` in a room can invite new -users to said room. The person being invited must not be in the ``join`` state -in the room. The fully-qualified user ID must be specified when inviting a -user, as the user may reside on a different home server. To invite a user, send -the following request to |/rooms//invite|_, which will manage the -entire invitation process:: - - { - "user_id": "" - } - -Alternatively, the membership state for this user in this room can be modified -directly by sending the following request to -``/rooms//state/m.room.member/``:: - - { - "membership": "invite" - } - -See the `Room events`_ section for more information on ``m.room.member``. - -Leaving rooms -~~~~~~~~~~~~~ -.. TODO-spec - HS deleting rooms they are no longer a part of. Not implemented. - - This is actually Very Tricky. If all clients a HS is serving leave a room, - the HS will no longer get any new events for that room, because the servers - who get the events are determined on the *membership list*. There should - probably be a way for a HS to lurk on a room even if there are 0 of their - members in the room. - - Grace period before deletion? - - Under what conditions should a room NOT be purged? - - -A user can leave a room to stop receiving events for that room. A user must -have joined the room before they are eligible to leave the room. If the room is -an "invite-only" room, they will need to be re-invited before they can re-join -the room. To leave a room, a request should be made to -|/rooms//leave|_ with:: - - {} - -Alternatively, the membership state for this user in this room can be modified -directly by sending the following request to -``/rooms//state/m.room.member/``:: - - { - "membership": "leave" - } - -See the `Room events`_ section for more information on ``m.room.member``. - -Once a user has left a room, that room will no longer appear on the -|initialSync|_ API. - -If all members in a room leave, that room becomes eligible for deletion. - -Banning users in a room -~~~~~~~~~~~~~~~~~~~~~~~ -A user may decide to ban another user in a room. 'Banning' forces the target -user to leave the room and prevents them from re-joining the room. A banned -user will not be treated as a joined user, and so will not be able to send or -receive events in the room. In order to ban someone, the user performing the -ban MUST have the required power level. To ban a user, a request should be made -to |/rooms//ban|_ with:: - - { - "user_id": "" - } - -Banning a user adjusts the banned member's membership state to ``ban`` and -adjusts the power level of this event to a level higher than the banned person. -Like with other membership changes, a user can directly adjust the target -member's state, by making a request to -``/rooms//state/m.room.member/``:: - - { - "membership": "ban" - } - -Events in a room -~~~~~~~~~~~~~~~~ -Room events can be split into two categories: - -:State Events: - These are events which replace events that came before it, depending on a set - of unique keys. These keys are the event ``type`` and a ``state_key``. - Events with the same set of keys will be overwritten. Typically, state events - are used to store state, hence their name. - -:Non-state events: - These are events which cannot be overwritten after sending. The list of - events continues to grow as more events are sent. As this list grows, it - becomes necessary to provide a mechanism for navigating this list. Pagination - APIs are used to view the list of historical non-state events. Typically, - non-state events are used to send messages. - -This specification outlines several events, all with the event type prefix -``m.``. However, applications may wish to add their own type of event, and this -can be achieved using the REST API detailed in the following sections. If new -events are added, the event ``type`` key SHOULD follow the Java package naming -convention, e.g. ``com.example.myapp.event``. This ensures event types are -suitably namespaced for each application and reduces the risk of clashes. - -State events -~~~~~~~~~~~~ -State events can be sent by ``PUT`` ing to -|/rooms//state//|_. These events will be -overwritten if ````, ```` and ```` all match. -If the state event has no ``state_key``, it can be omitted from the path. These -requests **cannot use transaction IDs** like other ``PUT`` paths because they -cannot be differentiated from the ``state_key``. Furthermore, ``POST`` is -unsupported on state paths. Valid requests look like:: - - PUT /rooms/!roomid:domain/state/m.example.event - { "key" : "without a state key" } - - PUT /rooms/!roomid:domain/state/m.another.example.event/foo - { "key" : "with 'foo' as the state key" } - -In contrast, these requests are invalid:: - - POST /rooms/!roomid:domain/state/m.example.event/ - { "key" : "cannot use POST here" } - - PUT /rooms/!roomid:domain/state/m.another.example.event/foo/11 - { "key" : "txnIds are not supported" } - -Care should be taken to avoid setting the wrong ``state key``:: - - PUT /rooms/!roomid:domain/state/m.another.example.event/11 - { "key" : "with '11' as the state key, but was probably intended to be a txnId" } - -The ``state_key`` is often used to store state about individual users, by using -the user ID as the ``state_key`` value. For example:: - - PUT /rooms/!roomid:domain/state/m.favorite.animal.event/%40my_user%3Adomain.com - { "animal" : "cat", "reason": "fluffy" } - -In some cases, there may be no need for a ``state_key``, so it can be omitted:: - - PUT /rooms/!roomid:domain/state/m.room.bgd.color - { "color": "red", "hex": "#ff0000" } - -See `Room Events`_ for the ``m.`` event specification. - -Non-state events -~~~~~~~~~~~~~~~~ -Non-state events can be sent by sending a request to -|/rooms//send/|_. These requests *can* use transaction -IDs and ``PUT``/``POST`` methods. Non-state events allow access to historical -events and pagination, making it best suited for sending messages. For -example:: - - POST /rooms/!roomid:domain/send/m.custom.example.message - { "text": "Hello world!" } - - PUT /rooms/!roomid:domain/send/m.custom.example.message/11 - { "text": "Goodbye world!" } - -See `Room Events`_ for the ``m.`` event specification. - -Syncing rooms -~~~~~~~~~~~~~ -.. NOTE:: - This section is a work in progress. - -When a client logs in, they may have a list of rooms which they have already -joined. These rooms may also have a list of events associated with them. The -purpose of 'syncing' is to present the current room and event information in a -convenient, compact manner. The events returned are not limited to room events; -presence events will also be returned. A single syncing API is provided: - - - |initialSync|_ : A global sync which will present room and event information - for all rooms the user has joined. - -.. TODO-spec room-scoped initial sync - - |/rooms//initialSync|_ : A sync scoped to a single room. Presents - room and event information for this room only. - - Room-scoped initial sync is Very Tricky because typically people would - want to sync the room then listen for any new content from that point - onwards. The event stream cannot do this for a single room currently. - As a result, commenting room-scoped initial sync at this time. - -The |initialSync|_ API contains the following keys: - -``presence`` - Description: - Contains a list of presence information for users the client is interested - in. - Format: - A JSON array of ``m.presence`` events. - -``end`` - Description: - Contains an event stream token which can be used with the `Event Stream`_. - Format: - A string containing the event stream token. - -``rooms`` - Description: - Contains a list of room information for all rooms the client has joined, - and limited room information on rooms the client has been invited to. - Format: - A JSON array containing Room Information JSON objects. - -Room Information: - Description: - Contains all state events for the room, along with a limited amount of - the most recent non-state events, configured via the ``limit`` query - parameter. Also contains additional keys with room metadata, such as the - ``room_id`` and the client's ``membership`` to the room. - Format: - A JSON object with the following keys: - ``room_id`` - A string containing the ID of the room being described. - ``membership`` - A string representing the client's membership status in this room. - ``messages`` - An event stream JSON object containing a ``chunk`` of recent non-state - events, along with an ``end`` token. *NB: The name of this key will be - changed in a later version.* - ``state`` - A JSON array containing all the current state events for this room. - -Getting events for a room -~~~~~~~~~~~~~~~~~~~~~~~~~ -There are several APIs provided to ``GET`` events for a room: - -``/rooms//state//`` - Description: - Get the state event identified. - Response format: - A JSON object representing the state event **content**. - Example: - ``/rooms/!room:domain.com/state/m.room.name`` returns ``{ "name": "Room name" }`` - -|/rooms//state|_ - Description: - Get all state events for a room. - Response format: - ``[ { state event }, { state event }, ... ]`` - Example: - TODO-doc - - -|/rooms//members|_ - Description: - Get all ``m.room.member`` state events. - Response format: - ``{ "start": "", "end": "", "chunk": [ { m.room.member event }, ... ] }`` - Example: - TODO-doc - -|/rooms//messages|_ - Description: - Get all ``m.room.message`` and ``m.room.member`` events. This API supports - pagination using ``from`` and ``to`` query parameters, coupled with the - ``start`` and ``end`` tokens from an |initialSync|_ API. - Response format: - ``{ "start": "", "end": "" }`` - Example: - TODO-doc - -|/rooms//initialSync|_ - Description: - Get all relevant events for a room. This includes state events, paginated - non-state events and presence events. - Response format: - `` { TODO-doc } `` - Example: - TODO-doc - -Redactions -~~~~~~~~~~ -Since events are extensible it is possible for malicious users and/or servers -to add keys that are, for example offensive or illegal. Since some events -cannot be simply deleted, e.g. membership events, we instead 'redact' events. -This involves removing all keys from an event that are not required by the -protocol. This stripped down event is thereafter returned anytime a client or -remote server requests it. - -Events that have been redacted include a ``redacted_because`` key whose value -is the event that caused it to be redacted, which may include a reason. - -Redacting an event cannot be undone, allowing server owners to delete the -offending content from the databases. - -Currently, only room admins can redact events by sending a ``m.room.redaction`` -event, but server admins also need to be able to redact events by a similar -mechanism. - -Upon receipt of a redaction event, the server should strip off any keys not in -the following list: - - - ``event_id`` - - ``type`` - - ``room_id`` - - ``user_id`` - - ``state_key`` - - ``prev_state`` - - ``content`` - -The content object should also be stripped of all keys, unless it is one of -one of the following event types: - - - ``m.room.member`` allows key ``membership`` - - ``m.room.create`` allows key ``creator`` - - ``m.room.join_rules`` allows key ``join_rule`` - - ``m.room.power_levels`` allows keys that are user ids or ``default`` - - ``m.room.add_state_level`` allows key ``level`` - - ``m.room.send_event_level`` allows key ``level`` - - ``m.room.ops_levels`` allows keys ``kick_level``, ``ban_level`` - and ``redact_level`` - - ``m.room.aliases`` allows key ``aliases`` - -The redaction event should be added under the key ``redacted_because``. - - -When a client receives a redaction event it should change the redacted event -in the same way a server does. - -Presence -~~~~~~~~ -The client API for presence is on the following set of REST calls. - -Fetching basic status:: - - GET $PREFIX/presence/:user_id/status - - Returned content: JSON object containing the following keys: - presence: "offline"|"unavailable"|"online"|"free_for_chat" - status_msg: (optional) string of freeform text - last_active_ago: miliseconds since the last activity by the user - -Setting basic status:: - - PUT $PREFIX/presence/:user_id/status - - Content: JSON object containing the following keys: - presence and status_msg: as above - -When setting the status, the activity time is updated to reflect that activity; -the client does not need to specify the ``last_active_ago`` field. - -Fetching the presence list:: - - GET $PREFIX/presence/list - - Returned content: JSON array containing objects; each object containing the - following keys: - user_id: observed user ID - presence: "offline"|"unavailable"|"online"|"free_for_chat" - status_msg: (optional) string of freeform text - last_active_ago: miliseconds since the last activity by the user - -Maintaining the presence list:: - - POST $PREFIX/presence/list - - Content: JSON object containing either or both of the following keys: - invite: JSON array of strings giving user IDs to send invites to - drop: JSON array of strings giving user IDs to remove from the list - -.. TODO-spec - - Define how users receive presence invites, and how they accept/decline them - -Profiles -~~~~~~~~ -The client API for profile management consists of the following REST calls. - -Fetching a user account displayname:: - - GET $PREFIX/profile/:user_id/displayname - - Returned content: JSON object containing the following keys: - displayname: string of freeform text - -This call may be used to fetch the user's own displayname or to query the name -of other users; either locally or on remote systems hosted on other home -servers. - -Setting a new displayname:: - - PUT $PREFIX/profile/:user_id/displayname - - Content: JSON object containing the following keys: - displayname: string of freeform text - -Fetching a user account avatar URL:: - - GET $PREFIX/profile/:user_id/avatar_url - - Returned content: JSON object containing the following keys: - avatar_url: string containing an http-scheme URL - -As with displayname, this call may be used to fetch either the user's own, or -other users' avatar URL. - -Setting a new avatar URL:: - - PUT $PREFIX/profile/:user_id/avatar_url - - Content: JSON object containing the following keys: - avatar_url: string containing an http-scheme URL - -Fetching combined account profile information:: - - GET $PREFIX/profile/:user_id - - Returned content: JSON object containing the following keys: - displayname: string of freeform text - avatar_url: string containing an http-scheme URL - -At the current time, this API simply returns the displayname and avatar URL -information, though it is intended to return more fields about the user's -profile once they are defined. Client implementations should take care not to -expect that these are the only two keys returned as future versions of this -specification may yield more keys here. - -Security --------- - -Rate limiting -~~~~~~~~~~~~~ -Home servers SHOULD implement rate limiting to reduce the risk of being -overloaded. If a request is refused due to rate limiting, it should return a -standard error response of the form:: - - { - "errcode": "M_LIMIT_EXCEEDED", - "error": "string", - "retry_after_ms": integer (optional) - } - -The ``retry_after_ms`` key SHOULD be included to tell the client how long they -have to wait in milliseconds before they can try again. - -.. TODO-spec - - Surely we should recommend an algorithm for the rate limiting, rather than letting every - homeserver come up with their own idea, causing totally unpredictable performance over - federated rooms? - -End-to-End Encryption -~~~~~~~~~~~~~~~~~~~~~ - -.. TODO-doc - - Why is this needed. - - Overview of process - - Implementation - -Content repository ------------------- -.. NOTE:: - This section is a work in progress. - -.. TODO-spec - - path to upload - - format for thumbnail paths, mention what it is protecting against. - - content size limit and associated M_ERROR. - - -Address book repository ------------------------ -.. NOTE:: - This section is a work in progress. - -.. TODO-spec - - format: POST(?) wodges of json, some possible processing, then return wodges of json on GET. - - processing may remove dupes, merge contacts, pepper with extra info (e.g. matrix-ability of - contacts), etc. - - Standard json format for contacts? Piggy back off vcards? - -Federation API -=============== - -Federation is the term used to describe how to communicate between Matrix home -servers. Federation is a mechanism by which two home servers can exchange -Matrix event messages, both as a real-time push of current events, and as a -historic fetching mechanism to synchronise past history for clients to view. It -uses HTTPS connections between each pair of servers involved as the underlying -transport. Messages are exchanged between servers in real-time by active -pushing from each server's HTTP client into the server of the other. Queries to -fetch historic data for the purpose of back-filling scrollback buffers and the -like can also be performed. Currently routing of messages between homeservers -is full mesh (like email) - however, fan-out refinements to this design are -currently under consideration. - -There are three main kinds of communication that occur between home servers: - -:Queries: - These are single request/response interactions between a given pair of - servers, initiated by one side sending an HTTPS GET request to obtain some - information, and responded by the other. They are not persisted and contain - no long-term significant history. They simply request a snapshot state at - the instant the query is made. - -:Ephemeral Data Units (EDUs): - These are notifications of events that are pushed from one home server to - another. They are not persisted and contain no long-term significant - history, nor does the receiving home server have to reply to them. - -:Persisted Data Units (PDUs): - These are notifications of events that are broadcast from one home server to - any others that are interested in the same "context" (namely, a Room ID). - They are persisted to long-term storage and form the record of history for - that context. - -EDUs and PDUs are further wrapped in an envelope called a Transaction, which is -transferred from the origin to the destination home server using an HTTP PUT -request. - - -Transactions ------------- -.. WARNING:: - This section may be misleading or inaccurate. - -The transfer of EDUs and PDUs between home servers is performed by an exchange -of Transaction messages, which are encoded as JSON objects, passed over an HTTP -PUT request. A Transaction is meaningful only to the pair of home servers that -exchanged it; they are not globally-meaningful. - -Each transaction has: - - An opaque transaction ID. - - A timestamp (UNIX epoch time in milliseconds) generated by its origin - server. - - An origin and destination server name. - - A list of "previous IDs". - - A list of PDUs and EDUs - the actual message payload that the Transaction - carries. - -``origin`` - Type: - String - Description: - DNS name of homeserver making this transaction. - -``ts`` - Type: - Integer - Description: - Timestamp in milliseconds on originating homeserver when this transaction - started. - -``previous_ids`` - Type: - List of strings - Description: - List of transactions that were sent immediately prior to this transaction. - -``pdus`` - Type: - List of Objects. - Description: - List of updates contained in this transaction. - -:: - - { - "transaction_id":"916d630ea616342b42e98a3be0b74113", - "ts":1404835423000, - "origin":"red", - "destination":"blue", - "prev_ids":["e1da392e61898be4d2009b9fecce5325"], - "pdus":[...], - "edus":[...] - } - -The ``prev_ids`` field contains a list of previous transaction IDs that the -``origin`` server has sent to this ``destination``. Its purpose is to act as a -sequence checking mechanism - the destination server can check whether it has -successfully received that Transaction, or ask for a retransmission if not. - -The ``pdus`` field of a transaction is a list, containing zero or more PDUs.[*] -Each PDU is itself a JSON object containing a number of keys, the exact details -of which will vary depending on the type of PDU. Similarly, the ``edus`` field -is another list containing the EDUs. This key may be entirely absent if there -are no EDUs to transfer. - -(* Normally the PDU list will be non-empty, but the server should cope with -receiving an "empty" transaction.) - -PDUs and EDUs -------------- -.. WARNING:: - This section may be misleading or inaccurate. - -All PDUs have: - - An ID - - A context - - A declaration of their type - - A list of other PDU IDs that have been seen recently on that context - (regardless of which origin sent them) - -``context`` - Type: - String - Description: - Event context identifier - -``origin`` - Type: - String - Description: - DNS name of homeserver that created this PDU. - -``pdu_id`` - Type: - String - Description: - Unique identifier for PDU within the context for the originating homeserver - -``ts`` - Type: - Integer - Description: - Timestamp in milliseconds on originating homeserver when this PDU was - created. - -``pdu_type`` - Type: - String - Description: - PDU event type. - -``prev_pdus`` - Type: - List of pairs of strings - Description: - The originating homeserver and PDU ids of the most recent PDUs the - homeserver was aware of for this context when it made this PDU. - -``depth`` - Type: - Integer - Description: - The maximum depth of the previous PDUs plus one. - - -.. TODO-spec paul - - Update this structure so that 'pdu_id' is a two-element [origin,ref] pair - like the prev_pdus are - -For state updates: - -``is_state`` - Type: - Boolean - Description: - True if this PDU is updating state. - -``state_key`` - Type: - String - Description: - Optional key identifying the updated state within the context. - -``power_level`` - Type: - Integer - Description: - The asserted power level of the user performing the update. - -``required_power_level`` - Type: - Integer - Description: - The required power level needed to replace this update. - -``prev_state_id`` - Type: - String - Description: - PDU event type. - -``prev_state_origin`` - Type: - String - Description: - The PDU id of the update this replaces. - -``user_id`` - Type: - String - Description: - The user updating the state. - -:: - - { - "pdu_id":"a4ecee13e2accdadf56c1025af232176", - "context":"#example.green", - "origin":"green", - "ts":1404838188000, - "pdu_type":"m.text", - "prev_pdus":[["blue","99d16afbc857975916f1d73e49e52b65"]], - "content":... - "is_state":false - } - -In contrast to Transactions, it is important to note that the ``prev_pdus`` -field of a PDU refers to PDUs that any origin server has sent, rather than -previous IDs that this ``origin`` has sent. This list may refer to other PDUs -sent by the same origin as the current one, or other origins. - -Because of the distributed nature of participants in a Matrix conversation, it -is impossible to establish a globally-consistent total ordering on the events. -However, by annotating each outbound PDU at its origin with IDs of other PDUs -it has received, a partial ordering can be constructed allowing causality -relationships to be preserved. A client can then display these messages to the -end-user in some order consistent with their content and ensure that no message -that is semantically in reply of an earlier one is ever displayed before it. - -PDUs fall into two main categories: those that deliver Events, and those that -synchronise State. For PDUs that relate to State synchronisation, additional -keys exist to support this: - -:: - - {..., - "is_state":true, - "state_key":TODO-doc - "power_level":TODO-doc - "prev_state_id":TODO-doc - "prev_state_origin":TODO-doc} - -EDUs, by comparison to PDUs, do not have an ID, a context, or a list of -"previous" IDs. The only mandatory fields for these are the type, origin and -destination home server names, and the actual nested content. - -:: - - {"edu_type":"m.presence", - "origin":"blue", - "destination":"orange", - "content":...} - - -Protocol URLs -------------- -.. WARNING:: - This section may be misleading or inaccurate. - -All these URLs are namespaced within a prefix of:: - - /_matrix/federation/v1/... - -For active pushing of messages representing live activity "as it happens":: - - PUT .../send/:transaction_id/ - Body: JSON encoding of a single Transaction - Response: TODO-doc - -The transaction_id path argument will override any ID given in the JSON body. -The destination name will be set to that of the receiving server itself. Each -embedded PDU in the transaction body will be processed. - - -To fetch a particular PDU:: - - GET .../pdu/:origin/:pdu_id/ - Response: JSON encoding of a single Transaction containing one PDU - -Retrieves a given PDU from the server. The response will contain a single new -Transaction, inside which will be the requested PDU. - - -To fetch all the state of a given context:: - - GET .../state/:context/ - Response: JSON encoding of a single Transaction containing multiple PDUs - -Retrieves a snapshot of the entire current state of the given context. The -response will contain a single Transaction, inside which will be a list of PDUs -that encode the state. - -To backfill events on a given context:: - - GET .../backfill/:context/ - Query args: v, limit - Response: JSON encoding of a single Transaction containing multiple PDUs - -Retrieves a sliding-window history of previous PDUs that occurred on the given -context. Starting from the PDU ID(s) given in the "v" argument, the PDUs that -preceeded it are retrieved, up to a total number given by the "limit" argument. -These are then returned in a new Transaction containing all of the PDUs. - - -To stream events all the events:: - - GET .../pull/ - Query args: origin, v - Response: JSON encoding of a single Transaction consisting of multiple PDUs - -Retrieves all of the transactions later than any version given by the "v" -arguments. - - -To make a query:: - - GET .../query/:query_type - Query args: as specified by the individual query types - Response: JSON encoding of a response object - -Performs a single query request on the receiving home server. The Query Type -part of the path specifies the kind of query being made, and its query -arguments have a meaning specific to that kind of query. The response is a -JSON-encoded object whose meaning also depends on the kind of query. - -Backfilling ------------ -.. NOTE:: - This section is a work in progress. - -.. TODO-doc - - What it is, when is it used, how is it done - -SRV Records ------------ -.. NOTE:: - This section is a work in progress. - -.. TODO-doc - - Why it is needed - -State Conflict Resolution -------------------------- -.. NOTE:: - This section is a work in progress. - -.. TODO-doc - - How do conflicts arise (diagrams?) - - How are they resolved (incl tie breaks) - - How does this work with deleting current state - -Presence --------- -The server API for presence is based entirely on exchange of the following -EDUs. There are no PDUs or Federation Queries involved. - -Performing a presence update and poll subscription request:: - - EDU type: m.presence - - Content keys: - push: (optional): list of push operations. - Each should be an object with the following keys: - user_id: string containing a User ID - presence: "offline"|"unavailable"|"online"|"free_for_chat" - status_msg: (optional) string of freeform text - last_active_ago: miliseconds since the last activity by the user - - poll: (optional): list of strings giving User IDs - - unpoll: (optional): list of strings giving User IDs - -The presence of this combined message is two-fold: it informs the recipient -server of the current status of one or more users on the sending server (by the -``push`` key), and it maintains the list of users on the recipient server that -the sending server is interested in receiving updates for, by adding (by the -``poll`` key) or removing them (by the ``unpoll`` key). The ``poll`` and -``unpoll`` lists apply *changes* to the implied list of users; any existing IDs -that the server sent as ``poll`` operations in a previous message are not -removed until explicitly requested by a later ``unpoll``. - -On receipt of a message containing a non-empty ``poll`` list, the receiving -server should immediately send the sending server a presence update EDU of its -own, containing in a ``push`` list the current state of every user that was in -the orginal EDU's ``poll`` list. - -Sending a presence invite:: - - EDU type: m.presence_invite - - Content keys: - observed_user: string giving the User ID of the user whose presence is - requested (i.e. the recipient of the invite) - observer_user: string giving the User ID of the user who is requesting to - observe the presence (i.e. the sender of the invite) - -Accepting a presence invite:: - - EDU type: m.presence_accept - - Content keys - as for m.presence_invite - -Rejecting a presence invite:: - - EDU type: m.presence_deny - - Content keys - as for m.presence_invite - -.. TODO-doc - - Explain the timing-based roundtrip reduction mechanism for presence - messages - - Explain the zero-byte presence inference logic - See also: docs/client-server/model/presence - -Profiles --------- -The server API for profiles is based entirely on the following Federation -Queries. There are no additional EDU or PDU types involved, other than the -implicit ``m.presence`` and ``m.room.member`` events (see section below). - -Querying profile information:: - - Query type: profile - - Arguments: - user_id: the ID of the user whose profile to return - field: (optional) string giving a field name - - Returns: JSON object containing the following keys: - displayname: string of freeform text - avatar_url: string containing an http-scheme URL - -If the query contains the optional ``field`` key, it should give the name of a -result field. If such is present, then the result should contain only a field -of that name, with no others present. If not, the result should contain as much -of the user's profile as the home server has available and can make public. - -Server-Server Authentication ----------------------------- - -.. TODO-doc - - Why is this needed. - - High level overview of process. - - Transaction/PDU signing - - How does this work with redactions? (eg hashing required keys only) - - - -Threat Model ------------- - -Denial of Service -~~~~~~~~~~~~~~~~~ - -The attacker could attempt to prevent delivery of messages to or from the -victim in order to: - -* Disrupt service or marketing campaign of a commercial competitor. -* Censor a discussion or censor a participant in a discussion. -* Perform general vandalism. - -Threat: Resource Exhaustion -+++++++++++++++++++++++++++ - -An attacker could cause the victims server to exhaust a particular resource -(e.g. open TCP connections, CPU, memory, disk storage) - -Threat: Unrecoverable Consistency Violations -++++++++++++++++++++++++++++++++++++++++++++ - -An attacker could send messages which created an unrecoverable "split-brain" -state in the cluster such that the victim's servers could no longer dervive a -consistent view of the chatroom state. - -Threat: Bad History -+++++++++++++++++++ - -An attacker could convince the victim to accept invalid messages which the -victim would then include in their view of the chatroom history. Other servers -in the chatroom would reject the invalid messages and potentially reject the -victims messages as well since they depended on the invalid messages. - -.. TODO-spec - Track trustworthiness of HS or users based on if they try to pretend they - haven't seen recent events, and fake a splitbrain... --M - -Threat: Block Network Traffic -+++++++++++++++++++++++++++++ - -An attacker could try to firewall traffic between the victim's server and some -or all of the other servers in the chatroom. - -Threat: High Volume of Messages -+++++++++++++++++++++++++++++++ - -An attacker could send large volumes of messages to a chatroom with the victim -making the chatroom unusable. - -Threat: Banning users without necessary authorisation -+++++++++++++++++++++++++++++++++++++++++++++++++++++ - -An attacker could attempt to ban a user from a chatroom with the necessary -authorisation. - -Spoofing -~~~~~~~~ - -An attacker could try to send a message claiming to be from the victim without -the victim having sent the message in order to: - -* Impersonate the victim while performing illict activity. -* Obtain privileges of the victim. - -Threat: Altering Message Contents -+++++++++++++++++++++++++++++++++ - -An attacker could try to alter the contents of an existing message from the -victim. - -Threat: Fake Message "origin" Field -+++++++++++++++++++++++++++++++++++ - -An attacker could try to send a new message purporting to be from the victim -with a phony "origin" field. - -Spamming -~~~~~~~~ - -The attacker could try to send a high volume of solicicted or unsolicted -messages to the victim in order to: - -* Find victims for scams. -* Market unwanted products. - -Threat: Unsoliticted Messages -+++++++++++++++++++++++++++++ - -An attacker could try to send messages to victims who do not wish to receive -them. - -Threat: Abusive Messages -++++++++++++++++++++++++ - -An attacker could send abusive or threatening messages to the victim - -Spying -~~~~~~ - -The attacker could try to access message contents or metadata for messages sent -by the victim or to the victim that were not intended to reach the attacker in -order to: - -* Gain sensitive personal or commercial information. -* Impersonate the victim using credentials contained in the messages. - (e.g. password reset messages) -* Discover who the victim was talking to and when. - -Threat: Disclosure during Transmission -++++++++++++++++++++++++++++++++++++++ - -An attacker could try to expose the message contents or metadata during -transmission between the servers. - -Threat: Disclosure to Servers Outside Chatroom -++++++++++++++++++++++++++++++++++++++++++++++ - -An attacker could try to convince servers within a chatroom to send messages to -a server it controls that was not authorised to be within the chatroom. - -Threat: Disclosure to Servers Within Chatroom -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -An attacker could take control of a server within a chatroom to expose message -contents or metadata for messages in that room. - - -Identity Servers -================ -.. NOTE:: - This section is a work in progress. - -.. TODO-doc Dave - - 3PIDs and identity server, functions - -Lawful Interception -------------------- - -Key Escrow Servers -~~~~~~~~~~~~~~~~~~ - -Policy Servers -============== -.. NOTE:: - This section is a work in progress. - -.. TODO-spec - We should mention them in the Architecture section at least: how they fit - into the picture. - -Enforcing policies ------------------- - - - -.. Links through the external API docs are below -.. ============================================= - -.. |createRoom| replace:: ``/createRoom`` -.. _createRoom: /docs/api/client-server/#!/-rooms/create_room - -.. |initialSync| replace:: ``/initialSync`` -.. _initialSync: /docs/api/client-server/#!/-events/initial_sync - -.. |/rooms//initialSync| replace:: ``/rooms//initialSync`` -.. _/rooms//initialSync: /docs/api/client-server/#!/-rooms/get_room_sync_data - -.. |login| replace:: ``/login`` -.. _login: /docs/api/client-server/#!/-login - -.. |register| replace:: ``/register`` -.. _register: /docs/api/client-server/#!/-registration - -.. |/rooms//messages| replace:: ``/rooms//messages`` -.. _/rooms//messages: /docs/api/client-server/#!/-rooms/get_messages - -.. |/rooms//members| replace:: ``/rooms//members`` -.. _/rooms//members: /docs/api/client-server/#!/-rooms/get_members - -.. |/rooms//state| replace:: ``/rooms//state`` -.. _/rooms//state: /docs/api/client-server/#!/-rooms/get_state_events - -.. |/rooms//send/| replace:: ``/rooms//send/`` -.. _/rooms//send/: /docs/api/client-server/#!/-rooms/send_non_state_event - -.. |/rooms//state//| replace:: ``/rooms//state//`` -.. _/rooms//state//: /docs/api/client-server/#!/-rooms/send_state_event - -.. |/rooms//invite| replace:: ``/rooms//invite`` -.. _/rooms//invite: /docs/api/client-server/#!/-rooms/invite - -.. |/rooms//join| replace:: ``/rooms//join`` -.. _/rooms//join: /docs/api/client-server/#!/-rooms/join_room - -.. |/rooms//leave| replace:: ``/rooms//leave`` -.. _/rooms//leave: /docs/api/client-server/#!/-rooms/leave - -.. |/rooms//ban| replace:: ``/rooms//ban`` -.. _/rooms//ban: /docs/api/client-server/#!/-rooms/ban - -.. |/join/| replace:: ``/join/`` -.. _/join/: /docs/api/client-server/#!/-rooms/join - -.. _`Event Stream`: /docs/api/client-server/#!/-events/get_event_stream - diff --git a/docs/state_resolution.rst b/docs/state_resolution.rst deleted file mode 100644 index fec290dd79..0000000000 --- a/docs/state_resolution.rst +++ /dev/null @@ -1,51 +0,0 @@ -State Resolution -================ -This section describes why we need state resolution and how it works. - - -Motivation ------------ -We want to be able to associate some shared state with rooms, e.g. a room name -or members list. This is done by having a current state dictionary that maps -from the pair event type and state key to an event. - -However, since the servers involved in the room are distributed we need to be -able to handle the case when two (or more) servers try and update the state at -the same time. This is done via the state resolution algorithm. - - -State Tree ------------- -State events contain a reference to the state it is trying to replace. These -relations form a tree where the current state is one of the leaf nodes. - -Note that state events are events, and so are part of the PDU graph. Thus we -can be sure that (modulo the internet being particularly broken) we will see -all state events eventually. - - -Algorithm requirements ----------------------- -We want the algorithm to have the following properties: -- Since we aren't guaranteed what order we receive state events in, except that - we see parents before children, the state resolution algorithm must not depend - on the order and must always come to the same result. -- If we receive a state event whose parent is the current state, then the - algorithm will select it. -- The algorithm does not depend on internal state, ensuring all servers should - come to the same decision. - -These three properties mean it is enough to keep track of the current state and -compare it with any new proposed state, rather than having to keep track of all -the leafs of the tree and recomputing across the entire state tree. - - -Current Implementation ----------------------- -The current implementation works as follows: Upon receipt of a newly proposed -state change we first find the common ancestor. Then we take the maximum -across each branch of the users' power levels, if one is higher then it is -selected as the current state. Otherwise, we check if one chain is longer than -the other, if so we choose that one. If that also fails, then we concatenate -all the pdu ids and take a SHA1 hash and compare them to select a common -ancestor. From 259b5e84519014be5062b37ad2b2c58d6b0e2761 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Thu, 9 Oct 2014 20:43:07 +0200 Subject: [PATCH 079/106] move swagger JSON from synapse project to matrix-doc project --- docs/client-server/swagger_matrix/api-docs | 46 - .../swagger_matrix/api-docs-directory | 101 -- .../swagger_matrix/api-docs-events | 247 ----- .../swagger_matrix/api-docs-login | 120 --- .../swagger_matrix/api-docs-presence | 164 --- .../swagger_matrix/api-docs-profile | 122 --- .../swagger_matrix/api-docs-registration | 120 --- .../swagger_matrix/api-docs-rooms | 977 ------------------ 8 files changed, 1897 deletions(-) delete mode 100644 docs/client-server/swagger_matrix/api-docs delete mode 100644 docs/client-server/swagger_matrix/api-docs-directory delete mode 100644 docs/client-server/swagger_matrix/api-docs-events delete mode 100644 docs/client-server/swagger_matrix/api-docs-login delete mode 100644 docs/client-server/swagger_matrix/api-docs-presence delete mode 100644 docs/client-server/swagger_matrix/api-docs-profile delete mode 100644 docs/client-server/swagger_matrix/api-docs-registration delete mode 100644 docs/client-server/swagger_matrix/api-docs-rooms diff --git a/docs/client-server/swagger_matrix/api-docs b/docs/client-server/swagger_matrix/api-docs deleted file mode 100644 index a80b3bb342..0000000000 --- a/docs/client-server/swagger_matrix/api-docs +++ /dev/null @@ -1,46 +0,0 @@ -{ - "apiVersion": "1.0.0", - "swaggerVersion": "1.2", - "apis": [ - { - "path": "-login", - "description": "Login operations" - }, - { - "path": "-registration", - "description": "Registration operations" - }, - { - "path": "-rooms", - "description": "Room operations" - }, - { - "path": "-profile", - "description": "Profile operations" - }, - { - "path": "-presence", - "description": "Presence operations" - }, - { - "path": "-events", - "description": "Event operations" - }, - { - "path": "-directory", - "description": "Directory operations" - } - ], - "authorizations": { - "token": { - "scopes": [] - } - }, - "info": { - "title": "Matrix Client-Server API Reference", - "description": "This contains the client-server API for the reference implementation of the home server", - "termsOfServiceUrl": "http://matrix.org", - "license": "Apache 2.0", - "licenseUrl": "http://www.apache.org/licenses/LICENSE-2.0.html" - } -} diff --git a/docs/client-server/swagger_matrix/api-docs-directory b/docs/client-server/swagger_matrix/api-docs-directory deleted file mode 100644 index 5dda580658..0000000000 --- a/docs/client-server/swagger_matrix/api-docs-directory +++ /dev/null @@ -1,101 +0,0 @@ -{ - "apiVersion": "1.0.0", - "swaggerVersion": "1.2", - "basePath": "http://localhost:8008/_matrix/client/api/v1", - "resourcePath": "/directory", - "produces": [ - "application/json" - ], - "apis": [ - { - "path": "/directory/room/{roomAlias}", - "operations": [ - { - "method": "GET", - "summary": "Get the room ID corresponding to this room alias.", - "notes": "Volatile: This API is likely to change.", - "type": "DirectoryResponse", - "nickname": "get_room_id_for_alias", - "parameters": [ - { - "name": "roomAlias", - "description": "The room alias.", - "required": true, - "type": "string", - "paramType": "path" - } - ] - }, - { - "method": "PUT", - "summary": "Create a new mapping from room alias to room ID.", - "notes": "Volatile: This API is likely to change.", - "type": "void", - "nickname": "add_room_alias", - "parameters": [ - { - "name": "roomAlias", - "description": "The room alias to set.", - "required": true, - "type": "string", - "paramType": "path" - }, - { - "name": "body", - "description": "The room ID to set.", - "required": true, - "type": "RoomAliasRequest", - "paramType": "body" - } - ] - }, - { - "method": "DELETE", - "summary": "Removes a mapping of room alias to room ID.", - "notes": "Only privileged users can perform this action.", - "type": "void", - "nickname": "remove_room_alias", - "parameters": [ - { - "name": "roomAlias", - "description": "The room alias to remove.", - "required": true, - "type": "string", - "paramType": "path" - } - ] - } - ] - } - ], - "models": { - "DirectoryResponse": { - "id": "DirectoryResponse", - "properties": { - "room_id": { - "type": "string", - "description": "The fully-qualified room ID.", - "required": true - }, - "servers": { - "type": "array", - "items": { - "$ref": "string" - }, - "description": "A list of servers that know about this room.", - "required": true - } - } - }, - "RoomAliasRequest": { - "id": "RoomAliasRequest", - "properties": { - "room_id": { - "type": "string", - "description": "The room ID to map the alias to.", - "required": true - } - } - } - } -} diff --git a/docs/client-server/swagger_matrix/api-docs-events b/docs/client-server/swagger_matrix/api-docs-events deleted file mode 100644 index 1bdb9b034a..0000000000 --- a/docs/client-server/swagger_matrix/api-docs-events +++ /dev/null @@ -1,247 +0,0 @@ -{ - "apiVersion": "1.0.0", - "swaggerVersion": "1.2", - "basePath": "http://localhost:8008/_matrix/client/api/v1", - "resourcePath": "/events", - "produces": [ - "application/json" - ], - "apis": [ - { - "path": "/events", - "operations": [ - { - "method": "GET", - "summary": "Listen on the event stream", - "notes": "This can only be done by the logged in user. This will block until an event is received, or until the timeout is reached.", - "type": "PaginationChunk", - "nickname": "get_event_stream", - "parameters": [ - { - "name": "from", - "description": "The token to stream from.", - "required": false, - "type": "string", - "paramType": "query" - }, - { - "name": "timeout", - "description": "The maximum time in milliseconds to wait for an event.", - "required": false, - "type": "integer", - "paramType": "query" - } - ] - } - ], - - "responseMessages": [ - { - "code": 400, - "message": "Bad pagination token." - } - ] - }, - { - "path": "/events/{eventId}", - "operations": [ - { - "method": "GET", - "summary": "Get information about a single event.", - "notes": "Get information about a single event.", - "type": "Event", - "nickname": "get_event", - "parameters": [ - { - "name": "eventId", - "description": "The event ID to get.", - "required": true, - "type": "string", - "paramType": "path" - } - ], - "responseMessages": [ - { - "code": 404, - "message": "Event not found." - } - ] - } - ] - }, - { - "path": "/initialSync", - "operations": [ - { - "method": "GET", - "summary": "Get this user's current state.", - "notes": "Get this user's current state.", - "type": "InitialSyncResponse", - "nickname": "initial_sync", - "parameters": [ - { - "name": "limit", - "description": "The maximum number of messages to return for each room.", - "type": "integer", - "paramType": "query", - "required": false - } - ] - } - ] - }, - { - "path": "/publicRooms", - "operations": [ - { - "method": "GET", - "summary": "Get a list of publicly visible rooms.", - "type": "PublicRoomsPaginationChunk", - "nickname": "get_public_room_list" - } - ] - } - ], - "models": { - "PaginationChunk": { - "id": "PaginationChunk", - "properties": { - "start": { - "type": "string", - "description": "A token which correlates to the first value in \"chunk\" for paginating.", - "required": true - }, - "end": { - "type": "string", - "description": "A token which correlates to the last value in \"chunk\" for paginating.", - "required": true - }, - "chunk": { - "type": "array", - "description": "An array of events.", - "required": true, - "items": { - "$ref": "Event" - } - } - } - }, - "Event": { - "id": "Event", - "properties": { - "event_id": { - "type": "string", - "description": "An ID which uniquely identifies this event.", - "required": true - }, - "room_id": { - "type": "string", - "description": "The room in which this event occurred.", - "required": true - } - } - }, - "PublicRoomInfo": { - "id": "PublicRoomInfo", - "properties": { - "aliases": { - "type": "array", - "description": "A list of room aliases for this room.", - "items": { - "$ref": "string" - } - }, - "name": { - "type": "string", - "description": "The name of the room, as given by the m.room.name state event." - }, - "room_id": { - "type": "string", - "description": "The room ID for this public room.", - "required": true - }, - "topic": { - "type": "string", - "description": "The topic of this room, as given by the m.room.topic state event." - } - } - }, - "PublicRoomsPaginationChunk": { - "id": "PublicRoomsPaginationChunk", - "properties": { - "start": { - "type": "string", - "description": "A token which correlates to the first value in \"chunk\" for paginating.", - "required": true - }, - "end": { - "type": "string", - "description": "A token which correlates to the last value in \"chunk\" for paginating.", - "required": true - }, - "chunk": { - "type": "array", - "description": "A list of public room data.", - "required": true, - "items": { - "$ref": "PublicRoomInfo" - } - } - } - }, - "InitialSyncResponse": { - "id": "InitialSyncResponse", - "properties": { - "end": { - "type": "string", - "description": "A streaming token which can be used with /events to continue from this snapshot of data.", - "required": true - }, - "presence": { - "type": "array", - "description": "A list of presence events.", - "items": { - "$ref": "Event" - }, - "required": false - }, - "rooms": { - "type": "array", - "description": "A list of initial sync room data.", - "required": false, - "items": { - "$ref": "InitialSyncRoomData" - } - } - } - }, - "InitialSyncRoomData": { - "id": "InitialSyncRoomData", - "properties": { - "membership": { - "type": "string", - "description": "This user's membership state in this room.", - "required": true - }, - "room_id": { - "type": "string", - "description": "The ID of this room.", - "required": true - }, - "messages": { - "type": "PaginationChunk", - "description": "The most recent messages for this room, governed by the limit parameter.", - "required": false - }, - "state": { - "type": "array", - "description": "A list of state events representing the current state of the room.", - "required": false, - "items": { - "$ref": "Event" - } - } - } - } - } -} diff --git a/docs/client-server/swagger_matrix/api-docs-login b/docs/client-server/swagger_matrix/api-docs-login deleted file mode 100644 index d6f8d84f29..0000000000 --- a/docs/client-server/swagger_matrix/api-docs-login +++ /dev/null @@ -1,120 +0,0 @@ -{ - "apiVersion": "1.0.0", - "apis": [ - { - "operations": [ - { - "method": "GET", - "nickname": "get_login_info", - "notes": "All login stages MUST be mentioned if there is >1 login type.", - "summary": "Get the login mechanism to use when logging in.", - "type": "LoginFlows" - }, - { - "method": "POST", - "nickname": "submit_login", - "notes": "If this is part of a multi-stage login, there MUST be a 'session' key.", - "parameters": [ - { - "description": "A login submission", - "name": "body", - "paramType": "body", - "required": true, - "type": "LoginSubmission" - } - ], - "responseMessages": [ - { - "code": 400, - "message": "Bad login type" - }, - { - "code": 400, - "message": "Missing JSON keys" - } - ], - "summary": "Submit a login action.", - "type": "LoginResult" - } - ], - "path": "/login" - } - ], - "basePath": "http://localhost:8008/_matrix/client/api/v1", - "consumes": [ - "application/json" - ], - "models": { - "LoginFlows": { - "id": "LoginFlows", - "properties": { - "flows": { - "description": "A list of valid login flows.", - "type": "array", - "items": { - "$ref": "LoginInfo" - } - } - } - }, - "LoginInfo": { - "id": "LoginInfo", - "properties": { - "stages": { - "description": "Multi-stage login only: An array of all the login types required to login.", - "items": { - "$ref": "string" - }, - "type": "array" - }, - "type": { - "description": "The login type that must be used when logging in.", - "type": "string" - } - } - }, - "LoginResult": { - "id": "LoginResult", - "properties": { - "access_token": { - "description": "The access token for this user's login if this is the final stage of the login process.", - "type": "string" - }, - "user_id": { - "description": "The user's fully-qualified user ID.", - "type": "string" - }, - "next": { - "description": "Multi-stage login only: The next login type to submit.", - "type": "string" - }, - "session": { - "description": "Multi-stage login only: The session token to send when submitting the next login type.", - "type": "string" - } - } - }, - "LoginSubmission": { - "id": "LoginSubmission", - "properties": { - "type": { - "description": "The type of login being submitted.", - "type": "string" - }, - "session": { - "description": "Multi-stage login only: The session token from an earlier login stage.", - "type": "string" - }, - "_login_type_defined_keys_": { - "description": "Keys as defined by the specified login type, e.g. \"user\", \"password\"" - } - } - } - }, - "produces": [ - "application/json" - ], - "resourcePath": "/login", - "swaggerVersion": "1.2" -} - diff --git a/docs/client-server/swagger_matrix/api-docs-presence b/docs/client-server/swagger_matrix/api-docs-presence deleted file mode 100644 index 6b22446024..0000000000 --- a/docs/client-server/swagger_matrix/api-docs-presence +++ /dev/null @@ -1,164 +0,0 @@ -{ - "apiVersion": "1.0.0", - "swaggerVersion": "1.2", - "basePath": "http://localhost:8008/_matrix/client/api/v1", - "resourcePath": "/presence", - "produces": [ - "application/json" - ], - "consumes": [ - "application/json" - ], - "apis": [ - { - "path": "/presence/{userId}/status", - "operations": [ - { - "method": "PUT", - "summary": "Update this user's presence state.", - "notes": "This can only be done by the logged in user.", - "type": "void", - "nickname": "update_presence", - "parameters": [ - { - "name": "body", - "description": "The new presence state", - "required": true, - "type": "PresenceUpdate", - "paramType": "body" - }, - { - "name": "userId", - "description": "The user whose presence to set.", - "required": true, - "type": "string", - "paramType": "path" - } - ] - }, - { - "method": "GET", - "summary": "Get this user's presence state.", - "notes": "Get this user's presence state.", - "type": "PresenceUpdate", - "nickname": "get_presence", - "parameters": [ - { - "name": "userId", - "description": "The user whose presence to get.", - "required": true, - "type": "string", - "paramType": "path" - } - ] - } - ] - }, - { - "path": "/presence/list/{userId}", - "operations": [ - { - "method": "GET", - "summary": "Retrieve a list of presences for all of this user's friends.", - "notes": "", - "type": "array", - "items": { - "$ref": "Presence" - }, - "nickname": "get_presence_list", - "parameters": [ - { - "name": "userId", - "description": "The user whose presence list to get.", - "required": true, - "type": "string", - "paramType": "path" - } - ] - }, - { - "method": "POST", - "summary": "Add or remove users from this presence list.", - "notes": "Add or remove users from this presence list.", - "type": "void", - "nickname": "modify_presence_list", - "parameters": [ - { - "name": "userId", - "description": "The user whose presence list is being modified.", - "required": true, - "type": "string", - "paramType": "path" - }, - { - "name": "body", - "description": "The modifications to make to this presence list.", - "required": true, - "type": "PresenceListModifications", - "paramType": "body" - } - ] - } - ] - } - ], - "models": { - "PresenceUpdate": { - "id": "PresenceUpdate", - "properties": { - "presence": { - "type": "string", - "description": "Enum: The presence state.", - "enum": [ - "offline", - "unavailable", - "online", - "free_for_chat" - ] - }, - "status_msg": { - "type": "string", - "description": "The user-defined message associated with this presence state." - } - }, - "subTypes": [ - "Presence" - ] - }, - "Presence": { - "id": "Presence", - "properties": { - "last_active_ago": { - "type": "integer", - "format": "int64", - "description": "The last time this user performed an action on their home server." - }, - "user_id": { - "type": "string", - "description": "The fully qualified user ID" - } - } - }, - "PresenceListModifications": { - "id": "PresenceListModifications", - "properties": { - "invite": { - "type": "array", - "description": "A list of user IDs to add to the list.", - "items": { - "type": "string", - "description": "A fully qualified user ID." - } - }, - "drop": { - "type": "array", - "description": "A list of user IDs to remove from the list.", - "items": { - "type": "string", - "description": "A fully qualified user ID." - } - } - } - } - } -} diff --git a/docs/client-server/swagger_matrix/api-docs-profile b/docs/client-server/swagger_matrix/api-docs-profile deleted file mode 100644 index d2fccaa67d..0000000000 --- a/docs/client-server/swagger_matrix/api-docs-profile +++ /dev/null @@ -1,122 +0,0 @@ -{ - "apiVersion": "1.0.0", - "swaggerVersion": "1.2", - "basePath": "http://localhost:8008/_matrix/client/api/v1", - "resourcePath": "/profile", - "produces": [ - "application/json" - ], - "consumes": [ - "application/json" - ], - "apis": [ - { - "path": "/profile/{userId}/displayname", - "operations": [ - { - "method": "PUT", - "summary": "Set a display name.", - "notes": "This can only be done by the logged in user.", - "type": "void", - "nickname": "set_display_name", - "parameters": [ - { - "name": "body", - "description": "The new display name for this user.", - "required": true, - "type": "DisplayName", - "paramType": "body" - }, - { - "name": "userId", - "description": "The user whose display name to set.", - "required": true, - "type": "string", - "paramType": "path" - } - ] - }, - { - "method": "GET", - "summary": "Get a display name.", - "notes": "This can be done by anyone.", - "type": "DisplayName", - "nickname": "get_display_name", - "parameters": [ - { - "name": "userId", - "description": "The user whose display name to get.", - "required": true, - "type": "string", - "paramType": "path" - } - ] - } - ] - }, - { - "path": "/profile/{userId}/avatar_url", - "operations": [ - { - "method": "PUT", - "summary": "Set an avatar URL.", - "notes": "This can only be done by the logged in user.", - "type": "void", - "nickname": "set_avatar_url", - "parameters": [ - { - "name": "body", - "description": "The new avatar url for this user.", - "required": true, - "type": "AvatarUrl", - "paramType": "body" - }, - { - "name": "userId", - "description": "The user whose avatar url to set.", - "required": true, - "type": "string", - "paramType": "path" - } - ] - }, - { - "method": "GET", - "summary": "Get an avatar url.", - "notes": "This can be done by anyone.", - "type": "AvatarUrl", - "nickname": "get_avatar_url", - "parameters": [ - { - "name": "userId", - "description": "The user whose avatar url to get.", - "required": true, - "type": "string", - "paramType": "path" - } - ] - } - ] - } - ], - "models": { - "DisplayName": { - "id": "DisplayName", - "properties": { - "displayname": { - "type": "string", - "description": "The textual display name" - } - } - }, - "AvatarUrl": { - "id": "AvatarUrl", - "properties": { - "avatar_url": { - "type": "string", - "description": "A url to an image representing an avatar." - } - } - } - } -} diff --git a/docs/client-server/swagger_matrix/api-docs-registration b/docs/client-server/swagger_matrix/api-docs-registration deleted file mode 100644 index 11c170c3ec..0000000000 --- a/docs/client-server/swagger_matrix/api-docs-registration +++ /dev/null @@ -1,120 +0,0 @@ -{ - "apiVersion": "1.0.0", - "apis": [ - { - "operations": [ - { - "method": "GET", - "nickname": "get_registration_info", - "notes": "All login stages MUST be mentioned if there is >1 login type.", - "summary": "Get the login mechanism to use when registering.", - "type": "RegistrationFlows" - }, - { - "method": "POST", - "nickname": "submit_registration", - "notes": "If this is part of a multi-stage registration, there MUST be a 'session' key.", - "parameters": [ - { - "description": "A registration submission", - "name": "body", - "paramType": "body", - "required": true, - "type": "RegistrationSubmission" - } - ], - "responseMessages": [ - { - "code": 400, - "message": "Bad login type" - }, - { - "code": 400, - "message": "Missing JSON keys" - } - ], - "summary": "Submit a registration action.", - "type": "RegistrationResult" - } - ], - "path": "/register" - } - ], - "basePath": "http://localhost:8008/_matrix/client/api/v1", - "consumes": [ - "application/json" - ], - "models": { - "RegistrationFlows": { - "id": "RegistrationFlows", - "properties": { - "flows": { - "description": "A list of valid registration flows.", - "type": "array", - "items": { - "$ref": "RegistrationInfo" - } - } - } - }, - "RegistrationInfo": { - "id": "RegistrationInfo", - "properties": { - "stages": { - "description": "Multi-stage registration only: An array of all the login types required to registration.", - "items": { - "$ref": "string" - }, - "type": "array" - }, - "type": { - "description": "The first login type that must be used when logging in.", - "type": "string" - } - } - }, - "RegistrationResult": { - "id": "RegistrationResult", - "properties": { - "access_token": { - "description": "The access token for this user's registration if this is the final stage of the registration process.", - "type": "string" - }, - "user_id": { - "description": "The user's fully-qualified user ID.", - "type": "string" - }, - "next": { - "description": "Multi-stage registration only: The next registration type to submit.", - "type": "string" - }, - "session": { - "description": "Multi-stage registration only: The session token to send when submitting the next registration type.", - "type": "string" - } - } - }, - "RegistrationSubmission": { - "id": "RegistrationSubmission", - "properties": { - "type": { - "description": "The type of registration being submitted.", - "type": "string" - }, - "session": { - "description": "Multi-stage registration only: The session token from an earlier registration stage.", - "type": "string" - }, - "_registration_type_defined_keys_": { - "description": "Keys as defined by the specified registration type, e.g. \"user\", \"password\"" - } - } - } - }, - "produces": [ - "application/json" - ], - "resourcePath": "/register", - "swaggerVersion": "1.2" -} - diff --git a/docs/client-server/swagger_matrix/api-docs-rooms b/docs/client-server/swagger_matrix/api-docs-rooms deleted file mode 100644 index b941e58139..0000000000 --- a/docs/client-server/swagger_matrix/api-docs-rooms +++ /dev/null @@ -1,977 +0,0 @@ -{ - "apiVersion": "1.0.0", - "swaggerVersion": "1.2", - "basePath": "http://localhost:8008/_matrix/client/api/v1", - "resourcePath": "/rooms", - "produces": [ - "application/json" - ], - "consumes": [ - "application/json" - ], - "authorizations": { - "token": [] - }, - "apis": [ - { - "path": "/rooms/{roomId}/send/{eventType}", - "operations": [ - { - "method": "POST", - "summary": "Send a generic non-state event to this room.", - "notes": "This operation can also be done as a PUT by suffixing /{txnId}.", - "type": "EventId", - "nickname": "send_non_state_event", - "consumes": [ - "application/json" - ], - "parameters": [ - { - "name": "body", - "description": "The event contents", - "required": true, - "type": "EventContent", - "paramType": "body" - }, - { - "name": "roomId", - "description": "The room to send the message in.", - "required": true, - "type": "string", - "paramType": "path" - }, - { - "name": "eventType", - "description": "The type of event to send.", - "required": true, - "type": "string", - "paramType": "path" - } - ] - } - ] - }, - { - "path": "/rooms/{roomId}/state/{eventType}/{stateKey}", - "operations": [ - { - "method": "PUT", - "summary": "Send a generic state event to this room.", - "notes": "The state key can be omitted, such that you can PUT to /rooms/{roomId}/state/{eventType}. The state key defaults to a 0 length string in this case.", - "type": "void", - "nickname": "send_state_event", - "consumes": [ - "application/json" - ], - "parameters": [ - { - "name": "body", - "description": "The event contents", - "required": true, - "type": "EventContent", - "paramType": "body" - }, - { - "name": "roomId", - "description": "The room to send the message in.", - "required": true, - "type": "string", - "paramType": "path" - }, - { - "name": "eventType", - "description": "The type of event to send.", - "required": true, - "type": "string", - "paramType": "path" - }, - { - "name": "stateKey", - "description": "An identifier used to specify clobbering semantics. State events with the same (roomId, eventType, stateKey) will be replaced.", - "required": true, - "type": "string", - "paramType": "path" - } - ] - } - ] - }, - { - "path": "/rooms/{roomId}/send/m.room.message", - "operations": [ - { - "method": "POST", - "summary": "Send a message in this room.", - "notes": "This operation can also be done as a PUT by suffixing /{txnId}.", - "type": "EventId", - "nickname": "send_message", - "consumes": [ - "application/json" - ], - "parameters": [ - { - "name": "body", - "description": "The message contents", - "required": true, - "type": "Message", - "paramType": "body" - }, - { - "name": "roomId", - "description": "The room to send the message in.", - "required": true, - "type": "string", - "paramType": "path" - } - ] - } - ] - }, - { - "path": "/rooms/{roomId}/state/m.room.topic", - "operations": [ - { - "method": "PUT", - "summary": "Set the topic for this room.", - "notes": "Set the topic for this room.", - "type": "void", - "nickname": "set_topic", - "consumes": [ - "application/json" - ], - "parameters": [ - { - "name": "body", - "description": "The topic contents", - "required": true, - "type": "Topic", - "paramType": "body" - }, - { - "name": "roomId", - "description": "The room to set the topic in.", - "required": true, - "type": "string", - "paramType": "path" - } - ] - }, - { - "method": "GET", - "summary": "Get the topic for this room.", - "notes": "Get the topic for this room.", - "type": "Topic", - "nickname": "get_topic", - "parameters": [ - { - "name": "roomId", - "description": "The room to get topic in.", - "required": true, - "type": "string", - "paramType": "path" - } - ], - "responseMessages": [ - { - "code": 404, - "message": "Topic not found." - } - ] - } - ] - }, - { - "path": "/rooms/{roomId}/state/m.room.name", - "operations": [ - { - "method": "PUT", - "summary": "Set the name of this room.", - "notes": "Set the name of this room.", - "type": "void", - "nickname": "set_room_name", - "consumes": [ - "application/json" - ], - "parameters": [ - { - "name": "body", - "description": "The name contents", - "required": true, - "type": "RoomName", - "paramType": "body" - }, - { - "name": "roomId", - "description": "The room to set the name of.", - "required": true, - "type": "string", - "paramType": "path" - } - ] - }, - { - "method": "GET", - "summary": "Get the room's name.", - "notes": "", - "type": "RoomName", - "nickname": "get_room_name", - "parameters": [ - { - "name": "roomId", - "description": "The room to get the name of.", - "required": true, - "type": "string", - "paramType": "path" - } - ], - "responseMessages": [ - { - "code": 404, - "message": "Name not found." - } - ] - } - ] - }, - { - "path": "/rooms/{roomId}/send/m.room.message.feedback", - "operations": [ - { - "method": "POST", - "summary": "Send feedback to a message.", - "notes": "This operation can also be done as a PUT by suffixing /{txnId}.", - "type": "EventId", - "nickname": "send_feedback", - "consumes": [ - "application/json" - ], - "parameters": [ - { - "name": "body", - "description": "The feedback contents", - "required": true, - "type": "Feedback", - "paramType": "body" - }, - { - "name": "roomId", - "description": "The room to send the feedback in.", - "required": true, - "type": "string", - "paramType": "path" - } - ], - "responseMessages": [ - { - "code": 400, - "message": "Bad feedback type." - } - ] - } - ] - }, - { - "path": "/rooms/{roomId}/invite", - "operations": [ - { - "method": "POST", - "summary": "Invite a user to this room.", - "notes": "This operation can also be done as a PUT by suffixing /{txnId}.", - "type": "void", - "nickname": "invite", - "consumes": [ - "application/json" - ], - "parameters": [ - { - "name": "roomId", - "description": "The room which has this user.", - "required": true, - "type": "string", - "paramType": "path" - }, - { - "name": "body", - "description": "The user to invite.", - "required": true, - "type": "InviteRequest", - "paramType": "body" - } - ] - } - ] - }, - { - "path": "/rooms/{roomId}/join", - "operations": [ - { - "method": "POST", - "summary": "Join this room.", - "notes": "This operation can also be done as a PUT by suffixing /{txnId}.", - "type": "void", - "nickname": "join_room", - "consumes": [ - "application/json" - ], - "parameters": [ - { - "name": "roomId", - "description": "The room to join.", - "required": true, - "type": "string", - "paramType": "path" - }, - { - "name": "body", - "required": true, - "type": "JoinRequest", - "paramType": "body" - } - ] - } - ] - }, - { - "path": "/rooms/{roomId}/leave", - "operations": [ - { - "method": "POST", - "summary": "Leave this room.", - "notes": "This operation can also be done as a PUT by suffixing /{txnId}.", - "type": "void", - "nickname": "leave", - "consumes": [ - "application/json" - ], - "parameters": [ - { - "name": "roomId", - "description": "The room to leave.", - "required": true, - "type": "string", - "paramType": "path" - }, - { - "name": "body", - "required": true, - "type": "LeaveRequest", - "paramType": "body" - } - ] - } - ] - }, - { - "path": "/rooms/{roomId}/ban", - "operations": [ - { - "method": "POST", - "summary": "Ban a user in the room.", - "notes": "This operation can also be done as a PUT by suffixing /{txnId}. The caller must have the required power level to do this operation.", - "type": "void", - "nickname": "ban", - "consumes": [ - "application/json" - ], - "parameters": [ - { - "name": "roomId", - "description": "The room which has the user to ban.", - "required": true, - "type": "string", - "paramType": "path" - }, - { - "name": "body", - "description": "The user to ban.", - "required": true, - "type": "BanRequest", - "paramType": "body" - } - ] - } - ] - }, - { - "path": "/rooms/{roomId}/state/m.room.member/{userId}", - "operations": [ - { - "method": "PUT", - "summary": "Change the membership state for a user in a room.", - "notes": "Change the membership state for a user in a room.", - "type": "void", - "nickname": "set_membership", - "consumes": [ - "application/json" - ], - "parameters": [ - { - "name": "body", - "description": "The new membership state", - "required": true, - "type": "Member", - "paramType": "body" - }, - { - "name": "userId", - "description": "The user whose membership is being changed.", - "required": true, - "type": "string", - "paramType": "path" - }, - { - "name": "roomId", - "description": "The room which has this user.", - "required": true, - "type": "string", - "paramType": "path" - } - ], - "responseMessages": [ - { - "code": 400, - "message": "No membership key." - }, - { - "code": 400, - "message": "Bad membership value." - }, - { - "code": 403, - "message": "When inviting: You are not in the room." - }, - { - "code": 403, - "message": "When inviting: is already in the room." - }, - { - "code": 403, - "message": "When joining: Cannot force another user to join." - }, - { - "code": 403, - "message": "When joining: You are not invited to this room." - } - ] - }, - { - "method": "GET", - "summary": "Get the membership state of a user in a room.", - "notes": "Get the membership state of a user in a room.", - "type": "Member", - "nickname": "get_membership", - "parameters": [ - { - "name": "userId", - "description": "The user whose membership state you want to get.", - "required": true, - "type": "string", - "paramType": "path" - }, - { - "name": "roomId", - "description": "The room which has this user.", - "required": true, - "type": "string", - "paramType": "path" - } - ], - "responseMessages": [ - { - "code": 404, - "message": "Member not found." - } - ] - } - ] - }, - { - "path": "/join/{roomAliasOrId}", - "operations": [ - { - "method": "POST", - "summary": "Join a room via a room alias or room ID.", - "notes": "Join a room via a room alias or room ID.", - "type": "JoinRoomInfo", - "nickname": "join", - "consumes": [ - "application/json" - ], - "parameters": [ - { - "name": "roomAliasOrId", - "description": "The room alias or room ID to join.", - "required": true, - "type": "string", - "paramType": "path" - } - ], - "responseMessages": [ - { - "code": 400, - "message": "Bad room alias." - } - ] - } - ] - }, - { - "path": "/createRoom", - "operations": [ - { - "method": "POST", - "summary": "Create a room.", - "notes": "Create a room.", - "type": "RoomInfo", - "nickname": "create_room", - "consumes": [ - "application/json" - ], - "parameters": [ - { - "name": "body", - "description": "The desired configuration for the room. This operation can also be done as a PUT by suffixing /{txnId}.", - "required": true, - "type": "RoomConfig", - "paramType": "body" - } - ], - "responseMessages": [ - { - "code": 400, - "message": "Body must be JSON." - }, - { - "code": 400, - "message": "Room alias already taken." - } - ] - } - ] - }, - { - "path": "/rooms/{roomId}/messages", - "operations": [ - { - "method": "GET", - "summary": "Get a list of messages for this room.", - "notes": "Get a list of messages for this room.", - "type": "MessagePaginationChunk", - "nickname": "get_messages", - "parameters": [ - { - "name": "roomId", - "description": "The room to get messages in.", - "required": true, - "type": "string", - "paramType": "path" - }, - { - "name": "from", - "description": "The token to start getting results from.", - "required": false, - "type": "string", - "paramType": "query" - }, - { - "name": "to", - "description": "The token to stop getting results at.", - "required": false, - "type": "string", - "paramType": "query" - }, - { - "name": "limit", - "description": "The maximum number of messages to return.", - "required": false, - "type": "integer", - "paramType": "query" - } - ] - } - ] - }, - { - "path": "/rooms/{roomId}/members", - "operations": [ - { - "method": "GET", - "summary": "Get a list of members for this room.", - "notes": "Get a list of members for this room.", - "type": "MemberPaginationChunk", - "nickname": "get_members", - "parameters": [ - { - "name": "roomId", - "description": "The room to get a list of members from.", - "required": true, - "type": "string", - "paramType": "path" - }, - { - "name": "from", - "description": "The token to start getting results from.", - "required": false, - "type": "string", - "paramType": "query" - }, - { - "name": "to", - "description": "The token to stop getting results at.", - "required": false, - "type": "string", - "paramType": "query" - }, - { - "name": "limit", - "description": "The maximum number of members to return.", - "required": false, - "type": "integer", - "paramType": "query" - } - ] - } - ] - }, - { - "path": "/rooms/{roomId}/state", - "operations": [ - { - "method": "GET", - "summary": "Get a list of all the current state events for this room.", - "notes": "This is equivalent to the events returned under the 'state' key for this room in /initialSync.", - "type": "array", - "items": { - "$ref": "Event" - }, - "nickname": "get_state_events", - "parameters": [ - { - "name": "roomId", - "description": "The room to get a list of current state events from.", - "required": true, - "type": "string", - "paramType": "path" - } - ] - } - ] - }, - { - "path": "/rooms/{roomId}/initialSync", - "operations": [ - { - "method": "GET", - "summary": "Get all the current information for this room, including messages and state events.", - "notes": "NOT YET IMPLEMENTED.", - "type": "InitialSyncRoomData", - "nickname": "get_room_sync_data", - "parameters": [ - { - "name": "roomId", - "description": "The room to get information for.", - "required": true, - "type": "string", - "paramType": "path" - } - ] - } - ] - } - ], - "models": { - "Topic": { - "id": "Topic", - "properties": { - "topic": { - "type": "string", - "description": "The topic text" - } - } - }, - "RoomName": { - "id": "RoomName", - "properties": { - "name": { - "type": "string", - "description": "The human-readable name for the room. Can contain spaces." - } - } - }, - "Message": { - "id": "Message", - "properties": { - "msgtype": { - "type": "string", - "description": "The type of message being sent, e.g. \"m.text\"", - "required": true - }, - "_msgtype_defined_keys_": { - "description": "Additional keys as defined by the msgtype, e.g. \"body\"" - } - } - }, - "Feedback": { - "id": "Feedback", - "properties": { - "target_event_id": { - "type": "string", - "description": "The event ID being acknowledged.", - "required": true - }, - "type": { - "type": "string", - "description": "The type of feedback. Either 'delivered' or 'read'.", - "required": true - } - } - }, - "Member": { - "id": "Member", - "properties": { - "membership": { - "type": "string", - "description": "Enum: The membership state of this member.", - "enum": [ - "invite", - "join", - "leave", - "ban" - ] - } - } - }, - "RoomInfo": { - "id": "RoomInfo", - "properties": { - "room_id": { - "type": "string", - "description": "The allocated room ID.", - "required": true - }, - "room_alias": { - "type": "string", - "description": "The alias for the room.", - "required": false - } - } - }, - "JoinRoomInfo": { - "id": "JoinRoomInfo", - "properties": { - "room_id": { - "type": "string", - "description": "The room ID joined, if joined via a room alias only.", - "required": true - } - } - }, - "RoomConfig": { - "id": "RoomConfig", - "properties": { - "visibility": { - "type": "string", - "description": "Enum: The room visibility.", - "required": false, - "enum": [ - "public", - "private" - ] - }, - "room_alias_name": { - "type": "string", - "description": "The alias to give the new room.", - "required": false - }, - "name": { - "type": "string", - "description": "Sets the name of the room. Send a m.room.name event after creating the room with the 'name' key specified.", - "required": false - }, - "topic": { - "type": "string", - "description": "Sets the topic for the room. Send a m.room.topic event after creating the room with the 'topic' key specified.", - "required": false - } - } - }, - "PaginationRequest": { - "id": "PaginationRequest", - "properties": { - "from": { - "type": "string", - "description": "The token to start getting results from." - }, - "to": { - "type": "string", - "description": "The token to stop getting results at." - }, - "limit": { - "type": "integer", - "description": "The maximum number of entries to return." - } - } - }, - "PaginationChunk": { - "id": "PaginationChunk", - "properties": { - "start": { - "type": "string", - "description": "A token which correlates to the first value in \"chunk\" for paginating.", - "required": true - }, - "end": { - "type": "string", - "description": "A token which correlates to the last value in \"chunk\" for paginating.", - "required": true - } - }, - "subTypes": [ - "MessagePaginationChunk" - ] - }, - "MessagePaginationChunk": { - "id": "MessagePaginationChunk", - "properties": { - "chunk": { - "type": "array", - "description": "A list of message events.", - "items": { - "$ref": "MessageEvent" - }, - "required": true - } - } - }, - "MemberPaginationChunk": { - "id": "MemberPaginationChunk", - "properties": { - "chunk": { - "type": "array", - "description": "A list of member events.", - "items": { - "$ref": "MemberEvent" - }, - "required": true - } - } - }, - "Event": { - "id": "Event", - "properties": { - "event_id": { - "type": "string", - "description": "An ID which uniquely identifies this event. This is automatically set by the server.", - "required": true - }, - "room_id": { - "type": "string", - "description": "The room in which this event occurred. This is automatically set by the server.", - "required": true - }, - "type": { - "type": "string", - "description": "The event type.", - "required": true - } - }, - "subTypes": [ - "MessageEvent" - ] - }, - "EventId": { - "id": "EventId", - "properties": { - "event_id": { - "type": "string", - "description": "The allocated event ID for this event.", - "required": true - } - } - }, - "EventContent": { - "id": "EventContent", - "properties": { - "__event_content_keys__": { - "type": "string", - "description": "Event-specific content keys and values.", - "required": false - } - } - }, - "MessageEvent": { - "id": "MessageEvent", - "properties": { - "content": { - "type": "Message" - } - } - }, - "MemberEvent": { - "id": "MemberEvent", - "properties": { - "content": { - "type": "Member" - } - } - }, - "InviteRequest": { - "id": "InviteRequest", - "properties": { - "user_id": { - "type": "string", - "description": "The fully-qualified user ID." - } - } - }, - "JoinRequest": { - "id": "JoinRequest", - "properties": {} - }, - "LeaveRequest": { - "id": "LeaveRequest", - "properties": {} - }, - "BanRequest": { - "id": "BanRequest", - "properties": { - "user_id": { - "type": "string", - "description": "The fully-qualified user ID." - }, - "reason": { - "type": "string", - "description": "The reason for the ban." - } - } - }, - "InitialSyncRoomData": { - "id": "InitialSyncRoomData", - "properties": { - "membership": { - "type": "string", - "description": "This user's membership state in this room.", - "required": true - }, - "room_id": { - "type": "string", - "description": "The ID of this room.", - "required": true - }, - "messages": { - "type": "MessagePaginationChunk", - "description": "The most recent messages for this room, governed by the limit parameter.", - "required": false - }, - "state": { - "type": "array", - "description": "A list of state events representing the current state of the room.", - "required": false, - "items": { - "$ref": "Event" - } - } - } - } - } -} From 66df7f1aaf73a4f5774aee705de4dac2c8d8ad5e Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Sun, 12 Oct 2014 00:00:37 +0100 Subject: [PATCH 080/106] remove wishlist in favour of jira --- WISHLIST.rst | 9 --------- 1 file changed, 9 deletions(-) delete mode 100644 WISHLIST.rst diff --git a/WISHLIST.rst b/WISHLIST.rst deleted file mode 100644 index a0713f1966..0000000000 --- a/WISHLIST.rst +++ /dev/null @@ -1,9 +0,0 @@ -Broad-sweeping stuff which would be nice to have -================================================ - - - Additional SQL backends beyond sqlite - - homeserver implementation in go - - homeserver implementation in node.js - - client SDKs - - libpurple library - - irssi plugin? From 693d0b8f4562d79ca00e05ce0cfd2d8c7b175b59 Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Mon, 13 Oct 2014 10:49:04 +0100 Subject: [PATCH 081/106] Replace on_send_callback with something a bit clearer so that we can sign messages --- synapse/http/client.py | 46 ++++++++++++++++++++++++++++++++---------- 1 file changed, 35 insertions(+), 11 deletions(-) diff --git a/synapse/http/client.py b/synapse/http/client.py index 5c2fbd1f87..0e8fa2eb25 100644 --- a/synapse/http/client.py +++ b/synapse/http/client.py @@ -31,6 +31,7 @@ from StringIO import StringIO import json import logging import urllib +import urlparse logger = logging.getLogger(__name__) @@ -68,16 +69,20 @@ class BaseHttpClient(object): self.hs = hs @defer.inlineCallbacks - def _create_request(self, destination, method, path_bytes, param_bytes=b"", - query_bytes=b"", producer=None, headers_dict={}, - retry_on_dns_fail=True, on_send_callback=None): + def _create_request(self, destination, method, path_bytes, + body_callback, headers_dict={}, param_bytes=b"", + query_bytes=b"", retry_on_dns_fail=True): """ Creates and sends a request to the given url """ headers_dict[b"User-Agent"] = [b"Synapse"] headers_dict[b"Host"] = [destination] - logger.debug("Sending request to %s: %s %s;%s?%s", - destination, method, path_bytes, param_bytes, query_bytes) + url_bytes = urlparse.urlunparse( + ("", "", path_bytes, param_bytes, query_bytes, "",) + ) + + logger.debug("Sending request to %s: %s %s", + destination, method, url_bytes) logger.debug( "Types: %s", @@ -93,8 +98,8 @@ class BaseHttpClient(object): endpoint = self._getEndpoint(reactor, destination); while True: - if on_send_callback: - on_send_callback(destination, method, path_bytes, producer) + + producer = body_callback(method, url_bytes, headers_dict) try: response = yield self.agent.request( @@ -167,13 +172,22 @@ class MatrixHttpClient(BaseHttpClient): will be the decoded JSON body. On a 4xx or 5xx error response a CodeMessageException is raised. """ + + if not on_send_callback: + def on_send_callback(destination, method, path_bytes, producer): + pass + + def body_callback(method, url_bytes, headers_dict): + producer = _JsonProducer(data) + on_send_callback(destination, method, path, producer) + return producer + response = yield self._create_request( destination.encode("ascii"), "PUT", path.encode("ascii"), - producer=_JsonProducer(data), + body_callback=body_callback, headers_dict={"Content-Type": ["application/json"]}, - on_send_callback=on_send_callback, ) logger.debug("Getting resp body") @@ -206,11 +220,15 @@ class MatrixHttpClient(BaseHttpClient): query_bytes = urllib.urlencode(args, True) logger.debug("Query bytes: %s Retry DNS: %s", args, retry_on_dns_fail) + def body_callback(method, url_bytes, headers_dict): + return None + response = yield self._create_request( destination.encode("ascii"), "GET", path.encode("ascii"), query_bytes=query_bytes, + body_callback=body_callback, retry_on_dns_fail=retry_on_dns_fail ) @@ -239,11 +257,14 @@ class IdentityServerHttpClient(BaseHttpClient): logger.debug("post_urlencoded_get_json args: %s", args) query_bytes = urllib.urlencode(args, True) + def body_callback(method, url_bytes, headers_dict): + return FileBodyProducer(StringIO(query_bytes)) + response = yield self._create_request( destination.encode("ascii"), "POST", path.encode("ascii"), - producer=FileBodyProducer(StringIO(query_bytes)), + body_callback=body_callback, headers_dict={ "Content-Type": ["application/x-www-form-urlencoded"] } @@ -265,11 +286,14 @@ class CaptchaServerHttpClient(MatrixHttpClient): args={}): query_bytes = urllib.urlencode(args, True) + def body_callback(method, url_bytes, headers_dict): + return FileBodyProducer(StringIO(query_bytes)) + response = yield self._create_request( destination.encode("ascii"), "POST", path.encode("ascii"), - producer=FileBodyProducer(StringIO(query_bytes)), + body_callback=body_callback, headers_dict={ "Content-Type": ["application/x-www-form-urlencoded"] } From 10ef8e6e4bb9d50fd2c636cfbb66d3dd6d6f94e9 Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Mon, 13 Oct 2014 11:49:40 +0100 Subject: [PATCH 082/106] SYN-75 sign at the request level rather than the transaction level --- synapse/federation/replication.py | 13 -------- synapse/federation/transport.py | 18 ++-------- synapse/federation/units.py | 5 +++ synapse/http/client.py | 52 +++++++++++++++++++++++++---- tests/federation/test_federation.py | 4 +-- tests/handlers/test_presence.py | 26 +++++++-------- tests/handlers/test_typing.py | 4 +-- 7 files changed, 70 insertions(+), 52 deletions(-) diff --git a/synapse/federation/replication.py b/synapse/federation/replication.py index b4235585a3..2346d55045 100644 --- a/synapse/federation/replication.py +++ b/synapse/federation/replication.py @@ -25,8 +25,6 @@ from .persistence import PduActions, TransactionActions from synapse.util.logutils import log_function -from syutil.crypto.jsonsign import sign_json - import logging @@ -66,8 +64,6 @@ class ReplicationLayer(object): hs, self.transaction_actions, transport_layer ) - self.keyring = hs.get_keyring() - self.handler = None self.edu_handlers = {} self.query_handlers = {} @@ -296,10 +292,6 @@ class ReplicationLayer(object): @defer.inlineCallbacks @log_function def on_incoming_transaction(self, transaction_data): - yield self.keyring.verify_json_for_server( - transaction_data["origin"], transaction_data - ) - transaction = Transaction(**transaction_data) for p in transaction.pdus: @@ -500,7 +492,6 @@ class _TransactionQueue(object): """ def __init__(self, hs, transaction_actions, transport_layer): - self.signing_key = hs.config.signing_key[0] self.server_name = hs.hostname self.transaction_actions = transaction_actions self.transport_layer = transport_layer @@ -615,9 +606,6 @@ class _TransactionQueue(object): # Actually send the transaction - server_name = self.server_name - signing_key = self.signing_key - # FIXME (erikj): This is a bit of a hack to make the Pdu age # keys work def json_data_cb(): @@ -627,7 +615,6 @@ class _TransactionQueue(object): for p in data["pdus"]: if "age_ts" in p: p["age"] = now - int(p["age_ts"]) - data = sign_json(data, server_name, signing_key) return data code, response = yield self.transport_layer.send_transaction( diff --git a/synapse/federation/transport.py b/synapse/federation/transport.py index 1f864f5fa7..48fc9fbf5e 100644 --- a/synapse/federation/transport.py +++ b/synapse/federation/transport.py @@ -163,27 +163,15 @@ class TransportLayer(object): if transaction.destination == self.server_name: raise RuntimeError("Transport layer cannot send to itself!") - if json_data_callback is None: - def json_data_callback(): - return transaction.get_dict() - - # FIXME (erikj): This is a bit of a hack to make the Pdu age - # keys work - def cb(destination, method, path_bytes, producer): - json_data = json_data_callback() - del json_data["destination"] - del json_data["transaction_id"] - producer.reset(json_data) - + # FIXME: This is only used by the tests. The actual json sent is + # generated by the json_data_callback. json_data = transaction.get_dict() - del json_data["destination"] - del json_data["transaction_id"] code, response = yield self.client.put_json( transaction.destination, path=PREFIX + "/send/%s/" % transaction.transaction_id, data=json_data, - on_send_callback=cb, + json_data_callback=json_data_callback, ) logger.debug( diff --git a/synapse/federation/units.py b/synapse/federation/units.py index 1ca123d1bf..ecca35ac43 100644 --- a/synapse/federation/units.py +++ b/synapse/federation/units.py @@ -190,6 +190,11 @@ class Transaction(JsonEncodedObject): "destination", ] + internal_keys = [ + "transaction_id", + "destination", + ] + required_keys = [ "transaction_id", "origin", diff --git a/synapse/http/client.py b/synapse/http/client.py index 0e8fa2eb25..62fe14fa5e 100644 --- a/synapse/http/client.py +++ b/synapse/http/client.py @@ -26,6 +26,8 @@ from syutil.jsonutil import encode_canonical_json from synapse.api.errors import CodeMessageException, SynapseError +from syutil.crypto.jsonsign import sign_json + from StringIO import StringIO import json @@ -147,7 +149,7 @@ class BaseHttpClient(object): class MatrixHttpClient(BaseHttpClient): - """ Wrapper around the twisted HTTP client api. Implements + """ Wrapper around the twisted HTTP client api. Implements Attributes: agent (twisted.web.client.Agent): The twisted Agent used to send the @@ -156,8 +158,38 @@ class MatrixHttpClient(BaseHttpClient): RETRY_DNS_LOOKUP_FAILURES = "__retry_dns" + def __init__(self, hs): + self.signing_key = hs.config.signing_key[0] + self.server_name = hs.hostname + BaseHttpClient.__init__(self, hs) + + def sign_request(self, destination, method, url_bytes, headers_dict, + content=None): + request = { + "method": method, + "uri": url_bytes, + "origin": self.server_name, + "destination": destination, + } + + if content is not None: + request["content"] = content + + request = sign_json(request, self.server_name, self.signing_key) + + auth_headers = [] + + for key,sig in request["signatures"][self.server_name].items(): + auth_headers.append( + "X-Matrix origin=%s,key=\"%s\",sig=\"%s\"" % ( + self.server_name, key, sig, + ) + ) + + headers_dict["Authorization"] = auth_headers + @defer.inlineCallbacks - def put_json(self, destination, path, data, on_send_callback=None): + def put_json(self, destination, path, data={}, json_data_callback=None): """ Sends the specifed json data using PUT Args: @@ -166,6 +198,8 @@ class MatrixHttpClient(BaseHttpClient): path (str): The HTTP path. data (dict): A dict containing the data that will be used as the request body. This will be encoded as JSON. + json_data_callback (callable): A callable returning the dict to + use as the request body. Returns: Deferred: Succeeds when we get a 2xx HTTP response. The result @@ -173,13 +207,16 @@ class MatrixHttpClient(BaseHttpClient): CodeMessageException is raised. """ - if not on_send_callback: - def on_send_callback(destination, method, path_bytes, producer): - pass + if not json_data_callback: + def json_data_callback(): + return data def body_callback(method, url_bytes, headers_dict): - producer = _JsonProducer(data) - on_send_callback(destination, method, path, producer) + json_data = json_data_callback() + self.sign_request( + destination, method, url_bytes, headers_dict, json_data + ) + producer = _JsonProducer(json_data) return producer response = yield self._create_request( @@ -221,6 +258,7 @@ class MatrixHttpClient(BaseHttpClient): logger.debug("Query bytes: %s Retry DNS: %s", args, retry_on_dns_fail) def body_callback(method, url_bytes, headers_dict): + self.sign_request(destination, method, url_bytes, headers_dict) return None response = yield self._create_request( diff --git a/tests/federation/test_federation.py b/tests/federation/test_federation.py index 01f07ff36d..91edeaa4b9 100644 --- a/tests/federation/test_federation.py +++ b/tests/federation/test_federation.py @@ -186,7 +186,7 @@ class FederationTestCase(unittest.TestCase): }, ] }, - on_send_callback=ANY, + json_data_callback=ANY, ) @defer.inlineCallbacks @@ -218,7 +218,7 @@ class FederationTestCase(unittest.TestCase): } ], }, - on_send_callback=ANY, + json_data_callback=ANY, ) @defer.inlineCallbacks diff --git a/tests/handlers/test_presence.py b/tests/handlers/test_presence.py index c9406b70c4..15022b8d05 100644 --- a/tests/handlers/test_presence.py +++ b/tests/handlers/test_presence.py @@ -300,7 +300,7 @@ class PresenceInvitesTestCase(unittest.TestCase): "observed_user": "@cabbage:elsewhere", } ), - on_send_callback=ANY, + json_data_callback=ANY, ), defer.succeed((200, "OK")) ) @@ -329,7 +329,7 @@ class PresenceInvitesTestCase(unittest.TestCase): "observed_user": "@apple:test", } ), - on_send_callback=ANY, + json_data_callback=ANY, ), defer.succeed((200, "OK")) ) @@ -365,7 +365,7 @@ class PresenceInvitesTestCase(unittest.TestCase): "observed_user": "@durian:test", } ), - on_send_callback=ANY, + json_data_callback=ANY, ), defer.succeed((200, "OK")) ) @@ -786,7 +786,7 @@ class PresencePushTestCase(unittest.TestCase): ], } ), - on_send_callback=ANY, + json_data_callback=ANY, ), defer.succeed((200, "OK")) ) @@ -802,7 +802,7 @@ class PresencePushTestCase(unittest.TestCase): ], } ), - on_send_callback=ANY, + json_data_callback=ANY, ), defer.succeed((200, "OK")) ) @@ -928,7 +928,7 @@ class PresencePushTestCase(unittest.TestCase): ], } ), - on_send_callback=ANY, + json_data_callback=ANY, ), defer.succeed((200, "OK")) ) @@ -943,7 +943,7 @@ class PresencePushTestCase(unittest.TestCase): ], } ), - on_send_callback=ANY, + json_data_callback=ANY, ), defer.succeed((200, "OK")) ) @@ -973,7 +973,7 @@ class PresencePushTestCase(unittest.TestCase): ], } ), - on_send_callback=ANY, + json_data_callback=ANY, ), defer.succeed((200, "OK")) ) @@ -1175,7 +1175,7 @@ class PresencePollingTestCase(unittest.TestCase): "poll": [ "@potato:remote" ], }, ), - on_send_callback=ANY, + json_data_callback=ANY, ), defer.succeed((200, "OK")) ) @@ -1188,7 +1188,7 @@ class PresencePollingTestCase(unittest.TestCase): "push": [ {"user_id": "@clementine:test" }], }, ), - on_send_callback=ANY, + json_data_callback=ANY, ), defer.succeed((200, "OK")) ) @@ -1217,7 +1217,7 @@ class PresencePollingTestCase(unittest.TestCase): "push": [ {"user_id": "@fig:test" }], }, ), - on_send_callback=ANY, + json_data_callback=ANY, ), defer.succeed((200, "OK")) ) @@ -1250,7 +1250,7 @@ class PresencePollingTestCase(unittest.TestCase): "unpoll": [ "@potato:remote" ], }, ), - on_send_callback=ANY, + json_data_callback=ANY, ), defer.succeed((200, "OK")) ) @@ -1282,7 +1282,7 @@ class PresencePollingTestCase(unittest.TestCase): ], }, ), - on_send_callback=ANY, + json_data_callback=ANY, ), defer.succeed((200, "OK")) ) diff --git a/tests/handlers/test_typing.py b/tests/handlers/test_typing.py index ff40343b8c..064b04c217 100644 --- a/tests/handlers/test_typing.py +++ b/tests/handlers/test_typing.py @@ -175,7 +175,7 @@ class TypingNotificationsTestCase(unittest.TestCase): "typing": True, } ), - on_send_callback=ANY, + json_data_callback=ANY, ), defer.succeed((200, "OK")) ) @@ -226,7 +226,7 @@ class TypingNotificationsTestCase(unittest.TestCase): "typing": False, } ), - on_send_callback=ANY, + json_data_callback=ANY, ), defer.succeed((200, "OK")) ) From 66848557672977e17f0d5ba785b7567b305ccdbe Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Mon, 13 Oct 2014 14:37:46 +0100 Subject: [PATCH 083/106] Verify signatures for server2server requests --- synapse/federation/__init__.py | 1 + synapse/federation/transport.py | 110 ++++++++++++++++++++++------ synapse/http/client.py | 10 ++- tests/federation/test_federation.py | 1 + tests/utils.py | 3 + 5 files changed, 100 insertions(+), 25 deletions(-) diff --git a/synapse/federation/__init__.py b/synapse/federation/__init__.py index 1351b68fd6..0112588656 100644 --- a/synapse/federation/__init__.py +++ b/synapse/federation/__init__.py @@ -22,6 +22,7 @@ from .transport import TransportLayer def initialize_http_replication(homeserver): transport = TransportLayer( + homeserver, homeserver.hostname, server=homeserver.get_resource_for_federation(), client=homeserver.get_http_client() diff --git a/synapse/federation/transport.py b/synapse/federation/transport.py index 48fc9fbf5e..7b2631fbc8 100644 --- a/synapse/federation/transport.py +++ b/synapse/federation/transport.py @@ -54,7 +54,7 @@ class TransportLayer(object): we receive data. """ - def __init__(self, server_name, server, client): + def __init__(self, homeserver, server_name, server, client): """ Args: server_name (str): Local home server host @@ -63,6 +63,7 @@ class TransportLayer(object): client (synapse.protocol.http.HttpClient): the http client used to send requests """ + self.keyring = homeserver.get_keyring() self.server_name = server_name self.server = server self.client = client @@ -195,6 +196,66 @@ class TransportLayer(object): defer.returnValue(response) + @defer.inlineCallbacks + def _authenticate_request(self, request): + json_request = { + "method": request.method, + "uri": request.uri, + "destination": self.server_name, + "signatures": {}, + } + + content = None + origin = None + + if request.method == "PUT": + #TODO: Handle other method types? other content types? + content_bytes = request.content.read() + content = json.loads(content_bytes) + json_request["content"] = content + + def parse_auth_header(header_str): + params = auth.split(" ")[1].split(",") + param_dict = dict(kv.split("=") for kv in params) + def strip_quotes(value): + if value.startswith("\""): + return value[1:-1] + else: + return value + origin = strip_quotes(param_dict["origin"]) + key = strip_quotes(param_dict["key"]) + sig = strip_quotes(param_dict["sig"]) + return (origin, key, sig) + + auth_headers = request.requestHeaders.getRawHeaders(b"Authorization") + + if not auth_headers: + #TODO(markjh): Send a 401 response? + raise Exception("Missing auth headers") + + for auth in auth_headers: + if auth.startswith("X-Matrix"): + (origin, key, sig) = parse_auth_header(auth) + json_request["origin"] = origin + json_request["signatures"].setdefault(origin,{})[key] = sig + + from syutil.jsonutil import encode_canonical_json + logger.debug("Checking %s %s", + origin, encode_canonical_json(json_request)) + yield self.keyring.verify_json_for_server(origin, json_request) + + defer.returnValue((origin, content)) + + def _with_authentication(self, handler): + @defer.inlineCallbacks + def new_handler(request, *args, **kwargs): + (origin, content) = yield self._authenticate_request(request) + response = yield handler( + origin, content, request.args, *args, **kwargs + ) + defer.returnValue(response) + return new_handler + @log_function def register_received_handler(self, handler): """ Register a handler that will be fired when we receive data. @@ -208,7 +269,7 @@ class TransportLayer(object): self.server.register_path( "PUT", re.compile("^" + PREFIX + "/send/([^/]*)/$"), - self._on_send_request + self._with_authentication(self._on_send_request) ) @log_function @@ -226,9 +287,9 @@ class TransportLayer(object): self.server.register_path( "GET", re.compile("^" + PREFIX + "/pull/$"), - lambda request: handler.on_pull_request( - request.args["origin"][0], - request.args["v"] + self._with_authentication( + lambda origin, content, query: + handler.on_pull_request(query["origin"][0], query["v"]) ) ) @@ -237,8 +298,9 @@ class TransportLayer(object): self.server.register_path( "GET", re.compile("^" + PREFIX + "/pdu/([^/]*)/([^/]*)/$"), - lambda request, pdu_origin, pdu_id: handler.on_pdu_request( - pdu_origin, pdu_id + self._with_authentication( + lambda origin, content, query, pdu_origin, pdu_id: + handler.on_pdu_request(pdu_origin, pdu_id) ) ) @@ -246,38 +308,47 @@ class TransportLayer(object): self.server.register_path( "GET", re.compile("^" + PREFIX + "/state/([^/]*)/$"), - lambda request, context: handler.on_context_state_request( - context + self._with_authentication( + lambda origin, content, query, context: + handler.on_context_state_request(context) ) ) self.server.register_path( "GET", re.compile("^" + PREFIX + "/backfill/([^/]*)/$"), - lambda request, context: self._on_backfill_request( - context, request.args["v"], - request.args["limit"] + self._with_authentication( + lambda origin, content, query, context: + self._on_backfill_request( + context, query["v"], query["limit"] + ) ) ) self.server.register_path( "GET", re.compile("^" + PREFIX + "/context/([^/]*)/$"), - lambda request, context: handler.on_context_pdus_request(context) + self._with_authentication( + lambda origin, content, query, context: + handler.on_context_pdus_request(context) + ) ) # This is when we receive a server-server Query self.server.register_path( "GET", re.compile("^" + PREFIX + "/query/([^/]*)$"), - lambda request, query_type: handler.on_query_request( - query_type, {k: v[0] for k, v in request.args.items()} + self._with_authentication( + lambda origin, content, query, query_type: + handler.on_query_request( + query_type, {k: v[0] for k, v in query.items()} + ) ) ) @defer.inlineCallbacks @log_function - def _on_send_request(self, request, transaction_id): + def _on_send_request(self, origin, content, query, transaction_id): """ Called on PUT /send// Args: @@ -292,12 +363,7 @@ class TransportLayer(object): """ # Parse the request try: - data = request.content.read() - - l = data[:20].encode("string_escape") - logger.debug("Got data: \"%s\"", l) - - transaction_data = json.loads(data) + transaction_data = content logger.debug( "Decoded %s: %s", diff --git a/synapse/http/client.py b/synapse/http/client.py index 62fe14fa5e..9f54b74e3a 100644 --- a/synapse/http/client.py +++ b/synapse/http/client.py @@ -177,16 +177,20 @@ class MatrixHttpClient(BaseHttpClient): request = sign_json(request, self.server_name, self.signing_key) + from syutil.jsonutil import encode_canonical_json + logger.debug("Signing " + " " * 11 + "%s %s", + self.server_name, encode_canonical_json(request)) + auth_headers = [] for key,sig in request["signatures"][self.server_name].items(): - auth_headers.append( + auth_headers.append(bytes( "X-Matrix origin=%s,key=\"%s\",sig=\"%s\"" % ( self.server_name, key, sig, ) - ) + )) - headers_dict["Authorization"] = auth_headers + headers_dict[b"Authorization"] = auth_headers @defer.inlineCallbacks def put_json(self, destination, path, data={}, json_data_callback=None): diff --git a/tests/federation/test_federation.py b/tests/federation/test_federation.py index 91edeaa4b9..8d277d6612 100644 --- a/tests/federation/test_federation.py +++ b/tests/federation/test_federation.py @@ -221,6 +221,7 @@ class FederationTestCase(unittest.TestCase): json_data_callback=ANY, ) + @defer.inlineCallbacks def test_recv_edu(self): recv_observer = Mock() diff --git a/tests/utils.py b/tests/utils.py index 797818be72..83dbd4f4d3 100644 --- a/tests/utils.py +++ b/tests/utils.py @@ -76,6 +76,9 @@ class MockHttpResource(HttpServer): mock_content.configure_mock(**config) mock_request.content = mock_content + mock_request.method = http_method + mock_request.uri = path + # return the right path if the event requires it mock_request.path = path From 75e517a2da4890b55f492897599185c91ed0826c Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Mon, 13 Oct 2014 15:41:20 +0100 Subject: [PATCH 084/106] Remove debug logging, raise a proper SynapseError if the auth header is missing --- synapse/federation/transport.py | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/synapse/federation/transport.py b/synapse/federation/transport.py index 7b2631fbc8..93134ee274 100644 --- a/synapse/federation/transport.py +++ b/synapse/federation/transport.py @@ -24,6 +24,7 @@ over a different (albeit still reliable) protocol. from twisted.internet import defer from synapse.api.urls import FEDERATION_PREFIX as PREFIX +from synapse.api.errors import Codes, SynapseError from synapse.util.logutils import log_function import logging @@ -230,8 +231,9 @@ class TransportLayer(object): auth_headers = request.requestHeaders.getRawHeaders(b"Authorization") if not auth_headers: - #TODO(markjh): Send a 401 response? - raise Exception("Missing auth headers") + raise SynapseError( + 401, "Missing Authorization headers", Codes.FORBIDDEN, + ) for auth in auth_headers: if auth.startswith("X-Matrix"): @@ -239,9 +241,6 @@ class TransportLayer(object): json_request["origin"] = origin json_request["signatures"].setdefault(origin,{})[key] = sig - from syutil.jsonutil import encode_canonical_json - logger.debug("Checking %s %s", - origin, encode_canonical_json(json_request)) yield self.keyring.verify_json_for_server(origin, json_request) defer.returnValue((origin, content)) From 25d80f35f10239b280cf374f60ccb552087fcf44 Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Mon, 13 Oct 2014 15:53:18 +0100 Subject: [PATCH 085/106] Raise a SynapseError if the authorisation header is missing or malformed --- synapse/federation/transport.py | 46 +++++++++++++++++++-------------- tests/utils.py | 4 +++ 2 files changed, 31 insertions(+), 19 deletions(-) diff --git a/synapse/federation/transport.py b/synapse/federation/transport.py index 93134ee274..7a4c1f6443 100644 --- a/synapse/federation/transport.py +++ b/synapse/federation/transport.py @@ -211,36 +211,44 @@ class TransportLayer(object): if request.method == "PUT": #TODO: Handle other method types? other content types? - content_bytes = request.content.read() - content = json.loads(content_bytes) - json_request["content"] = content + try: + content_bytes = request.content.read() + content = json.loads(content_bytes) + json_request["content"] = content + except: + raise SynapseError(400, "Unable to parse JSON", Codes.BAD_JSON) def parse_auth_header(header_str): - params = auth.split(" ")[1].split(",") - param_dict = dict(kv.split("=") for kv in params) - def strip_quotes(value): - if value.startswith("\""): - return value[1:-1] - else: - return value - origin = strip_quotes(param_dict["origin"]) - key = strip_quotes(param_dict["key"]) - sig = strip_quotes(param_dict["sig"]) - return (origin, key, sig) + try: + params = auth.split(" ")[1].split(",") + param_dict = dict(kv.split("=") for kv in params) + def strip_quotes(value): + if value.startswith("\""): + return value[1:-1] + else: + return value + origin = strip_quotes(param_dict["origin"]) + key = strip_quotes(param_dict["key"]) + sig = strip_quotes(param_dict["sig"]) + return (origin, key, sig) + except: + raise SynapseError( + 400, "Malformed Authorization Header", Codes.FORBIDDEN + ) auth_headers = request.requestHeaders.getRawHeaders(b"Authorization") - if not auth_headers: - raise SynapseError( - 401, "Missing Authorization headers", Codes.FORBIDDEN, - ) - for auth in auth_headers: if auth.startswith("X-Matrix"): (origin, key, sig) = parse_auth_header(auth) json_request["origin"] = origin json_request["signatures"].setdefault(origin,{})[key] = sig + if not json_request["signatures"]: + raise SynapseError( + 401, "Missing Authorization headers", Codes.FORBIDDEN, + ) + yield self.keyring.verify_json_for_server(origin, json_request) defer.returnValue((origin, content)) diff --git a/tests/utils.py b/tests/utils.py index 83dbd4f4d3..60fd6085ac 100644 --- a/tests/utils.py +++ b/tests/utils.py @@ -79,6 +79,10 @@ class MockHttpResource(HttpServer): mock_request.method = http_method mock_request.uri = path + mock_request.requestHeaders.getRawHeaders.return_value=[ + "X-Matrix origin=test,key=,sig=" + ] + # return the right path if the event requires it mock_request.path = path From 07639c79d9536cf293c550e5849ce6b5dd82189e Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Mon, 13 Oct 2014 16:39:15 +0100 Subject: [PATCH 086/106] Respond with more helpful error messages for unsigned requests --- synapse/api/errors.py | 1 + synapse/crypto/keyclient.py | 4 ++-- synapse/crypto/keyring.py | 33 +++++++++++++++++++++++++++++++-- synapse/federation/transport.py | 4 ++-- synapse/storage/_base.py | 11 +++++++---- synapse/storage/keys.py | 2 ++ 6 files changed, 45 insertions(+), 10 deletions(-) diff --git a/synapse/api/errors.py b/synapse/api/errors.py index 88175602c4..6d7d499fea 100644 --- a/synapse/api/errors.py +++ b/synapse/api/errors.py @@ -19,6 +19,7 @@ import logging class Codes(object): + UNAUTHORIZED = "M_UNAUTHORIZED" FORBIDDEN = "M_FORBIDDEN" BAD_JSON = "M_BAD_JSON" NOT_JSON = "M_NOT_JSON" diff --git a/synapse/crypto/keyclient.py b/synapse/crypto/keyclient.py index c26f16a038..5949ea0573 100644 --- a/synapse/crypto/keyclient.py +++ b/synapse/crypto/keyclient.py @@ -43,7 +43,7 @@ def fetch_server_key(server_name, ssl_context_factory): return except Exception as e: logger.exception(e) - raise IOError("Cannot get key for " % server_name) + raise IOError("Cannot get key for %s" % server_name) class SynapseKeyClientError(Exception): @@ -93,7 +93,7 @@ class SynapseKeyClientProtocol(HTTPClient): def on_timeout(self): logger.debug("Timeout waiting for response from %s", self.transport.getHost()) - self.on_remote_key.errback(IOError("Timeout waiting for response")) + self.remote_key.errback(IOError("Timeout waiting for response")) self.transport.abortConnection() diff --git a/synapse/crypto/keyring.py b/synapse/crypto/keyring.py index ce19c69bd5..3c85295274 100644 --- a/synapse/crypto/keyring.py +++ b/synapse/crypto/keyring.py @@ -20,6 +20,7 @@ from syutil.crypto.signing_key import ( is_signing_algorithm_supported, decode_verify_key_bytes ) from syutil.base64util import decode_base64, encode_base64 +from synapse.api.errors import SynapseError, Codes from OpenSSL import crypto @@ -38,8 +39,36 @@ class Keyring(object): @defer.inlineCallbacks def verify_json_for_server(self, server_name, json_object): key_ids = signature_ids(json_object, server_name) - verify_key = yield self.get_server_verify_key(server_name, key_ids) - verify_signed_json(json_object, server_name, verify_key) + if not key_ids: + raise SynapseError( + 400, + "No supported algorithms in signing keys", + Codes.UNAUTHORIZED, + ) + try: + verify_key = yield self.get_server_verify_key(server_name, key_ids) + except IOError: + raise SynapseError( + 502, + "Error downloading keys for %s" % (server_name,), + Codes.UNAUTHORIZED, + ) + except: + raise SynapseError( + 401, + "No key for %s with id %s" % (server_name, key_ids), + Codes.UNAUTHORIZED, + ) + try: + verify_signed_json(json_object, server_name, verify_key) + except: + raise SynapseError( + 401, + "Invalid signature for server %s with key %s:%s" % ( + server_name, verify_key.alg, verify_key.version + ), + Codes.UNAUTHORIZED, + ) @defer.inlineCallbacks def get_server_verify_key(self, server_name, key_ids): diff --git a/synapse/federation/transport.py b/synapse/federation/transport.py index 7a4c1f6443..755eee8cf6 100644 --- a/synapse/federation/transport.py +++ b/synapse/federation/transport.py @@ -233,7 +233,7 @@ class TransportLayer(object): return (origin, key, sig) except: raise SynapseError( - 400, "Malformed Authorization Header", Codes.FORBIDDEN + 400, "Malformed Authorization header", Codes.UNAUTHORIZED ) auth_headers = request.requestHeaders.getRawHeaders(b"Authorization") @@ -246,7 +246,7 @@ class TransportLayer(object): if not json_request["signatures"]: raise SynapseError( - 401, "Missing Authorization headers", Codes.FORBIDDEN, + 401, "Missing Authorization headers", Codes.UNAUTHORIZED, ) yield self.keyring.verify_json_for_server(origin, json_request) diff --git a/synapse/storage/_base.py b/synapse/storage/_base.py index 889de2bedc..dba50f1213 100644 --- a/synapse/storage/_base.py +++ b/synapse/storage/_base.py @@ -121,7 +121,7 @@ class SQLBaseStore(object): # "Simple" SQL API methods that operate on a single table with no JOINs, # no complex WHERE clauses, just a dict of values for columns. - def _simple_insert(self, table, values, or_replace=False): + def _simple_insert(self, table, values, or_replace=False, or_ignore=False): """Executes an INSERT query on the named table. Args: @@ -130,13 +130,16 @@ class SQLBaseStore(object): or_replace : bool; if True performs an INSERT OR REPLACE """ return self.runInteraction( - self._simple_insert_txn, table, values, or_replace=or_replace + self._simple_insert_txn, table, values, or_replace=or_replace, + or_ignore=or_ignore, ) @log_function - def _simple_insert_txn(self, txn, table, values, or_replace=False): + def _simple_insert_txn(self, txn, table, values, or_replace=False, + or_ignore=False): sql = "%s INTO %s (%s) VALUES(%s)" % ( - ("INSERT OR REPLACE" if or_replace else "INSERT"), + ("INSERT OR REPLACE" if or_replace else + "INSERT OR IGNORE" if or_ignore else "INSERT"), table, ", ".join(k for k in values), ", ".join("?" for k in values) diff --git a/synapse/storage/keys.py b/synapse/storage/keys.py index 253dc17be2..8189e071a3 100644 --- a/synapse/storage/keys.py +++ b/synapse/storage/keys.py @@ -65,6 +65,7 @@ class KeyStore(SQLBaseStore): "ts_added_ms": time_now_ms, "tls_certificate": buffer(tls_certificate_bytes), }, + or_ignore=True, ) @defer.inlineCallbacks @@ -113,4 +114,5 @@ class KeyStore(SQLBaseStore): "ts_added_ms": time_now_ms, "verify_key": buffer(verify_key.encode()), }, + or_ignore=True, ) From 34034af1c9f67af399b59581af8469d489757446 Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Mon, 13 Oct 2014 16:47:23 +0100 Subject: [PATCH 087/106] Better response message when signature is missing or unsupported --- synapse/crypto/keyring.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/synapse/crypto/keyring.py b/synapse/crypto/keyring.py index 3c85295274..015f76ebe3 100644 --- a/synapse/crypto/keyring.py +++ b/synapse/crypto/keyring.py @@ -42,7 +42,7 @@ class Keyring(object): if not key_ids: raise SynapseError( 400, - "No supported algorithms in signing keys", + "Not signed with a supported algorithm", Codes.UNAUTHORIZED, ) try: From c18a6433d4f2ff0cad6bcaf92d05d8540cc75b3d Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Mon, 13 Oct 2014 23:24:14 +0100 Subject: [PATCH 088/106] typoe --- docs/server-server/signing.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/server-server/signing.rst b/docs/server-server/signing.rst index a592f48c35..dae10f121b 100644 --- a/docs/server-server/signing.rst +++ b/docs/server-server/signing.rst @@ -62,7 +62,7 @@ To check if an entity has signed a JSON object a server does the following 1. Checks if the ``signatures`` object contains an entry with the name of the entity. If the entry is missing then the check fails. -2. Removes any *signing key identifiers* from the entry with algrothims it +2. Removes any *signing key identifiers* from the entry with algorithms it doesn't understand. If there are no *signing key identifiers* left then the check fails. 3. Looks up *verification keys* for the remaining *signing key identifiers* From 4fe5dfa74ca009681c821f7763a78aab2c04925c Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Tue, 14 Oct 2014 10:30:50 +0100 Subject: [PATCH 089/106] Note that this breaks federation --- CHANGES.rst | 4 ++++ UPGRADE.rst | 5 +++++ 2 files changed, 9 insertions(+) diff --git a/CHANGES.rst b/CHANGES.rst index 1690490f66..5b05900daf 100644 --- a/CHANGES.rst +++ b/CHANGES.rst @@ -1,3 +1,7 @@ +Changes in latest +================= +This breaks federation becuase of signing + Changes in synapse 0.3.4 (2014-09-25) ===================================== This version adds support for using a TURN server. See docs/turn-howto.rst on diff --git a/UPGRADE.rst b/UPGRADE.rst index 713fb9ae83..2ae9254ecf 100644 --- a/UPGRADE.rst +++ b/UPGRADE.rst @@ -1,3 +1,8 @@ +Upgrading to latest +=================== +This breaks federation between old and new servers due to signing of +transactions. + Upgrading to v0.3.0 =================== From f74e850b5cf7947fbbd13d8bfd1daf43d535741f Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Tue, 14 Oct 2014 11:46:13 +0100 Subject: [PATCH 090/106] remove debugging logging for signing requests --- synapse/http/client.py | 4 ---- 1 file changed, 4 deletions(-) diff --git a/synapse/http/client.py b/synapse/http/client.py index 9f54b74e3a..316ca1ccb9 100644 --- a/synapse/http/client.py +++ b/synapse/http/client.py @@ -177,10 +177,6 @@ class MatrixHttpClient(BaseHttpClient): request = sign_json(request, self.server_name, self.signing_key) - from syutil.jsonutil import encode_canonical_json - logger.debug("Signing " + " " * 11 + "%s %s", - self.server_name, encode_canonical_json(request)) - auth_headers = [] for key,sig in request["signatures"][self.server_name].items(): From 9aed791fc38790eae6c24e154e7f82ac8509295d Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Tue, 14 Oct 2014 16:44:27 +0100 Subject: [PATCH 091/106] SYN-103: Ignore the 'origin' key in received EDUs. Instead take the origin from the transaction itself --- synapse/federation/replication.py | 2 +- synapse/federation/units.py | 8 ++++++-- tests/federation/test_federation.py | 1 + tests/handlers/test_presence.py | 1 + tests/handlers/test_typing.py | 1 + 5 files changed, 10 insertions(+), 3 deletions(-) diff --git a/synapse/federation/replication.py b/synapse/federation/replication.py index 2346d55045..9363ac7300 100644 --- a/synapse/federation/replication.py +++ b/synapse/federation/replication.py @@ -319,7 +319,7 @@ class ReplicationLayer(object): if hasattr(transaction, "edus"): for edu in [Edu(**x) for x in transaction.edus]: - self.received_edu(edu.origin, edu.edu_type, edu.content) + self.received_edu(transaction.origin, edu.edu_type, edu.content) results = yield defer.DeferredList(dl) diff --git a/synapse/federation/units.py b/synapse/federation/units.py index ecca35ac43..d97aeb698e 100644 --- a/synapse/federation/units.py +++ b/synapse/federation/units.py @@ -156,11 +156,15 @@ class Edu(JsonEncodedObject): ] required_keys = [ - "origin", - "destination", "edu_type", ] +# TODO: SYN-103: Remove "origin" and "destination" keys. +# internal_keys = [ +# "origin", +# "destination", +# ] + class Transaction(JsonEncodedObject): """ A transaction is a list of Pdus and Edus to be sent to a remote home diff --git a/tests/federation/test_federation.py b/tests/federation/test_federation.py index 8d277d6612..d86ce83b28 100644 --- a/tests/federation/test_federation.py +++ b/tests/federation/test_federation.py @@ -211,6 +211,7 @@ class FederationTestCase(unittest.TestCase): "pdus": [], "edus": [ { + # TODO: SYN-103: Remove "origin" and "destination" "origin": "test", "destination": "remote", "edu_type": "m.test", diff --git a/tests/handlers/test_presence.py b/tests/handlers/test_presence.py index 15022b8d05..84985a8066 100644 --- a/tests/handlers/test_presence.py +++ b/tests/handlers/test_presence.py @@ -43,6 +43,7 @@ def _expect_edu(destination, edu_type, content, origin="test"): "pdus": [], "edus": [ { + # TODO: SYN-103: Remove "origin" and "destination" keys. "origin": origin, "destination": destination, "edu_type": edu_type, diff --git a/tests/handlers/test_typing.py b/tests/handlers/test_typing.py index 064b04c217..b685373deb 100644 --- a/tests/handlers/test_typing.py +++ b/tests/handlers/test_typing.py @@ -33,6 +33,7 @@ def _expect_edu(destination, edu_type, content, origin="test"): "pdus": [], "edus": [ { + # TODO: SYN-103: Remove "origin" and "destination" keys. "origin": origin, "destination": destination, "edu_type": edu_type, From 13b560971e71a87bf44c35ae9cb4591333dd576c Mon Sep 17 00:00:00 2001 From: "Paul \"LeoNerd\" Evans" Date: Tue, 14 Oct 2014 16:47:08 +0100 Subject: [PATCH 092/106] Make sure to return an empty JSON object ({}) from presence PUT/POST requests rather than an empty string ("") because most deserialisers won't like the latter --- synapse/rest/presence.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/synapse/rest/presence.py b/synapse/rest/presence.py index 7fc8ce4404..138cc88a05 100644 --- a/synapse/rest/presence.py +++ b/synapse/rest/presence.py @@ -68,7 +68,7 @@ class PresenceStatusRestServlet(RestServlet): yield self.handlers.presence_handler.set_state( target_user=user, auth_user=auth_user, state=state) - defer.returnValue((200, "")) + defer.returnValue((200, {})) def on_OPTIONS(self, request): return (200, {}) @@ -141,7 +141,7 @@ class PresenceListRestServlet(RestServlet): yield defer.DeferredList(deferreds) - defer.returnValue((200, "")) + defer.returnValue((200, {})) def on_OPTIONS(self, request): return (200, {}) From f4667f86afe249be69ba5f2bbfe70a5a02f5b2f7 Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Wed, 15 Oct 2014 09:32:02 +0100 Subject: [PATCH 093/106] Add support for org.matrix.custom.text.html This format will remain undocumented as it is not yet suitable for introduction into the specification. --- webclient/components/matrix/event-handler-service.js | 1 + webclient/room/room.html | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/webclient/components/matrix/event-handler-service.js b/webclient/components/matrix/event-handler-service.js index e990d42d05..495c24ef59 100644 --- a/webclient/components/matrix/event-handler-service.js +++ b/webclient/components/matrix/event-handler-service.js @@ -460,6 +460,7 @@ function(matrixService, $rootScope, $q, $timeout, mPresence) { handleRoomAliases(event, isLiveEvent); break; case "m.room.message": + case "org.matrix.custom.text.html": handleMessage(event, isLiveEvent); break; case "m.room.member": diff --git a/webclient/room/room.html b/webclient/room/room.html index b99413cbbf..30277ab9fb 100644 --- a/webclient/room/room.html +++ b/webclient/room/room.html @@ -121,7 +121,8 @@ + ng-bind-html="(msg.content.msgtype === 'm.text' && msg.type === 'm.room.message') ? (msg.content.body | linky:'_blank') : + (msg.content.msgtype === 'm.text' && msg.type === 'org.matrix.custom.text.html') ? msg.content.body : '' "/> Outgoing Call{{ isWebRTCSupported ? '' : ' (But your browser does not support VoIP)' }} Incoming Call{{ isWebRTCSupported ? '' : ' (But your browser does not support VoIP)' }} From 07890b43ca739667b6974466739933ec2f2404e9 Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Wed, 15 Oct 2014 13:57:19 +0100 Subject: [PATCH 094/106] Remove org.matrix.custom.text.html event type and replace it with 'format' and 'formatted_body' keys on m.text messages --- webclient/components/matrix/event-handler-service.js | 1 - webclient/room/room.html | 4 ++-- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/webclient/components/matrix/event-handler-service.js b/webclient/components/matrix/event-handler-service.js index 495c24ef59..e990d42d05 100644 --- a/webclient/components/matrix/event-handler-service.js +++ b/webclient/components/matrix/event-handler-service.js @@ -460,7 +460,6 @@ function(matrixService, $rootScope, $q, $timeout, mPresence) { handleRoomAliases(event, isLiveEvent); break; case "m.room.message": - case "org.matrix.custom.text.html": handleMessage(event, isLiveEvent); break; case "m.room.member": diff --git a/webclient/room/room.html b/webclient/room/room.html index 30277ab9fb..479b4c9a05 100644 --- a/webclient/room/room.html +++ b/webclient/room/room.html @@ -121,8 +121,8 @@ + ng-bind-html="(msg.content.msgtype === 'm.text' && msg.type === 'm.room.message' && msg.content.format === 'org.matrix.custom.html') ? msg.content.formatted_body : + (msg.content.msgtype === 'm.text' && msg.type === 'm.room.message') ? (msg.content.body | linky:'_blank') : '' "/> Outgoing Call{{ isWebRTCSupported ? '' : ' (But your browser does not support VoIP)' }} Incoming Call{{ isWebRTCSupported ? '' : ' (But your browser does not support VoIP)' }} From da19fd0d1aa526a1136af4389feb8f862952329d Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Wed, 15 Oct 2014 14:42:14 +0100 Subject: [PATCH 095/106] Add unsanitizedLinky filter to fix links in formatted messages. This filter is identical to ngSanitize's linky but instead of sanitizing text which isn't linkified in the addText function, it doesn't. --- webclient/app-filter.js | 59 +++++++++++++++++++++++++++++++++++++--- webclient/room/room.html | 3 +- 2 files changed, 57 insertions(+), 5 deletions(-) diff --git a/webclient/app-filter.js b/webclient/app-filter.js index fc16492ef3..654783cb60 100644 --- a/webclient/app-filter.js +++ b/webclient/app-filter.js @@ -1,12 +1,12 @@ /* Copyright 2014 OpenMarket Ltd - + Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at - + http://www.apache.org/licenses/LICENSE-2.0 - + Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. @@ -80,4 +80,55 @@ angular.module('matrixWebClient') return function(text) { return $sce.trustAsHtml(text); }; -}]); \ No newline at end of file +}]) +// Exactly the same as ngSanitize's linky but instead of pushing sanitized +// text in the addText function, we just push the raw text. This is ONLY SAFE +// IF THIS IS USED IN CONJUNCTION WITH NG-BIND-HTML which sweeps with $sanitize +// already. +.filter('unsanitizedLinky', ['$sanitize', function($sanitize) { + var LINKY_URL_REGEXP = + /((ftp|https?):\/\/|(mailto:)?[A-Za-z0-9._%+-]+@)\S*[^\s.;,(){}<>"]/, + MAILTO_REGEXP = /^mailto:/; + + return function(text, target) { + if (!text) return text; + var match; + var raw = text; + var html = []; + var url; + var i; + while ((match = raw.match(LINKY_URL_REGEXP))) { + // We can not end in these as they are sometimes found at the end of the sentence + url = match[0]; + // if we did not match ftp/http/mailto then assume mailto + if (match[2] == match[3]) url = 'mailto:' + url; + i = match.index; + addText(raw.substr(0, i)); + addLink(url, match[0].replace(MAILTO_REGEXP, '')); + raw = raw.substring(i + match[0].length); + } + addText(raw); + return $sanitize(html.join('')); + + function addText(text) { + if (!text) { + return; + } + html.push(text); + } + + function addLink(url, text) { + html.push(''); + addText(text); + html.push(''); + } + }; +}]); diff --git a/webclient/room/room.html b/webclient/room/room.html index 479b4c9a05..79a60585a5 100644 --- a/webclient/room/room.html +++ b/webclient/room/room.html @@ -121,7 +121,8 @@ Outgoing Call{{ isWebRTCSupported ? '' : ' (But your browser does not support VoIP)' }} From 79bd6e77b8901b47539996c72d22b75d69585383 Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Wed, 15 Oct 2014 14:45:38 +0100 Subject: [PATCH 096/106] Remove warning since the end result is still $sanitize'd --- webclient/app-filter.js | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/webclient/app-filter.js b/webclient/app-filter.js index 654783cb60..39ea1d637d 100644 --- a/webclient/app-filter.js +++ b/webclient/app-filter.js @@ -82,9 +82,7 @@ angular.module('matrixWebClient') }; }]) // Exactly the same as ngSanitize's linky but instead of pushing sanitized -// text in the addText function, we just push the raw text. This is ONLY SAFE -// IF THIS IS USED IN CONJUNCTION WITH NG-BIND-HTML which sweeps with $sanitize -// already. +// text in the addText function, we just push the raw text. .filter('unsanitizedLinky', ['$sanitize', function($sanitize) { var LINKY_URL_REGEXP = /((ftp|https?):\/\/|(mailto:)?[A-Za-z0-9._%+-]+@)\S*[^\s.;,(){}<>"]/, From be2a9a8d1a1650f0963c9cfdba4608bdfb88fc66 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Fri, 17 Oct 2014 02:08:41 +0100 Subject: [PATCH 097/106] move gendoc into matrix-doc project --- scripts/basic.css | 510 --------------------------------------------- scripts/gendoc.sh | 14 -- scripts/nature.css | 270 ------------------------ 3 files changed, 794 deletions(-) delete mode 100644 scripts/basic.css delete mode 100755 scripts/gendoc.sh delete mode 100644 scripts/nature.css diff --git a/scripts/basic.css b/scripts/basic.css deleted file mode 100644 index 6411570ee6..0000000000 --- a/scripts/basic.css +++ /dev/null @@ -1,510 +0,0 @@ -/* - * basic.css - * ~~~~~~~~~ - * - * Sphinx stylesheet -- basic theme. - * - * :copyright: Copyright 2007-2010 by the Sphinx team, see AUTHORS. - * :license: BSD, see LICENSE for details. - * - */ - -/* -- main layout ----------------------------------------------------------- */ - -div.clearer { - clear: both; -} - -/* -- relbar ---------------------------------------------------------------- */ - -div.related { - width: 100%; - font-size: 90%; -} - -div.related h3 { - display: none; -} - -div.related ul { - margin: 0; - padding: 0 0 0 10px; - list-style: none; -} - -div.related li { - display: inline; -} - -div.related li.right { - float: right; - margin-right: 5px; -} - -/* -- sidebar --------------------------------------------------------------- */ - -div.sphinxsidebarwrapper { - padding: 10px 5px 0 10px; -} - -div.sphinxsidebar { - float: left; - width: 230px; - margin-left: -100%; - font-size: 90%; -} - -div.sphinxsidebar ul { - list-style: none; -} - -div.sphinxsidebar ul ul, -div.sphinxsidebar ul.want-points { - margin-left: 20px; - list-style: square; -} - -div.sphinxsidebar ul ul { - margin-top: 0; - margin-bottom: 0; -} - -div.sphinxsidebar form { - margin-top: 10px; -} - -div.sphinxsidebar input { - border: 1px solid #98dbcc; - font-family: sans-serif; - font-size: 1em; -} - -img { - border: 0; -} - -/* -- search page ----------------------------------------------------------- */ - -ul.search { - margin: 10px 0 0 20px; - padding: 0; -} - -ul.search li { - padding: 5px 0 5px 20px; - background-image: url(file.png); - background-repeat: no-repeat; - background-position: 0 7px; -} - -ul.search li a { - font-weight: bold; -} - -ul.search li div.context { - color: #888; - margin: 2px 0 0 30px; - text-align: left; -} - -ul.keywordmatches li.goodmatch a { - font-weight: bold; -} - -/* -- index page ------------------------------------------------------------ */ - -table.contentstable { - width: 90%; -} - -table.contentstable p.biglink { - line-height: 150%; -} - -a.biglink { - font-size: 1.3em; -} - -span.linkdescr { - font-style: italic; - padding-top: 5px; - font-size: 90%; -} - -/* -- general index --------------------------------------------------------- */ - -table.indextable { - width: 100%; -} - -table.indextable td { - text-align: left; - vertical-align: top; -} - -table.indextable dl, table.indextable dd { - margin-top: 0; - margin-bottom: 0; -} - -table.indextable tr.pcap { - height: 10px; -} - -table.indextable tr.cap { - margin-top: 10px; - background-color: #f2f2f2; -} - -img.toggler { - margin-right: 3px; - margin-top: 3px; - cursor: pointer; -} - -div.modindex-jumpbox { - border-top: 1px solid #ddd; - border-bottom: 1px solid #ddd; - margin: 1em 0 1em 0; - padding: 0.4em; -} - -div.genindex-jumpbox { - border-top: 1px solid #ddd; - border-bottom: 1px solid #ddd; - margin: 1em 0 1em 0; - padding: 0.4em; -} - -/* -- general body styles --------------------------------------------------- */ - -a.headerlink { - visibility: hidden; -} - -h1:hover > a.headerlink, -h2:hover > a.headerlink, -h3:hover > a.headerlink, -h4:hover > a.headerlink, -h5:hover > a.headerlink, -h6:hover > a.headerlink, -dt:hover > a.headerlink { - visibility: visible; -} - -div.document p.caption { - text-align: inherit; -} - -div.document td { - text-align: left; -} - -.field-list ul { - padding-left: 1em; -} - -.first { - margin-top: 0 !important; -} - -p.rubric { - margin-top: 30px; - font-weight: bold; -} - -.align-left { - text-align: left; -} - -.align-center { - clear: both; - text-align: center; -} - -.align-right { - text-align: right; -} - -/* -- sidebars -------------------------------------------------------------- */ - -div.sidebar { - margin: 0 0 0.5em 1em; - border: 1px solid #ddb; - padding: 7px 7px 0 7px; - background-color: #ffe; - width: 40%; - float: right; -} - -p.sidebar-title { - font-weight: bold; -} - -/* -- topics ---------------------------------------------------------------- */ - -div.topic { - border: 1px solid #ccc; - padding: 7px 7px 0 7px; - margin: 10px 0 10px 0; -} - -p.topic-title { - font-size: 1.1em; - font-weight: bold; - margin-top: 10px; -} - -/* -- admonitions ----------------------------------------------------------- */ - -div.admonition { - margin-top: 10px; - margin-bottom: 10px; - padding: 7px; -} - -div.admonition dt { - font-weight: bold; -} - -div.admonition dl { - margin-bottom: 0; -} - -p.admonition-title { - margin: 0px 10px 5px 0px; - font-weight: bold; -} - -div.document p.centered { - text-align: center; - margin-top: 25px; -} - -/* -- tables ---------------------------------------------------------------- */ - -table.docutils { - border: 0; - border-collapse: collapse; -} - -table.docutils td, table.docutils th { - padding: 1px 8px 1px 5px; - border-top: 0; - border-left: 0; - border-right: 0; - border-bottom: 1px solid #aaa; -} - -table.field-list td, table.field-list th { - border: 0 !important; -} - -table.footnote td, table.footnote th { - border: 0 !important; -} - -th { - text-align: left; - padding-right: 5px; -} - -table.citation { - border-left: solid 1px gray; - margin-left: 1px; -} - -table.citation td { - border-bottom: none; -} - -/* -- other body styles ----------------------------------------------------- */ - -ol.arabic { - list-style: decimal; -} - -ol.loweralpha { - list-style: lower-alpha; -} - -ol.upperalpha { - list-style: upper-alpha; -} - -ol.lowerroman { - list-style: lower-roman; -} - -ol.upperroman { - list-style: upper-roman; -} - -dl { - margin-bottom: 15px; -} - -dd p { - margin-top: 0px; -} - -dd ul, dd table { - margin-bottom: 10px; -} - -dd { - margin-top: 3px; - margin-bottom: 10px; - margin-left: 30px; -} - -dt:target, .highlighted { - background-color: #fbe54e; -} - -dl.glossary dt { - font-weight: bold; - font-size: 1.1em; -} - -.field-list ul { - margin: 0; - padding-left: 1em; -} - -.field-list p { - margin: 0; -} - -.refcount { - color: #060; -} - -.optional { - font-size: 1.3em; -} - -.versionmodified { - font-style: italic; -} - -.system-message { - background-color: #fda; - padding: 5px; - border: 3px solid red; -} - -.footnote:target { - background-color: #ffa -} - -.line-block { - display: block; - margin-top: 1em; - margin-bottom: 1em; -} - -.line-block .line-block { - margin-top: 0; - margin-bottom: 0; - margin-left: 1.5em; -} - -.guilabel, .menuselection { - font-family: sans-serif; -} - -.accelerator { - text-decoration: underline; -} - -.classifier { - font-style: oblique; -} - -/* -- code displays --------------------------------------------------------- */ - -pre { - overflow: auto; -} - -td.linenos pre { - padding: 5px 0px; - border: 0; - background-color: transparent; - color: #aaa; -} - -table.highlighttable { - margin-left: 0.5em; -} - -table.highlighttable td { - padding: 0 0.5em 0 0.5em; -} - -tt.descname { - background-color: transparent; - font-weight: bold; - font-size: 1.2em; -} - -tt.descclassname { - background-color: transparent; -} - -tt.xref, a tt { - background-color: transparent; - font-weight: bold; -} - -h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt { - background-color: transparent; -} - -.viewcode-link { - float: right; -} - -.viewcode-back { - float: right; - font-family: sans-serif; -} - -div.viewcode-block:target { - margin: -1px -10px; - padding: 0 10px; -} - -/* -- math display ---------------------------------------------------------- */ - -img.math { - vertical-align: middle; -} - -div.document div.math p { - text-align: center; -} - -span.eqno { - float: right; -} - -/* -- printout stylesheet --------------------------------------------------- */ - -@media print { - div.document, - div.documentwrapper, - div.bodywrapper { - margin: 0 !important; - width: 100%; - } - - div.sphinxsidebar, - div.related, - div.footer, - #top-link { - display: none; - } -} - diff --git a/scripts/gendoc.sh b/scripts/gendoc.sh deleted file mode 100755 index 64aff3155e..0000000000 --- a/scripts/gendoc.sh +++ /dev/null @@ -1,14 +0,0 @@ -#!/bin/bash - -MATRIXDOTORG=$HOME/workspace/matrix.org - -rst2html-2.7.py --stylesheet=basic.css,nature.css ../docs/specification.rst > $MATRIXDOTORG/docs/spec/index.html -rst2html-2.7.py --stylesheet=basic.css,nature.css ../docs/client-server/howto.rst > $MATRIXDOTORG/docs/howtos/client-server.html - -perl -pi -e 's###' $MATRIXDOTORG/docs/spec/index.html $MATRIXDOTORG/docs/howtos/client-server.html - -perl -pi -e 's##
[matrix]
#' $MATRIXDOTORG/docs/spec/index.html $MATRIXDOTORG/docs/howtos/client-server.html - -perl -pi -e 's##
#' $MATRIXDOTORG/docs/spec/index.html $MATRIXDOTORG/docs/howtos/client-server.html - -scp -r $MATRIXDOTORG/docs matrix@ldc-prd-matrix-001:/sites/matrix \ No newline at end of file diff --git a/scripts/nature.css b/scripts/nature.css deleted file mode 100644 index b8147f10ee..0000000000 --- a/scripts/nature.css +++ /dev/null @@ -1,270 +0,0 @@ -/* - * nature.css_t - * ~~~~~~~~~~~~ - * - * Sphinx stylesheet -- nature theme. - * - * :copyright: Copyright 2007-2010 by the Sphinx team, see AUTHORS. - * :license: BSD, see LICENSE for details. - * - */ - -/* -- page layout ----------------------------------------------------------- */ - -body { - font-family: Arial, sans-serif; - font-size: 100%; - /*background-color: #111;*/ - color: #555; - margin: 0; - padding: 0; -} - -div.documentwrapper { - float: left; - width: 100%; -} - -div.bodywrapper { - margin: 0 0 0 230px; -} - -hr { - border: 1px solid #B1B4B6; -} - -/* -div.document { - background-color: #eee; -} -*/ - -div.document { - background-color: #ffffff; - color: #3E4349; - padding: 0 30px 30px 30px; - font-size: 0.9em; -} - -div.footer { - color: #555; - width: 100%; - padding: 13px 0; - text-align: center; - font-size: 75%; -} - -div.footer a { - color: #444; - text-decoration: underline; -} - -div.related { - background-color: #6BA81E; - line-height: 32px; - color: #fff; - text-shadow: 0px 1px 0 #444; - font-size: 0.9em; -} - -div.related a { - color: #E2F3CC; -} - -div.sphinxsidebar { - font-size: 0.75em; - line-height: 1.5em; -} - -div.sphinxsidebarwrapper{ - padding: 20px 0; -} - -div.sphinxsidebar h3, -div.sphinxsidebar h4 { - font-family: Arial, sans-serif; - color: #222; - font-size: 1.2em; - font-weight: normal; - margin: 0; - padding: 5px 10px; - background-color: #ddd; - text-shadow: 1px 1px 0 white -} - -div.sphinxsidebar h4{ - font-size: 1.1em; -} - -div.sphinxsidebar h3 a { - color: #444; -} - - -div.sphinxsidebar p { - color: #888; - padding: 5px 20px; -} - -div.sphinxsidebar p.topless { -} - -div.sphinxsidebar ul { - margin: 10px 20px; - padding: 0; - color: #000; -} - -div.sphinxsidebar a { - color: #444; -} - -div.sphinxsidebar input { - border: 1px solid #ccc; - font-family: sans-serif; - font-size: 1em; -} - -div.sphinxsidebar input[type=text]{ - margin-left: 20px; -} - -/* -- body styles ----------------------------------------------------------- */ - -a { - color: #005B81; - text-decoration: none; -} - -a:hover { - color: #E32E00; - text-decoration: underline; -} - -div.document h1, -div.document h2, -div.document h3, -div.document h4, -div.document h5, -div.document h6 { - font-family: Arial, sans-serif; - background-color: #BED4EB; - font-weight: normal; - color: #212224; - margin: 30px 0px 10px 0px; - padding: 5px 0 5px 10px; - text-shadow: 0px 1px 0 white -} - -div.document h1 { border-top: 20px solid white; margin-top: 0; font-size: 200%; } -div.document h2 { font-size: 150%; background-color: #C8D5E3; } -div.document h3 { font-size: 120%; background-color: #D8DEE3; } -div.document h4 { font-size: 110%; background-color: #D8DEE3; } -div.document h5 { font-size: 100%; background-color: #D8DEE3; } -div.document h6 { font-size: 100%; background-color: #D8DEE3; } - -a.headerlink { - color: #c60f0f; - font-size: 0.8em; - padding: 0 4px 0 4px; - text-decoration: none; -} - -a.headerlink:hover { - background-color: #c60f0f; - color: white; -} - -div.document p, div.document dd, div.document li { - line-height: 1.5em; -} - -div.admonition p.admonition-title + p { - display: inline; -} - -div.highlight{ - background-color: white; -} - -div.note { - background-color: #eee; - border: 1px solid #ccc; -} - -div.seealso { - background-color: #ffc; - border: 1px solid #ff6; -} - -div.topic { - background-color: #eee; -} - -div.warning { - background-color: #ffe4e4; - border: 1px solid #f66; -} - -p.admonition-title { - display: inline; -} - -p.admonition-title:after { - content: ":"; -} - -pre { - padding: 10px; - background-color: White; - color: #222; - line-height: 1.2em; - border: 1px solid #C6C9CB; - font-size: 1.1em; - margin: 1.5em 0 1.5em 0; - -webkit-box-shadow: 1px 1px 1px #d8d8d8; - -moz-box-shadow: 1px 1px 1px #d8d8d8; -} - -tt { - background-color: #ecf0f3; - color: #222; - /* padding: 1px 2px; */ - font-size: 1.1em; - font-family: monospace; -} - -.viewcode-back { - font-family: Arial, sans-serif; -} - -div.viewcode-block:target { - background-color: #f4debf; - border-top: 1px solid #ac9; - border-bottom: 1px solid #ac9; -} - -p { - margin: 0; -} - -ul li dd { - margin-top: 0; -} - -ul li dl { - margin-bottom: 0; -} - -li dl dd { - margin-bottom: 0; -} - -dd ul { - padding-left: 0; -} - -li dd ul { - margin-bottom: 0; -} - From 456017e0ae6fb542d4cd3bc5977003d556b7bf65 Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Fri, 17 Oct 2014 16:55:05 +0100 Subject: [PATCH 098/106] SPEC-7: Don't stamp event contents with 'hsob_ts' --- synapse/handlers/message.py | 16 +++------------- 1 file changed, 3 insertions(+), 13 deletions(-) diff --git a/synapse/handlers/message.py b/synapse/handlers/message.py index 317ef2c80c..7b2b8549ed 100644 --- a/synapse/handlers/message.py +++ b/synapse/handlers/message.py @@ -64,7 +64,7 @@ class MessageHandler(BaseHandler): defer.returnValue(None) @defer.inlineCallbacks - def send_message(self, event=None, suppress_auth=False, stamp_event=True): + def send_message(self, event=None, suppress_auth=False): """ Send a message. Args: @@ -72,7 +72,6 @@ class MessageHandler(BaseHandler): suppress_auth (bool) : True to suppress auth for this message. This is primarily so the home server can inject messages into rooms at will. - stamp_event (bool) : True to stamp event content with server keys. Raises: SynapseError if something went wrong. """ @@ -82,9 +81,6 @@ class MessageHandler(BaseHandler): user = self.hs.parse_userid(event.user_id) assert user.is_mine, "User must be our own: %s" % (user,) - if stamp_event: - event.content["hsob_ts"] = int(self.clock.time_msec()) - snapshot = yield self.store.snapshot_room(event.room_id, event.user_id) if not suppress_auth: @@ -132,7 +128,7 @@ class MessageHandler(BaseHandler): defer.returnValue(chunk) @defer.inlineCallbacks - def store_room_data(self, event=None, stamp_event=True): + def store_room_data(self, event=None): """ Stores data for a room. Args: @@ -151,9 +147,6 @@ class MessageHandler(BaseHandler): yield self.auth.check(event, snapshot, raises=True) - if stamp_event: - event.content["hsob_ts"] = int(self.clock.time_msec()) - yield self.state_handler.handle_new_event(event, snapshot) yield self._on_new_room_event(event, snapshot) @@ -221,10 +214,7 @@ class MessageHandler(BaseHandler): defer.returnValue(None) @defer.inlineCallbacks - def send_feedback(self, event, stamp_event=True): - if stamp_event: - event.content["hsob_ts"] = int(self.clock.time_msec()) - + def send_feedback(self, event): snapshot = yield self.store.snapshot_room(event.room_id, event.user_id) yield self.auth.check(event, snapshot, raises=True) From f5cf7ac25b311fda8a2d553f07437b3648c66f6c Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Fri, 17 Oct 2014 17:12:25 +0100 Subject: [PATCH 099/106] SPEC-7: Rename 'ts' to 'origin_server_ts' --- synapse/api/events/factory.py | 4 ++-- synapse/federation/pdu_codec.py | 4 ++-- synapse/federation/persistence.py | 2 +- synapse/federation/replication.py | 4 ++-- synapse/federation/units.py | 16 ++++++++-------- synapse/storage/_base.py | 2 +- synapse/storage/pdu.py | 2 +- synapse/storage/schema/pdu.sql | 2 +- synapse/storage/schema/transactions.sql | 4 ++-- synapse/storage/transactions.py | 14 +++++++------- tests/federation/test_federation.py | 14 +++++++------- tests/federation/test_pdu_codec.py | 4 ++-- tests/handlers/test_federation.py | 6 +++--- tests/handlers/test_presence.py | 2 +- tests/handlers/test_typing.py | 2 +- tests/test_state.py | 2 +- 16 files changed, 42 insertions(+), 42 deletions(-) diff --git a/synapse/api/events/factory.py b/synapse/api/events/factory.py index 0d94850cec..74d0ef77f4 100644 --- a/synapse/api/events/factory.py +++ b/synapse/api/events/factory.py @@ -58,8 +58,8 @@ class EventFactory(object): random_string(10), self.hs.hostname ) - if "ts" not in kwargs: - kwargs["ts"] = int(self.clock.time_msec()) + if "origin_server_ts" not in kwargs: + kwargs["origin_server_ts"] = int(self.clock.time_msec()) # The "age" key is a delta timestamp that should be converted into an # absolute timestamp the minute we see it. diff --git a/synapse/federation/pdu_codec.py b/synapse/federation/pdu_codec.py index cef61108dd..e8180d94fd 100644 --- a/synapse/federation/pdu_codec.py +++ b/synapse/federation/pdu_codec.py @@ -96,7 +96,7 @@ class PduCodec(object): if k not in ["event_id", "room_id", "type", "prev_events"] }) - if "ts" not in kwargs: - kwargs["ts"] = int(self.clock.time_msec()) + if "origin_server_ts" not in kwargs: + kwargs["origin_server_ts"] = int(self.clock.time_msec()) return Pdu(**kwargs) diff --git a/synapse/federation/persistence.py b/synapse/federation/persistence.py index de36a80e41..7043fcc504 100644 --- a/synapse/federation/persistence.py +++ b/synapse/federation/persistence.py @@ -157,7 +157,7 @@ class TransactionActions(object): transaction.prev_ids = yield self.store.prep_send_transaction( transaction.transaction_id, transaction.destination, - transaction.ts, + transaction.origin_server_ts, [(p["pdu_id"], p["origin"]) for p in transaction.pdus] ) diff --git a/synapse/federation/replication.py b/synapse/federation/replication.py index 9363ac7300..092411eaf9 100644 --- a/synapse/federation/replication.py +++ b/synapse/federation/replication.py @@ -421,7 +421,7 @@ class ReplicationLayer(object): return Transaction( origin=self.server_name, pdus=pdus, - ts=int(self._clock.time_msec()), + origin_server_ts=int(self._clock.time_msec()), destination=None, ) @@ -589,7 +589,7 @@ class _TransactionQueue(object): logger.debug("TX [%s] Persisting transaction...", destination) transaction = Transaction.create_new( - ts=self._clock.time_msec(), + origin_server_ts=self._clock.time_msec(), transaction_id=str(self._next_txn_id), origin=self.server_name, destination=destination, diff --git a/synapse/federation/units.py b/synapse/federation/units.py index d97aeb698e..dccac2aca7 100644 --- a/synapse/federation/units.py +++ b/synapse/federation/units.py @@ -40,7 +40,7 @@ class Pdu(JsonEncodedObject): { "pdu_id": "78c", - "ts": 1404835423000, + "origin_server_ts": 1404835423000, "origin": "bar", "prev_ids": [ ["23b", "foo"], @@ -55,7 +55,7 @@ class Pdu(JsonEncodedObject): "pdu_id", "context", "origin", - "ts", + "origin_server_ts", "pdu_type", "destinations", "transaction_id", @@ -82,7 +82,7 @@ class Pdu(JsonEncodedObject): "pdu_id", "context", "origin", - "ts", + "origin_server_ts", "pdu_type", "content", ] @@ -186,7 +186,7 @@ class Transaction(JsonEncodedObject): "transaction_id", "origin", "destination", - "ts", + "origin_server_ts", "previous_ids", "pdus", "edus", @@ -203,7 +203,7 @@ class Transaction(JsonEncodedObject): "transaction_id", "origin", "destination", - "ts", + "origin_server_ts", "pdus", ] @@ -225,10 +225,10 @@ class Transaction(JsonEncodedObject): @staticmethod def create_new(pdus, **kwargs): """ Used to create a new transaction. Will auto fill out - transaction_id and ts keys. + transaction_id and origin_server_ts keys. """ - if "ts" not in kwargs: - raise KeyError("Require 'ts' to construct a Transaction") + if "origin_server_ts" not in kwargs: + raise KeyError("Require 'origin_server_ts' to construct a Transaction") if "transaction_id" not in kwargs: raise KeyError( "Require 'transaction_id' to construct a Transaction" diff --git a/synapse/storage/_base.py b/synapse/storage/_base.py index dba50f1213..30c5103cdd 100644 --- a/synapse/storage/_base.py +++ b/synapse/storage/_base.py @@ -361,7 +361,7 @@ class SQLBaseStore(object): if "age_ts" not in d: # For compatibility - d["age_ts"] = d["ts"] if "ts" in d else 0 + d["age_ts"] = d["origin_server_ts"] if "origin_server_ts" in d else 0 return self.event_factory.create_event( etype=d["type"], diff --git a/synapse/storage/pdu.py b/synapse/storage/pdu.py index d70467dcd6..61ea979b8a 100644 --- a/synapse/storage/pdu.py +++ b/synapse/storage/pdu.py @@ -789,7 +789,7 @@ class PdusTable(Table): "origin", "context", "pdu_type", - "ts", + "origin_server_ts", "depth", "is_state", "content_json", diff --git a/synapse/storage/schema/pdu.sql b/synapse/storage/schema/pdu.sql index 16e111a56c..5cc8669912 100644 --- a/synapse/storage/schema/pdu.sql +++ b/synapse/storage/schema/pdu.sql @@ -18,7 +18,7 @@ CREATE TABLE IF NOT EXISTS pdus( origin TEXT, context TEXT, pdu_type TEXT, - ts INTEGER, + origin_server_ts INTEGER, depth INTEGER DEFAULT 0 NOT NULL, is_state BOOL, content_json TEXT, diff --git a/synapse/storage/schema/transactions.sql b/synapse/storage/schema/transactions.sql index 88e3e4e04d..5f8d01327a 100644 --- a/synapse/storage/schema/transactions.sql +++ b/synapse/storage/schema/transactions.sql @@ -16,7 +16,7 @@ CREATE TABLE IF NOT EXISTS received_transactions( transaction_id TEXT, origin TEXT, - ts INTEGER, + origin_server_ts INTEGER, response_code INTEGER, response_json TEXT, has_been_referenced BOOL default 0, -- Whether thishas been referenced by a prev_tx @@ -35,7 +35,7 @@ CREATE TABLE IF NOT EXISTS sent_transactions( destination TEXT, response_code INTEGER DEFAULT 0, response_json TEXT, - ts INTEGER + origin_server_ts INTEGER ); CREATE INDEX IF NOT EXISTS sent_transaction_dest ON sent_transactions(destination); diff --git a/synapse/storage/transactions.py b/synapse/storage/transactions.py index ab4599b468..a9fa959d49 100644 --- a/synapse/storage/transactions.py +++ b/synapse/storage/transactions.py @@ -87,7 +87,7 @@ class TransactionStore(SQLBaseStore): txn.execute(query, (code, response_json, transaction_id, origin)) - def prep_send_transaction(self, transaction_id, destination, ts, pdu_list): + def prep_send_transaction(self, transaction_id, destination, origin_server_ts, pdu_list): """Persists an outgoing transaction and calculates the values for the previous transaction id list. @@ -97,7 +97,7 @@ class TransactionStore(SQLBaseStore): Args: transaction_id (str) destination (str) - ts (int) + origin_server_ts (int) pdu_list (list) Returns: @@ -106,10 +106,10 @@ class TransactionStore(SQLBaseStore): return self.runInteraction( self._prep_send_transaction, - transaction_id, destination, ts, pdu_list + transaction_id, destination, origin_server_ts, pdu_list ) - def _prep_send_transaction(self, txn, transaction_id, destination, ts, + def _prep_send_transaction(self, txn, transaction_id, destination, origin_server_ts, pdu_list): # First we find out what the prev_txs should be. @@ -131,7 +131,7 @@ class TransactionStore(SQLBaseStore): None, transaction_id=transaction_id, destination=destination, - ts=ts, + origin_server_ts=origin_server_ts, response_code=0, response_json=None )) @@ -251,7 +251,7 @@ class ReceivedTransactionsTable(Table): fields = [ "transaction_id", "origin", - "ts", + "origin_server_ts", "response_code", "response_json", "has_been_referenced", @@ -267,7 +267,7 @@ class SentTransactions(Table): "id", "transaction_id", "destination", - "ts", + "origin_server_ts", "response_code", "response_json", ] diff --git a/tests/federation/test_federation.py b/tests/federation/test_federation.py index d86ce83b28..8b1202f6e4 100644 --- a/tests/federation/test_federation.py +++ b/tests/federation/test_federation.py @@ -99,7 +99,7 @@ class FederationTestCase(unittest.TestCase): origin="red", context="my-context", pdu_type="m.topic", - ts=123456789000, + origin_server_ts=123456789000, depth=1, is_state=True, content_json='{"topic":"The topic"}', @@ -134,7 +134,7 @@ class FederationTestCase(unittest.TestCase): origin="red", context="my-context", pdu_type="m.text", - ts=123456789001, + origin_server_ts=123456789001, depth=1, content_json='{"text":"Here is the message"}', ) @@ -158,7 +158,7 @@ class FederationTestCase(unittest.TestCase): origin="red", destinations=["remote"], context="my-context", - ts=123456789002, + origin_server_ts=123456789002, pdu_type="m.test", content={"testing": "content here"}, depth=1, @@ -170,14 +170,14 @@ class FederationTestCase(unittest.TestCase): "remote", path="/_matrix/federation/v1/send/1000000/", data={ - "ts": 1000000, + "origin_server_ts": 1000000, "origin": "test", "pdus": [ { "origin": "red", "pdu_id": "abc123def456", "prev_pdus": [], - "ts": 123456789002, + "origin_server_ts": 123456789002, "context": "my-context", "pdu_type": "m.test", "is_state": False, @@ -207,7 +207,7 @@ class FederationTestCase(unittest.TestCase): path="/_matrix/federation/v1/send/1000000/", data={ "origin": "test", - "ts": 1000000, + "origin_server_ts": 1000000, "pdus": [], "edus": [ { @@ -234,7 +234,7 @@ class FederationTestCase(unittest.TestCase): "/_matrix/federation/v1/send/1001000/", """{ "origin": "remote", - "ts": 1001000, + "origin_server_ts": 1001000, "pdus": [], "edus": [ { diff --git a/tests/federation/test_pdu_codec.py b/tests/federation/test_pdu_codec.py index 344e1baf60..0754ef92e8 100644 --- a/tests/federation/test_pdu_codec.py +++ b/tests/federation/test_pdu_codec.py @@ -68,7 +68,7 @@ class PduCodecTestCase(unittest.TestCase): context="rooooom", pdu_type="m.room.message", origin="bar.com", - ts=12345, + origin_server_ts=12345, depth=5, prev_pdus=[("alice", "bob.com")], is_state=False, @@ -123,7 +123,7 @@ class PduCodecTestCase(unittest.TestCase): context="rooooom", pdu_type="m.room.topic", origin="bar.com", - ts=12345, + origin_server_ts=12345, depth=5, prev_pdus=[("alice", "bob.com")], is_state=True, diff --git a/tests/handlers/test_federation.py b/tests/handlers/test_federation.py index 35c3a4df7b..219b2c4c5e 100644 --- a/tests/handlers/test_federation.py +++ b/tests/handlers/test_federation.py @@ -68,7 +68,7 @@ class FederationTestCase(unittest.TestCase): pdu_type=MessageEvent.TYPE, context="foo", content={"msgtype": u"fooo"}, - ts=0, + origin_server_ts=0, pdu_id="a", origin="b", ) @@ -95,7 +95,7 @@ class FederationTestCase(unittest.TestCase): target_host=self.hostname, context=room_id, content={}, - ts=0, + origin_server_ts=0, pdu_id="a", origin="b", ) @@ -127,7 +127,7 @@ class FederationTestCase(unittest.TestCase): state_key="@red:not%s" % self.hostname, context=room_id, content={}, - ts=0, + origin_server_ts=0, pdu_id="a", origin="b", ) diff --git a/tests/handlers/test_presence.py b/tests/handlers/test_presence.py index 84985a8066..1850deacf5 100644 --- a/tests/handlers/test_presence.py +++ b/tests/handlers/test_presence.py @@ -39,7 +39,7 @@ ONLINE = PresenceState.ONLINE def _expect_edu(destination, edu_type, content, origin="test"): return { "origin": origin, - "ts": 1000000, + "origin_server_ts": 1000000, "pdus": [], "edus": [ { diff --git a/tests/handlers/test_typing.py b/tests/handlers/test_typing.py index b685373deb..f1d3b27f74 100644 --- a/tests/handlers/test_typing.py +++ b/tests/handlers/test_typing.py @@ -29,7 +29,7 @@ from synapse.handlers.typing import TypingNotificationHandler def _expect_edu(destination, edu_type, content, origin="test"): return { "origin": origin, - "ts": 1000000, + "origin_server_ts": 1000000, "pdus": [], "edus": [ { diff --git a/tests/test_state.py b/tests/test_state.py index b1624f0b25..4b1feaf410 100644 --- a/tests/test_state.py +++ b/tests/test_state.py @@ -599,7 +599,7 @@ def new_fake_pdu(pdu_id, context, pdu_type, state_key, prev_state_id, prev_state_id=prev_state_id, origin="example.com", context="context", - ts=1405353060021, + origin_server_ts=1405353060021, depth=depth, content_json="{}", unrecognized_keys="{}", From 82c582076782f180c9f69a523953c3a36b57b3ac Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Fri, 17 Oct 2014 17:31:48 +0100 Subject: [PATCH 100/106] keep 'origin_server_ts' as 'ts' in the database to avoid needlessly updating schema --- synapse/federation/units.py | 1 + synapse/storage/__init__.py | 2 ++ synapse/storage/_base.py | 3 ++- synapse/storage/pdu.py | 2 +- synapse/storage/schema/pdu.sql | 2 +- synapse/storage/schema/transactions.sql | 4 ++-- synapse/storage/transactions.py | 13 +++++++------ tests/federation/test_federation.py | 4 ++-- 8 files changed, 18 insertions(+), 13 deletions(-) diff --git a/synapse/federation/units.py b/synapse/federation/units.py index dccac2aca7..b2fb964180 100644 --- a/synapse/federation/units.py +++ b/synapse/federation/units.py @@ -118,6 +118,7 @@ class Pdu(JsonEncodedObject): """ if pdu_tuple: d = copy.copy(pdu_tuple.pdu_entry._asdict()) + d["origin_server_ts"] = d.pop("ts") d["content"] = json.loads(d["content_json"]) del d["content_json"] diff --git a/synapse/storage/__init__.py b/synapse/storage/__init__.py index 6dadeb8cce..c8e0efb18f 100644 --- a/synapse/storage/__init__.py +++ b/synapse/storage/__init__.py @@ -155,6 +155,8 @@ class DataStore(RoomMemberStore, RoomStore, cols["unrecognized_keys"] = json.dumps(unrec_keys) + cols["ts"] = cols.pop("origin_server_ts") + logger.debug("Persisting: %s", repr(cols)) if pdu.is_state: diff --git a/synapse/storage/_base.py b/synapse/storage/_base.py index 30c5103cdd..65a86e9056 100644 --- a/synapse/storage/_base.py +++ b/synapse/storage/_base.py @@ -354,6 +354,7 @@ class SQLBaseStore(object): d.pop("stream_ordering", None) d.pop("topological_ordering", None) d.pop("processed", None) + d["origin_server_ts"] = d.pop("ts", 0) d.update(json.loads(row_dict["unrecognized_keys"])) d["content"] = json.loads(d["content"]) @@ -361,7 +362,7 @@ class SQLBaseStore(object): if "age_ts" not in d: # For compatibility - d["age_ts"] = d["origin_server_ts"] if "origin_server_ts" in d else 0 + d["age_ts"] = d.get("origin_server_ts", 0) return self.event_factory.create_event( etype=d["type"], diff --git a/synapse/storage/pdu.py b/synapse/storage/pdu.py index 61ea979b8a..d70467dcd6 100644 --- a/synapse/storage/pdu.py +++ b/synapse/storage/pdu.py @@ -789,7 +789,7 @@ class PdusTable(Table): "origin", "context", "pdu_type", - "origin_server_ts", + "ts", "depth", "is_state", "content_json", diff --git a/synapse/storage/schema/pdu.sql b/synapse/storage/schema/pdu.sql index 5cc8669912..16e111a56c 100644 --- a/synapse/storage/schema/pdu.sql +++ b/synapse/storage/schema/pdu.sql @@ -18,7 +18,7 @@ CREATE TABLE IF NOT EXISTS pdus( origin TEXT, context TEXT, pdu_type TEXT, - origin_server_ts INTEGER, + ts INTEGER, depth INTEGER DEFAULT 0 NOT NULL, is_state BOOL, content_json TEXT, diff --git a/synapse/storage/schema/transactions.sql b/synapse/storage/schema/transactions.sql index 5f8d01327a..88e3e4e04d 100644 --- a/synapse/storage/schema/transactions.sql +++ b/synapse/storage/schema/transactions.sql @@ -16,7 +16,7 @@ CREATE TABLE IF NOT EXISTS received_transactions( transaction_id TEXT, origin TEXT, - origin_server_ts INTEGER, + ts INTEGER, response_code INTEGER, response_json TEXT, has_been_referenced BOOL default 0, -- Whether thishas been referenced by a prev_tx @@ -35,7 +35,7 @@ CREATE TABLE IF NOT EXISTS sent_transactions( destination TEXT, response_code INTEGER DEFAULT 0, response_json TEXT, - origin_server_ts INTEGER + ts INTEGER ); CREATE INDEX IF NOT EXISTS sent_transaction_dest ON sent_transactions(destination); diff --git a/synapse/storage/transactions.py b/synapse/storage/transactions.py index a9fa959d49..2ba8e30efe 100644 --- a/synapse/storage/transactions.py +++ b/synapse/storage/transactions.py @@ -87,7 +87,8 @@ class TransactionStore(SQLBaseStore): txn.execute(query, (code, response_json, transaction_id, origin)) - def prep_send_transaction(self, transaction_id, destination, origin_server_ts, pdu_list): + def prep_send_transaction(self, transaction_id, destination, + origin_server_ts, pdu_list): """Persists an outgoing transaction and calculates the values for the previous transaction id list. @@ -109,8 +110,8 @@ class TransactionStore(SQLBaseStore): transaction_id, destination, origin_server_ts, pdu_list ) - def _prep_send_transaction(self, txn, transaction_id, destination, origin_server_ts, - pdu_list): + def _prep_send_transaction(self, txn, transaction_id, destination, + origin_server_ts, pdu_list): # First we find out what the prev_txs should be. # Since we know that we are only sending one transaction at a time, @@ -131,7 +132,7 @@ class TransactionStore(SQLBaseStore): None, transaction_id=transaction_id, destination=destination, - origin_server_ts=origin_server_ts, + ts=origin_server_ts, response_code=0, response_json=None )) @@ -251,7 +252,7 @@ class ReceivedTransactionsTable(Table): fields = [ "transaction_id", "origin", - "origin_server_ts", + "ts", "response_code", "response_json", "has_been_referenced", @@ -267,7 +268,7 @@ class SentTransactions(Table): "id", "transaction_id", "destination", - "origin_server_ts", + "ts", "response_code", "response_json", ] diff --git a/tests/federation/test_federation.py b/tests/federation/test_federation.py index 8b1202f6e4..933aa61c77 100644 --- a/tests/federation/test_federation.py +++ b/tests/federation/test_federation.py @@ -99,7 +99,7 @@ class FederationTestCase(unittest.TestCase): origin="red", context="my-context", pdu_type="m.topic", - origin_server_ts=123456789000, + ts=123456789000, depth=1, is_state=True, content_json='{"topic":"The topic"}', @@ -134,7 +134,7 @@ class FederationTestCase(unittest.TestCase): origin="red", context="my-context", pdu_type="m.text", - origin_server_ts=123456789001, + ts=123456789001, depth=1, content_json='{"text":"Here is the message"}', ) From 5662be894e517c0424dcc59127d0c62776510ee7 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Fri, 17 Oct 2014 20:26:18 +0100 Subject: [PATCH 101/106] Bump database version number. --- synapse/storage/__init__.py | 2 +- synapse/storage/schema/delta/v6.sql | 31 +++++++++++++++++++++++++++++ 2 files changed, 32 insertions(+), 1 deletion(-) create mode 100644 synapse/storage/schema/delta/v6.sql diff --git a/synapse/storage/__init__.py b/synapse/storage/__init__.py index c8e0efb18f..3aa6345a7f 100644 --- a/synapse/storage/__init__.py +++ b/synapse/storage/__init__.py @@ -64,7 +64,7 @@ SCHEMAS = [ # Remember to update this number every time an incompatible change is made to # database schema files, so the users will be informed on server restarts. -SCHEMA_VERSION = 5 +SCHEMA_VERSION = 6 class _RollbackButIsFineException(Exception): diff --git a/synapse/storage/schema/delta/v6.sql b/synapse/storage/schema/delta/v6.sql new file mode 100644 index 0000000000..9bf2068d84 --- /dev/null +++ b/synapse/storage/schema/delta/v6.sql @@ -0,0 +1,31 @@ +/* Copyright 2014 OpenMarket Ltd + * + * Licensed under the Apache License, Version 2.0 (the "License"); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +CREATE TABLE IF NOT EXISTS server_tls_certificates( + server_name TEXT, -- Server name. + fingerprint TEXT, -- Certificate fingerprint. + from_server TEXT, -- Which key server the certificate was fetched from. + ts_added_ms INTEGER, -- When the certifcate was added. + tls_certificate BLOB, -- DER encoded x509 certificate. + CONSTRAINT uniqueness UNIQUE (server_name, fingerprint) +); + +CREATE TABLE IF NOT EXISTS server_signature_keys( + server_name TEXT, -- Server name. + key_id TEXT, -- Key version. + from_server TEXT, -- Which key server the key was fetched form. + ts_added_ms INTEGER, -- When the key was added. + verify_key BLOB, -- NACL verification key. + CONSTRAINT uniqueness UNIQUE (server_name, key_id) +); From 71e6a94af76dbaea592b66c2c065f19f9ef57cb0 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Fri, 17 Oct 2014 20:26:26 +0100 Subject: [PATCH 102/106] Bump version and changelog --- CHANGES.rst | 13 ++++++++++--- UPGRADE.rst | 5 ----- VERSION | 2 +- synapse/__init__.py | 2 +- 4 files changed, 12 insertions(+), 10 deletions(-) diff --git a/CHANGES.rst b/CHANGES.rst index 5b05900daf..dab9285f3b 100644 --- a/CHANGES.rst +++ b/CHANGES.rst @@ -1,6 +1,13 @@ -Changes in latest -================= -This breaks federation becuase of signing +Changes in synpase 0.4.0 (2014-10-17) +===================================== +This server includes changes to the federation protocol that is not backwards +compatible. + +The Matrix specification has been moved to a seperate git repository. + +Homeserver: + * Sign federation transactions. + * Rename timestamp keys in PDUs. Changes in synapse 0.3.4 (2014-09-25) ===================================== diff --git a/UPGRADE.rst b/UPGRADE.rst index 2ae9254ecf..713fb9ae83 100644 --- a/UPGRADE.rst +++ b/UPGRADE.rst @@ -1,8 +1,3 @@ -Upgrading to latest -=================== -This breaks federation between old and new servers due to signing of -transactions. - Upgrading to v0.3.0 =================== diff --git a/VERSION b/VERSION index 42045acae2..1d0ba9ea18 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -0.3.4 +0.4.0 diff --git a/synapse/__init__.py b/synapse/__init__.py index a340a5db66..979eac08a7 100644 --- a/synapse/__init__.py +++ b/synapse/__init__.py @@ -16,4 +16,4 @@ """ This is a reference implementation of a synapse home server. """ -__version__ = "0.3.4" +__version__ = "0.4.0" From 5356044b77f0c080c67e7825515a87acc133bf0c Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Fri, 17 Oct 2014 20:35:28 +0100 Subject: [PATCH 103/106] Bump syutil dependency --- setup.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/setup.py b/setup.py index a9470b4c9e..7a7e53af39 100755 --- a/setup.py +++ b/setup.py @@ -31,7 +31,7 @@ setup( packages=find_packages(exclude=["tests"]), description="Reference Synapse Home Server", install_requires=[ - "syutil==0.0.1", + "syutil==0.0.2", "Twisted>=14.0.0", "service_identity>=1.0.0", "pyyaml", @@ -41,7 +41,7 @@ setup( "py-bcrypt", ], dependency_links=[ - "git+ssh://git@github.com/matrix-org/syutil.git#egg=syutil-0.0.1", + "git+ssh://git@github.com/matrix-org/syutil.git#egg=syutil-0.0.2", ], setup_requires=[ "setuptools_trial", From 3187b5ba2db51dc4bac0d20a67f0b6193b45e8cb Mon Sep 17 00:00:00 2001 From: Mark Haines Date: Fri, 17 Oct 2014 20:56:21 +0100 Subject: [PATCH 104/106] add log line for checking verifying signatures --- synapse/crypto/keyring.py | 1 + 1 file changed, 1 insertion(+) diff --git a/synapse/crypto/keyring.py b/synapse/crypto/keyring.py index 015f76ebe3..2440d604c3 100644 --- a/synapse/crypto/keyring.py +++ b/synapse/crypto/keyring.py @@ -38,6 +38,7 @@ class Keyring(object): @defer.inlineCallbacks def verify_json_for_server(self, server_name, json_object): + logger.debug("Verifying for %s", server_name) key_ids = signature_ids(json_object, server_name) if not key_ids: raise SynapseError( From cd198dfea8083132137f6c4df5129fd7bb5f7a1e Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Fri, 17 Oct 2014 20:58:47 +0100 Subject: [PATCH 105/106] More log lines. --- synapse/federation/transport.py | 22 +++++++++++++++------- 1 file changed, 15 insertions(+), 7 deletions(-) diff --git a/synapse/federation/transport.py b/synapse/federation/transport.py index 755eee8cf6..81529baee6 100644 --- a/synapse/federation/transport.py +++ b/synapse/federation/transport.py @@ -256,10 +256,14 @@ class TransportLayer(object): def _with_authentication(self, handler): @defer.inlineCallbacks def new_handler(request, *args, **kwargs): - (origin, content) = yield self._authenticate_request(request) - response = yield handler( - origin, content, request.args, *args, **kwargs - ) + try: + (origin, content) = yield self._authenticate_request(request) + response = yield handler( + origin, content, request.args, *args, **kwargs + ) + except: + logger.exception("_authenticate_request failed") + raise defer.returnValue(response) return new_handler @@ -392,9 +396,13 @@ class TransportLayer(object): defer.returnValue((400, {"error": "Invalid transaction"})) return - code, response = yield self.received_handler.on_incoming_transaction( - transaction_data - ) + try: + code, response = yield self.received_handler.on_incoming_transaction( + transaction_data + ) + except: + logger.exception("on_incoming_transaction failed") + raise defer.returnValue((code, response)) From ac9345b47a7c963850369e0a8ad63ed6aaba0795 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Fri, 17 Oct 2014 21:00:58 +0100 Subject: [PATCH 106/106] Check that we have auth headers and fail nicely --- synapse/federation/transport.py | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/synapse/federation/transport.py b/synapse/federation/transport.py index 81529baee6..e7517cac4d 100644 --- a/synapse/federation/transport.py +++ b/synapse/federation/transport.py @@ -238,6 +238,11 @@ class TransportLayer(object): auth_headers = request.requestHeaders.getRawHeaders(b"Authorization") + if not auth_headers: + raise SynapseError( + 401, "Missing Authorization headers", Codes.UNAUTHORIZED, + ) + for auth in auth_headers: if auth.startswith("X-Matrix"): (origin, key, sig) = parse_auth_header(auth)