From 5b5b4cfbed2941e342dc06678d39bf00ec50d0f7 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Fri, 17 Aug 2018 13:38:38 -0600 Subject: [PATCH 1/4] Explicitly say how appservices should detect state events Fixes https://github.com/matrix-org/matrix-doc/issues/1014 --- api/application-service/application_service.yaml | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/api/application-service/application_service.yaml b/api/application-service/application_service.yaml index 42c0c0cf..64064cbd 100644 --- a/api/application-service/application_service.yaml +++ b/api/application-service/application_service.yaml @@ -32,6 +32,10 @@ paths: description: |- This API is called by the homeserver when it wants to push an event (or batch of events) to the application service. + + The application service should take care to ensure that it handles + state events by the presence of a ``state_key``, not by the event + type. operationId: sendTransaction parameters: - in: path @@ -44,7 +48,7 @@ paths: x-example: "35" - in: body name: body - description: A list of events + description: A list of events. schema: type: object example: { From fd101b6ac967e692e24183942f5651e4bf451a76 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Fri, 17 Aug 2018 13:39:17 -0600 Subject: [PATCH 2/4] Misc language changes --- specification/application_service_api.rst | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/specification/application_service_api.rst b/specification/application_service_api.rst index b4950eac..3666df33 100644 --- a/specification/application_service_api.rst +++ b/specification/application_service_api.rst @@ -1,4 +1,5 @@ .. Copyright 2016 OpenMarket Ltd +.. Copyright 2018 New Vector Ltd .. .. Licensed under the Apache License, Version 2.0 (the "License"); .. you may not use this file except in compliance with the License. @@ -39,7 +40,7 @@ This version of the specification is generated from Application Services -------------------- Application services are passive and can only observe events from a given -homeserver. They can inject events into rooms they are participating in. +homeserver (HS). They can inject events into rooms they are participating in. They cannot prevent events from being sent, nor can they modify the content of the event being sent. In order to observe events from a homeserver, the homeserver needs to be configured to pass certain types of traffic to the @@ -217,7 +218,8 @@ need to be able to adjust the ``origin_server_ts`` value to do this. Inputs: - Application service token (``as_token``) - - Desired timestamp + - Desired timestamp in milliseconds since the unix epoch + Notes: - This will only apply when sending events. From 7caad61b86adc8ba44b9711a3f6aa91e46ec392e Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Fri, 17 Aug 2018 13:40:05 -0600 Subject: [PATCH 3/4] Clearly state how the users namespace relates to interest in events Fixes https://github.com/matrix-org/matrix-doc/issues/1307 --- specification/application_service_api.rst | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/specification/application_service_api.rst b/specification/application_service_api.rst index 3666df33..5fe0aede 100644 --- a/specification/application_service_api.rst +++ b/specification/application_service_api.rst @@ -69,7 +69,13 @@ Registration Application services register "namespaces" of user IDs, room aliases and room IDs. These namespaces are represented as regular expressions. An application service is said to be "interested" in a given event if one of the IDs in the event match -the regular expression provided by the application service. An application +the regular expression provided by the application service, such as the room having +an alias or ID in the relevant namespaces. Similarly, the application service is +said to be interested in a given event if one of the application service's namespaced +users is the target of the event, or is a joined member of the room where the event +occurred. + +An application service can also state whether they should be the only ones who can manage a specified namespace. This is referred to as an "exclusive" namespace. An exclusive namespace prevents humans and other application From c8ba2e098c5ec847c6799d37fa0476ff0867dc2c Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Mon, 20 Aug 2018 12:09:17 -0600 Subject: [PATCH 4/4] Wording improvements for appservices --- api/application-service/application_service.yaml | 6 +++--- specification/application_service_api.rst | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/api/application-service/application_service.yaml b/api/application-service/application_service.yaml index 64064cbd..d8f43ed6 100644 --- a/api/application-service/application_service.yaml +++ b/api/application-service/application_service.yaml @@ -33,9 +33,9 @@ paths: This API is called by the homeserver when it wants to push an event (or batch of events) to the application service. - The application service should take care to ensure that it handles - state events by the presence of a ``state_key``, not by the event - type. + Note that the application service should distinguish state events + from message events via the presence of a ``state_key``, rather than + via the event type. operationId: sendTransaction parameters: - in: path diff --git a/specification/application_service_api.rst b/specification/application_service_api.rst index 5fe0aede..5f502969 100644 --- a/specification/application_service_api.rst +++ b/specification/application_service_api.rst @@ -224,7 +224,7 @@ need to be able to adjust the ``origin_server_ts`` value to do this. Inputs: - Application service token (``as_token``) - - Desired timestamp in milliseconds since the unix epoch + - Desired timestamp (in milliseconds since the unix epoch) Notes: - This will only apply when sending events.