diff --git a/latest/modules/presence_router_callbacks.html b/latest/modules/presence_router_callbacks.html
index c8d26631a1..1574797c03 100644
--- a/latest/modules/presence_router_callbacks.html
+++ b/latest/modules/presence_router_callbacks.html
@@ -76,7 +76,7 @@
@@ -147,9 +147,15 @@
-Presence router callbacks allow module developers to specify additional users (local or remote)
-to receive certain presence updates from local users. Presence router callbacks can be
-registered using the module API's register_presence_router_callbacks
method.
+Presence router callbacks allow module developers to define additional users
+which receive presence updates from local users. The additional users
+can be local or remote.
+For example, it could be used to direct all of @alice:example.com
(a local user)'s
+presence updates to @bob:matrix.org
(a remote user), even though they don't share a
+room. (Note that those presence updates might not make it to @bob:matrix.org
's client
+unless a similar presence router is running on that homeserver.)
+Presence router callbacks can be registered using the module API's
+register_presence_router_callbacks
method.
The available presence router callbacks are:
diff --git a/latest/modules/spam_checker_callbacks.html b/latest/modules/spam_checker_callbacks.html
index d35145ad4d..4b5378feaa 100644
--- a/latest/modules/spam_checker_callbacks.html
+++ b/latest/modules/spam_checker_callbacks.html
@@ -76,7 +76,7 @@
diff --git a/latest/modules/third_party_rules_callbacks.html b/latest/modules/third_party_rules_callbacks.html
index bb89d8aa87..d235c91239 100644
--- a/latest/modules/third_party_rules_callbacks.html
+++ b/latest/modules/third_party_rules_callbacks.html
@@ -76,7 +76,7 @@
diff --git a/latest/modules/writing_a_module.html b/latest/modules/writing_a_module.html
index 8a64cb764f..5c0ac0de25 100644
--- a/latest/modules/writing_a_module.html
+++ b/latest/modules/writing_a_module.html
@@ -76,7 +76,7 @@
diff --git a/latest/openid.html b/latest/openid.html
index f22812e707..b312546436 100644
--- a/latest/openid.html
+++ b/latest/openid.html
@@ -76,7 +76,7 @@
diff --git a/latest/opentracing.html b/latest/opentracing.html
index d7a8a401f1..b3a11206dd 100644
--- a/latest/opentracing.html
+++ b/latest/opentracing.html
@@ -76,7 +76,7 @@
@@ -187,6 +187,10 @@ using docker like so:
-p 14268:14268 \
jaegertracing/all-in-one:1
+By default, Synapse will publish traces to Jaeger on localhost.
+If Jaeger is hosted elsewhere, point Synapse to the correct host by setting
+opentracing.jaeger_config.local_agent.reporting_host
in the Synapse configuration
+or by setting the JAEGER_AGENT_HOST
environment variable to the desired address.
Latest documentation is probably at
https://www.jaegertracing.io/docs/latest/getting-started.
diff --git a/latest/other/running_synapse_on_single_board_computers.html b/latest/other/running_synapse_on_single_board_computers.html
index 26f7e9af90..aa3a7a3f2d 100644
--- a/latest/other/running_synapse_on_single_board_computers.html
+++ b/latest/other/running_synapse_on_single_board_computers.html
@@ -76,7 +76,7 @@
diff --git a/latest/password_auth_providers.html b/latest/password_auth_providers.html
index 33eed556f9..a95d69b453 100644
--- a/latest/password_auth_providers.html
+++ b/latest/password_auth_providers.html
@@ -76,7 +76,7 @@
diff --git a/latest/postgres.html b/latest/postgres.html
index 4c487267ab..11ac206921 100644
--- a/latest/postgres.html
+++ b/latest/postgres.html
@@ -76,7 +76,7 @@
diff --git a/latest/print.html b/latest/print.html
index ae54decfdf..b477a54e7e 100644
--- a/latest/print.html
+++ b/latest/print.html
@@ -77,7 +77,7 @@
@@ -3872,6 +3872,10 @@ This option replaces the previous top-level 'use_presence' option.
presence:
enabled: false
+enabled
can also be set to a special value of "untracked" which ignores updates
+received via clients and federation, while still accepting updates from the
+module API.
+The "untracked" option was added in Synapse 1.96.0.
Whether to require authentication to retrieve profile data (avatars, display names) of other
@@ -6985,53 +6989,126 @@ users by always returning an empty list for all queries. Defaults to true.
-The alias_creation_rules
option controls who is allowed to create aliases
-on this server.
-The format of this option is a list of rules that contain globs that
-match against user_id, room_id and the new alias (fully qualified with
-server name). The action in the first rule that matches is taken,
-which can currently either be "allow" or "deny".
-Missing user_id/room_id/alias fields default to "*".
-If no rules match the request is denied. An empty list means no one
-can create aliases.
-Options for the rules include:
-
-user_id
: Matches against the creator of the alias. Defaults to "*".
-alias
: Matches against the alias being created. Defaults to "*".
-room_id
: Matches against the room ID the alias is being pointed at. Defaults to "*"
-action
: Whether to "allow" or "deny" the request if the rule matches. Defaults to allow.
-
+The alias_creation_rules
option allows server admins to prevent unwanted
+alias creation on this server.
+This setting is an optional list of 0 or more rules. By default, no list is
+provided, meaning that all alias creations are permitted.
+Otherwise, requests to create aliases are matched against each rule in order.
+The first rule that matches decides if the request is allowed or denied. If no
+rule matches, the request is denied. In particular, this means that configuring
+an empty list of rules will deny every alias creation request.
+Each rule is a YAML object containing four fields, each of which is an optional string:
+
+user_id
: a glob pattern that matches against the creator of the alias.
+alias
: a glob pattern that matches against the alias being created.
+room_id
: a glob pattern that matches against the room ID the alias is being pointed at.
+action
: either allow
or deny
. What to do with the request if the rule matches. Defaults to allow
.
+
+Each of the glob patterns is optional, defaulting to *
("match anything").
+Note that the patterns match against fully qualified IDs, e.g. against
+@alice:example.com
, #room:example.com
and !abcdefghijk:example.com
instead
+of alice
, room
and abcedgghijk
.
Example configuration:
-alias_creation_rules:
- - user_id: "bad_user"
- alias: "spammy_alias"
- room_id: "*"
+# No rule list specified. All alias creations are allowed.
+# This is the default behaviour.
+alias_creation_rules:
+
+# A list of one rule which allows everything.
+# This has the same effect as the previous example.
+alias_creation_rules:
+ - "action": "allow"
+
+# An empty list of rules. All alias creations are denied.
+alias_creation_rules: []
+
+# A list of one rule which denies everything.
+# This has the same effect as the previous example.
+alias_creation_rules:
+ - "action": "deny"
+
+# Prevent a specific user from creating aliases.
+# Allow other users to create any alias
+alias_creation_rules:
+ - user_id: "@bad_user:example.com"
+ action: deny
+
+ - action: allow
+
+# Prevent aliases being created which point to a specific room.
+alias_creation_rules:
+ - room_id: "!forbiddenRoom:example.com"
action: deny
+
+ - action: allow
-The room_list_publication_rules
option controls who can publish and
-which rooms can be published in the public room list.
+The room_list_publication_rules
option allows server admins to prevent
+unwanted entries from being published in the public room list.
The format of this option is the same as that for
-alias_creation_rules
.
-If the room has one or more aliases associated with it, only one of
-the aliases needs to match the alias rule. If there are no aliases
-then only rules with alias: *
match.
-If no rules match the request is denied. An empty list means no one
-can publish rooms.
-Options for the rules include:
-
-user_id
: Matches against the creator of the alias. Defaults to "*".
-alias
: Matches against any current local or canonical aliases associated with the room. Defaults to "*".
-room_id
: Matches against the room ID being published. Defaults to "*".
-action
: Whether to "allow" or "deny" the request if the rule matches. Defaults to allow.
-
+alias_creation_rules
: an optional list of 0 or more
+rules. By default, no list is provided, meaning that all rooms may be
+published to the room list.
+Otherwise, requests to publish a room are matched against each rule in order.
+The first rule that matches decides if the request is allowed or denied. If no
+rule matches, the request is denied. In particular, this means that configuring
+an empty list of rules will deny every alias creation request.
+Each rule is a YAML object containing four fields, each of which is an optional string:
+
+user_id
: a glob pattern that matches against the user publishing the room.
+alias
: a glob pattern that matches against one of published room's aliases.
+
+- If the room has no aliases, the alias match fails unless
alias
is unspecified or *
.
+- If the room has exactly one alias, the alias match succeeds if the
alias
pattern matches that alias.
+- If the room has two or more aliases, the alias match succeeds if the pattern matches at least one of the aliases.
+
+
+room_id
: a glob pattern that matches against the room ID of the room being published.
+action
: either allow
or deny
. What to do with the request if the rule matches. Defaults to allow
.
+
+Each of the glob patterns is optional, defaulting to *
("match anything").
+Note that the patterns match against fully qualified IDs, e.g. against
+@alice:example.com
, #room:example.com
and !abcdefghijk:example.com
instead
+of alice
, room
and abcedgghijk
.
Example configuration:
-room_list_publication_rules:
- - user_id: "*"
- alias: "*"
- room_id: "*"
- action: allow
+# No rule list specified. Anyone may publish any room to the public list.
+# This is the default behaviour.
+room_list_publication_rules:
+
+# A list of one rule which allows everything.
+# This has the same effect as the previous example.
+room_list_publication_rules:
+ - "action": "allow"
+
+# An empty list of rules. No-one may publish to the room list.
+room_list_publication_rules: []
+
+# A list of one rule which denies everything.
+# This has the same effect as the previous example.
+room_list_publication_rules:
+ - "action": "deny"
+
+# Prevent a specific user from publishing rooms.
+# Allow other users to publish anything.
+room_list_publication_rules:
+ - user_id: "@bad_user:example.com"
+ action: deny
+
+ - action: allow
+
+# Prevent publication of a specific room.
+room_list_publication_rules:
+ - room_id: "!forbiddenRoom:example.com"
+ action: deny
+
+ - action: allow
+
+# Prevent publication of rooms with at least one alias containing the word "potato".
+room_list_publication_rules:
+ - alias: "#*potato*:example.com"
+ action: deny
+
+ - action: allow
@@ -10517,9 +10594,15 @@ class EventCensorer:
return event_dict
-Presence router callbacks allow module developers to specify additional users (local or remote)
-to receive certain presence updates from local users. Presence router callbacks can be
-registered using the module API's register_presence_router_callbacks
method.
+Presence router callbacks allow module developers to define additional users
+which receive presence updates from local users. The additional users
+can be local or remote.
+For example, it could be used to direct all of @alice:example.com
(a local user)'s
+presence updates to @bob:matrix.org
(a remote user), even though they don't share a
+room. (Note that those presence updates might not make it to @bob:matrix.org
's client
+unless a similar presence router is running on that homeserver.)
+Presence router callbacks can be registered using the module API's
+register_presence_router_callbacks
method.
The available presence router callbacks are:
@@ -11004,6 +11087,27 @@ class CustomAccountDataModule:
}
)
+
+First introduced in Synapse v1.96.0
+This callback allows modules to add extra fields to the unsigned section of
+events when they get sent down to clients.
+These get called every time an event is to be sent to clients, so care should
+be taken to ensure with respect to performance.
+
+To register the callback, use
+register_add_extra_fields_to_unsigned_client_event_callbacks
on the
+ModuleApi
.
+The callback should be of the form
+async def add_field_to_unsigned(
+ event: EventBase,
+) -> JsonDict:
+
+where the extra fields to add to the event's unsigned section is returned.
+(Modules must not attempt to modify the event
directly).
+This cannot be used to alter the "core" fields in the unsigned section emitted
+by Synapse itself.
+If multiple such callbacks try to add the same field to an event's unsigned
+section, the last-registered callback wins.
In order to port a module that uses Synapse's old module interface, its author needs to:
pip install --user pipx
-pipx install poetry
+pipx install poetry==1.5.2 # Problems with Poetry 1.6, see https://github.com/matrix-org/synapse/issues/16147
but see poetry's installation instructions
for other installation methods.
@@ -17013,6 +17117,10 @@ using docker like so:
-p 14268:14268 \
jaegertracing/all-in-one:1
+By default, Synapse will publish traces to Jaeger on localhost.
+If Jaeger is hosted elsewhere, point Synapse to the correct host by setting
+opentracing.jaeger_config.local_agent.reporting_host
in the Synapse configuration
+or by setting the JAEGER_AGENT_HOST
environment variable to the desired address.
Latest documentation is probably at
https://www.jaegertracing.io/docs/latest/getting-started.
@@ -18339,16 +18447,22 @@ will be inserted with that ID.
For any given stream reader (including writers themselves), we may define a per-writer current stream ID:
-The current stream ID for a writer W is the largest stream ID such that
+
A current stream ID for a writer W is the largest stream ID such that
all transactions added by W with equal or smaller ID have completed.
Similarly, there is a "linear" notion of current stream ID:
-The "linear" current stream ID is the largest stream ID such that
+
A "linear" current stream ID is the largest stream ID such that
all facts (added by any writer) with equal or smaller ID have completed.
Because different stream readers A and B learn about new facts at different times, A and B may disagree about current stream IDs.
Put differently: we should think of stream readers as being independent of each other, proceeding through a stream of facts at different rates.
+The above definition does not give a unique current stream ID, in fact there can
+be a range of current stream IDs. Synapse uses both the minimum and maximum IDs
+for different purposes. Most often the maximum is used, as its generally
+beneficial for workers to advance their IDs as soon as possible. However, the
+minimum is used in situations where e.g. another worker is going to wait until
+the stream advances past a position.
NB. For both senses of "current", that if a writer opens a transaction that never completes, the current stream ID will never advance beyond that writer's last written stream ID.
For single-writer streams, the per-writer current ID and the linear current ID are the same.
Both senses of current ID are monotonic, but they may "skip" or jump over IDs because facts complete out of order.
@@ -18391,7 +18505,7 @@ We only ever treat this as a multiple single-writer streams as there is no impor
track their current position (i.e. its own per-writer stream ID).
their facts currently awaiting completion.