summary refs log tree commit diff
path: root/docs/server_notices.md
diff options
context:
space:
mode:
authorRichard van der Hoff <1389908+richvdh@users.noreply.github.com>2018-05-23 16:23:05 +0100
committerGitHub <noreply@github.com>2018-05-23 16:23:05 +0100
commit96f07cebda915e999ccde8e5205020611da05056 (patch)
tree9cfd4d0b666220e36219eeb77ce8b5d0adffbbaf /docs/server_notices.md
parentMerge pull request #3265 from matrix-org/erikj/limit_pagination (diff)
parentconsent_tracking.md: clarify link (diff)
downloadsynapse-96f07cebda915e999ccde8e5205020611da05056.tar.xz
Merge pull request #3268 from matrix-org/rav/privacy_policy_docs
Docs on consent bits
Diffstat (limited to 'docs/server_notices.md')
-rw-r--r--docs/server_notices.md68
1 files changed, 68 insertions, 0 deletions
diff --git a/docs/server_notices.md b/docs/server_notices.md
new file mode 100644
index 0000000000..8e18e3d95d
--- /dev/null
+++ b/docs/server_notices.md
@@ -0,0 +1,68 @@
+Server Notices
+==============
+
+'Server Notices' are a new feature introduced in Synapse 0.30. They provide a
+channel whereby server administrators can send messages to users on the server.
+
+They are used as part of communication of the server polices(see
+[consent_tracking.md](consent_tracking.md)), however the intention is that 
+they may also find a use for features such as "Message of the day".
+
+This is a feature specific to Synapse, but it uses standard Matrix
+communication mechanisms, so should work with any Matrix client.
+
+User experience
+---------------
+
+When the user is first sent a server notice, they will get an invitation to a
+room (typically called 'Server Notices', though this is configurable in
+`homeserver.yaml`). They will be **unable to reject** this invitation -
+attempts to do so will receive an error.
+
+Once they accept the invitation, they will see the notice message in the room
+history; it will appear to have come from the 'server notices user' (see
+below).
+
+The user is prevented from sending any messages in this room by the power
+levels. They also cannot leave it.
+
+Synapse configuration
+---------------------
+
+Server notices come from a specific user id on the server. Server
+administrators are free to choose the user id - something like `server` is
+suggested, meaning the notices will come from
+`@server:<your_server_name>`. Once the Server Notices user is configured, that
+user id becomes a special, privileged user, so administrators should ensure
+that **it is not already allocated**.
+
+In order to support server notices, it is necessary to add some configuration
+to the `homeserver.yaml` file. In particular, you should add a `server_notices`
+section, which should look like this:
+
+```yaml
+server_notices:
+   system_mxid_localpart: server
+   system_mxid_display_name: "Server Notices"
+   room_name: "Server Notices"
+```
+
+The only compulsory setting is `system_mxid_localpart`, which defines the user
+id of the server notices user, as above. `system_mxid_display_name` and
+`room_name` define the displayname of the system notices user, and of
+the notices room, respectively.
+
+Sending notices
+---------------
+
+As of the current version of synapse, there is no convenient interface for
+sending notices (other than the automated ones sent as part of consent
+tracking).
+
+In the meantime, it is possible to test this feature using the manhole. Having
+gone into the manhole as described in [manhole.md](manhole.md), a notice can be
+sent with something like:
+
+```
+>>> hs.get_server_notices_manager().send_notice('@user:server.com', {'msgtype':'m.text', 'body':'foo'})
+```