From deb24aecf40cb7e6e7fdd4fad8320820ae117c4d Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Mon, 5 Jan 2015 18:42:22 +0000 Subject: [PATCH] some thoughts on invisibility --- drafts/applications_services.rst | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/drafts/applications_services.rst b/drafts/applications_services.rst index 0333a89a..45bb8276 100644 --- a/drafts/applications_services.rst +++ b/drafts/applications_services.rst @@ -159,12 +159,28 @@ On AS publishing aliases for virtual rooms: at least the m.room.create of that room must also be prepopulated. It seems sensible to prepopulate the required initial state and history of the room to avoid a two-phase prepopulation process. - + On unregistering the AS from the HS: * An AS must tell the HS when it is going offline in order to stop receiving requests from the HS. It does this by hitting an API on the HS. +AS Visibility: + + * If an AS needs to sniff events in a room in order to operate on them (e.g. + to act as a search engine) but not inject traffic into the room, it should + do so by subscribing to the relevant events without actually joining the room. + * If the AS needs to participate in the room as a virtual user (e.g. an IVR + service, or a bot, or a gatewayed virtual user), it should join the room + normally. + * There are rare instances where an AS may wish to participate in a room + (including inserting messages), but be hidden from the room list - e.g. a + conferencing server focus bot may wish to join many rooms as the focus and + both listen to VoIP setups and inject its own VoIP answers, without ever + being physically seen in the room. In this scenario, the user should set + its presence to 'invisible', a state that HSes should only allow AS-authed + users to set. + Extensions to CS API ====================