diff --git a/latest/development/contributing_guide.html b/latest/development/contributing_guide.html index bdcfd36ba8..3aeafe7b4d 100644 --- a/latest/development/contributing_guide.html +++ b/latest/development/contributing_guide.html @@ -323,10 +323,10 @@ Here is how to run your local Synapse checkout against your local Complement che 
COMPLEMENT_DIR=../complement ./scripts-dev/complement.sh

To run a specific test file, you can pass the test name at the end of the command. The name passed comes from the naming structure in your Complement tests. If you're unsure of the name, you can do a full run and copy it from the test output:

-
COMPLEMENT_DIR=../complement ./scripts-dev/complement.sh TestBackfillingHistory
+
COMPLEMENT_DIR=../complement ./scripts-dev/complement.sh -run TestImportHistoricalMessages
 

 
To run a specific test, you can specify the whole name structure:

-
COMPLEMENT_DIR=../complement ./scripts-dev/complement.sh TestBackfillingHistory/parallel/Backfilled_historical_events_resolve_with_proper_state_in_correct_order
+
COMPLEMENT_DIR=../complement ./scripts-dev/complement.sh -run TestImportHistoricalMessages/parallel/Historical_events_resolve_in_the_correct_order
 

 
Access database for homeserver after Complement test runs.

 
If you're curious what the database looks like after you run some tests, here are some steps to get you going in Synapse:

diff --git a/latest/jwt.html b/latest/jwt.html
index 1a314e780b..9c41f27e9a 100644
--- a/latest/jwt.html
+++ b/latest/jwt.html
@@ -160,8 +160,6 @@ follows:

   "token": "<jwt>"
 }
 

-
Note that the login type of m.login.jwt is supported, but is deprecated. This
-will be removed in a future version of Synapse.

 
The token field should include the JSON web token with the following claims:
+

Upgrading to v1.59.0

+

Device name lookup over federation has been disabled by default

+

The names of user devices are no longer visible to users on other homeservers by default. +Device IDs are unaffected, as these are necessary to facilitate end-to-end encryption.

+

To re-enable this functionality, set the +allow_device_name_lookup_over_federation +homeserver config option to true.

+

Deprecation of the synapse.app.appservice and synapse.app.user_dir worker application types

+

The synapse.app.appservice worker application type allowed you to configure a +single worker to use to notify application services of new events, as long +as this functionality was disabled on the main process with notify_appservices: False. +Further, the synapse.app.user_dir worker application type allowed you to configure +a single worker to be responsible for updating the user directory, as long as this +was disabled on the main process with update_user_directory: False.

+

To unify Synapse's worker types, the synapse.app.appservice worker application +type and the notify_appservices configuration option have been deprecated. +The synapse.app.user_dir worker application type and update_user_directory +configuration option have also been deprecated.

+

To get the same functionality as was provided by the deprecated options, it's now recommended that the synapse.app.generic_worker +worker application type is used and that the notify_appservices_from_worker and/or +update_user_directory_from_worker options are set to the name of a worker.

+

For the time being, the old options can be used alongside the new options to make +it easier to transition between the two configurations, however please note that:

+ +

Please see the Notifying Application Services and +Updating the User Directory sections of the worker +documentation for more information.

Upgrading to v1.58.0

Groups/communities feature has been disabled by default

The non-standard groups/communities feature in Synapse has been disabled by default @@ -3501,6 +3531,17 @@ session. Defaults to 0. 

mau_trial_days: 5
+

Config option: mau_appservice_trial_days

+

The option mau_appservice_trial_days is similar to mau_trial_days, but applies a different +trial number if the user was registered by an appservice. A value +of 0 means no trial days are applied. Appservices not listed in this dictionary +use the value of mau_trial_days instead.

+

Example configuration:

+
mau_appservice_trial_days: 
+  my_appservice_id: 3
+  another_appservice_id: 6
+
+

Config option: mau_limit_alerting

The option mau_limit_alerting is a means of limiting client-side alerting should the mau limit be reached. This is useful for small instances @@ -3816,11 +3857,11 @@ on this homeserver.

Config option: allow_device_name_lookup_over_federation

-

Set this option to false to disable device display name lookup over federation. By default, the -Federation API allows other homeservers to obtain device display names of any user +

Set this option to true to allow device display name lookup over federation. By default, the +Federation API prevents other homeservers from obtaining the display names of any user devices on this homeserver.

Example configuration:

-
allow_device_name_lookup_over_federation: false
+
allow_device_name_lookup_over_federation: true
 

 

 
Caching

@@ -6345,6 +6386,11 @@ manhole_settings:
 # sign up in a short space of time never to return after their initial
 # session.
 #
+# The option `mau_appservice_trial_days` is similar to `mau_trial_days`, but
+# applies a different trial number if the user was registered by an appservice.
+# A value of 0 means no trial days are applied. Appservices not listed in this
+# dictionary use the value of `mau_trial_days` instead.
+#
 # 'mau_limit_alerting' is a means of limiting client side alerting
 # should the mau limit be reached. This is useful for small instances
 # where the admin has 5 mau seats (say) for 5 specific people and no
@@ -6355,6 +6401,8 @@ manhole_settings:
 #max_mau_value: 50
 #mau_trial_days: 2
 #mau_limit_alerting: false
+#mau_appservice_trial_days:
+#  "appservice-id": 1
 
 # If enabled, the metrics for the number of monthly active users will
 # be populated, however no one will be limited. If limit_usage_by_mau
@@ -6647,11 +6695,11 @@ retention:
 #
 #allow_profile_lookup_over_federation: false
 
-# Uncomment to disable device display name lookup over federation. By default, the
-# Federation API allows other homeservers to obtain device display names of any user
-# on this homeserver. Defaults to 'true'.
+# Uncomment to allow device display name lookup over federation. By default, the
+# Federation API prevents other homeservers from obtaining the display names of
+# user devices on this homeserver. Defaults to 'false'.
 #
-#allow_device_name_lookup_over_federation: false
+#allow_device_name_lookup_over_federation: true
 
 
 ## Caching ##
@@ -7261,6 +7309,12 @@ oembed:
 #
 #registration_requires_token: true
 
+# Allow users to submit a token during registration to bypass any required 3pid
+# steps configured in `registrations_require_3pid`.
+# Defaults to false, requiring that registration tokens (if enabled) complete a 3pid flow.
+#
+#enable_registration_token_3pid_bypass: false
+
 # If set, allows registration of standard or admin accounts by anyone who
 # has the shared secret, even if registration is otherwise disabled.
 #
@@ -8801,13 +8855,6 @@ loggers:
         # information such as access tokens.
         level: INFO
 
-    twisted:
-        # We send the twisted logging directly to the file handler,
-        # to work around https://github.com/matrix-org/synapse/issues/3471
-        # when using "buffer" logger. Use "console" to log to stderr instead.
-        handlers: [file]
-        propagate: false
-
 root:
     level: INFO
 
@@ -10098,8 +10145,6 @@ follows:

   "token": "<jwt>"
 }
-

Note that the login type of m.login.jwt is supported, but is deprecated. This -will be removed in a future version of Synapse.

The token field should include the JSON web token with the following claims:

+

Upgrading to v1.59.0

+

Device name lookup over federation has been disabled by default

+

The names of user devices are no longer visible to users on other homeservers by default. +Device IDs are unaffected, as these are necessary to facilitate end-to-end encryption.

+

To re-enable this functionality, set the +allow_device_name_lookup_over_federation +homeserver config option to true.

+

Deprecation of the synapse.app.appservice and synapse.app.user_dir worker application types

+

The synapse.app.appservice worker application type allowed you to configure a +single worker to use to notify application services of new events, as long +as this functionality was disabled on the main process with notify_appservices: False. +Further, the synapse.app.user_dir worker application type allowed you to configure +a single worker to be responsible for updating the user directory, as long as this +was disabled on the main process with update_user_directory: False.

+

To unify Synapse's worker types, the synapse.app.appservice worker application +type and the notify_appservices configuration option have been deprecated. +The synapse.app.user_dir worker application type and update_user_directory +configuration option have also been deprecated.

+

To get the same functionality as was provided by the deprecated options, it's now recommended that the synapse.app.generic_worker +worker application type is used and that the notify_appservices_from_worker and/or +update_user_directory_from_worker options are set to the name of a worker.

+

For the time being, the old options can be used alongside the new options to make +it easier to transition between the two configurations, however please note that:

+
    +
  • the options must not contradict each other (otherwise Synapse won't start); and
    • +
  • the notify_appservices and update_user_directory options will be removed in a future release of Synapse.
    • +
+

Please see the Notifying Application Services and +Updating the User Directory sections of the worker +documentation for more information.

Upgrading to v1.58.0

Groups/communities feature has been disabled by default

The non-standard groups/communities feature in Synapse has been disabled by default diff --git a/latest/usage/administration/request_log.html b/latest/usage/administration/request_log.html index 47b1defb1e..81b34fc9cf 100644 --- a/latest/usage/administration/request_log.html +++ b/latest/usage/administration/request_log.html @@ -169,7 +169,7 @@ NNNNTotal time waiting for response to DB queries across all parallel DB work from this request OOOOCount of DB transactions performed PPPPResponse body size -QQQQResponse status code (prefixed with ! if the socket was closed before the response was generated) +QQQQResponse status code
Suffixed with ! if the socket was closed before the response was generated.
A 499! status code indicates that Synapse also cancelled request processing after the socket was closed.
RRRRRequest SSSSUser-agent TTTTEvents fetched from DB to service this request (note that this does not include events fetched from the cache) diff --git a/latest/usage/administration/useful_sql_for_admins.html b/latest/usage/administration/useful_sql_for_admins.html index 308b1870f7..e6a8059845 100644 --- a/latest/usage/administration/useful_sql_for_admins.html +++ b/latest/usage/administration/useful_sql_for_admins.html @@ -148,40 +148,23 @@

Some useful SQL queries for Synapse Admins

Size of full matrix db

-

SELECT pg_size_pretty( pg_database_size( 'matrix' ) );

+
SELECT pg_size_pretty( pg_database_size( 'matrix' ) );
+

Result example:

pg_size_pretty 
 ----------------
  6420 MB
 (1 row)
-

Show top 20 larger rooms by state events count

-
SELECT r.name, s.room_id, s.current_state_events
-  FROM room_stats_current s
-  LEFT JOIN room_stats_state r USING (room_id)
-  ORDER BY current_state_events DESC
-  LIMIT 20;
-
-

and by state_group_events count:

-
SELECT rss.name, s.room_id, count(s.room_id) FROM state_groups_state s
-LEFT JOIN room_stats_state rss USING (room_id)
-GROUP BY s.room_id, rss.name        
-ORDER BY count(s.room_id) DESC
-LIMIT 20;
-
-

plus same, but with join removed for performance reasons:

-
SELECT s.room_id, count(s.room_id) FROM state_groups_state s
-GROUP BY s.room_id        
-ORDER BY count(s.room_id) DESC
-LIMIT 20;
-

Show top 20 larger tables by row count

-
SELECT relname, n_live_tup as rows
-  FROM pg_stat_user_tables 
+
SELECT relname, n_live_tup AS "rows"
+  FROM pg_stat_user_tables
   ORDER BY n_live_tup DESC
   LIMIT 20;
 

-
This query is quick, but may be very approximate, for exact number of rows use SELECT COUNT(*) FROM <table_name>.

+
This query is quick, but may be very approximate, for exact number of rows use:

+
SELECT COUNT(*) FROM <table_name>;
+

 
Result example:

 
state_groups_state - 161687170
 event_auth - 8584785
@@ -204,37 +187,15 @@ users_in_public_rooms - 364059
 device_lists_stream - 326903
 user_directory_search - 316433
 

-
Show top 20 rooms by new events count in last 1 day:

-
SELECT e.room_id, r.name, COUNT(e.event_id) cnt FROM events e
-LEFT JOIN room_stats_state r USING (room_id)
-WHERE e.origin_server_ts >= DATE_PART('epoch', NOW() - INTERVAL '1 day') * 1000 GROUP BY e.room_id, r.name ORDER BY cnt DESC LIMIT 20;
-

-
Show top 20 users on homeserver by sent events (messages) at last month:

-
SELECT user_id, SUM(total_events) 
-   FROM user_stats_historical
-   WHERE TO_TIMESTAMP(end_ts/1000) AT TIME ZONE 'UTC' > date_trunc('day', now() - interval '1 month')
-   GROUP BY user_id
-   ORDER BY SUM(total_events) DESC 
-   LIMIT 20;
-

-
Show last 100 messages from needed user, with room names:

-
SELECT e.room_id, r.name, e.event_id, e.type, e.content, j.json FROM events e
-  LEFT JOIN event_json j USING (room_id)
-  LEFT JOIN room_stats_state r USING (room_id)
-  WHERE sender = '@LOGIN:example.com'
-  AND e.type = 'm.room.message'
-  ORDER BY stream_ordering DESC
-  LIMIT 100;
-

 
Show top 20 larger tables by storage size

 
SELECT nspname || '.' || relname AS "relation",
-    pg_size_pretty(pg_total_relation_size(C.oid)) AS "total_size"
-  FROM pg_class C
-  LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
+    pg_size_pretty(pg_total_relation_size(c.oid)) AS "total_size"
+  FROM pg_class c
+  LEFT JOIN pg_namespace n ON (n.oid = c.relnamespace)
   WHERE nspname NOT IN ('pg_catalog', 'information_schema')
-    AND C.relkind <> 'i'
+    AND c.relkind <> 'i'
     AND nspname !~ '^pg_toast'
-  ORDER BY pg_total_relation_size(C.oid) DESC
+  ORDER BY pg_total_relation_size(c.oid) DESC
   LIMIT 20;
 

 
Result example:

@@ -259,8 +220,75 @@ public.state_groups - 160 MB
 public.device_lists_remote_cache - 124 MB
 public.state_group_edges - 122 MB
+

Show top 20 larger rooms by state events count

+

You get the same information when you use the +admin API +and set parameter order_by=state_events.

+
SELECT r.name, s.room_id, s.current_state_events
+  FROM room_stats_current s
+  LEFT JOIN room_stats_state r USING (room_id)
+  ORDER BY current_state_events DESC
+  LIMIT 20;
+
+

and by state_group_events count:

+
SELECT rss.name, s.room_id, COUNT(s.room_id)
+  FROM state_groups_state s
+  LEFT JOIN room_stats_state rss USING (room_id)
+  GROUP BY s.room_id, rss.name
+  ORDER BY COUNT(s.room_id) DESC
+  LIMIT 20;
+
+

plus same, but with join removed for performance reasons:

+
SELECT s.room_id, COUNT(s.room_id)
+  FROM state_groups_state s
+  GROUP BY s.room_id 
+  ORDER BY COUNT(s.room_id) DESC
+  LIMIT 20;
+
+

Show top 20 rooms by new events count in last 1 day:

+
SELECT e.room_id, r.name, COUNT(e.event_id) cnt
+  FROM events e
+  LEFT JOIN room_stats_state r USING (room_id)
+  WHERE e.origin_server_ts >= DATE_PART('epoch', NOW() - INTERVAL '1 day') * 1000
+  GROUP BY e.room_id, r.name 
+  ORDER BY cnt DESC
+  LIMIT 20;
+
+

Show top 20 users on homeserver by sent events (messages) at last month:

+

Caution. This query does not use any indexes, can be slow and create load on the database.

+
SELECT COUNT(*), sender
+  FROM events
+  WHERE (type = 'm.room.encrypted' OR type = 'm.room.message')
+    AND origin_server_ts >= DATE_PART('epoch', NOW() - INTERVAL '1 month') * 1000
+  GROUP BY sender
+  ORDER BY COUNT(*) DESC
+  LIMIT 20;
+
+

Show last 100 messages from needed user, with room names:

+
SELECT e.room_id, r.name, e.event_id, e.type, e.content, j.json
+  FROM events e
+  LEFT JOIN event_json j USING (room_id)
+  LEFT JOIN room_stats_state r USING (room_id)
+  WHERE sender = '@LOGIN:example.com'
+    AND e.type = 'm.room.message'
+  ORDER BY stream_ordering DESC
+  LIMIT 100;
+

Show rooms with names, sorted by events in this rooms

-

echo "select event_json.room_id,room_stats_state.name from event_json,room_stats_state where room_stats_state.room_id=event_json.room_id" | psql synapse | sort | uniq -c | sort -n

+

Sort and order with bash

+
echo "SELECT event_json.room_id, room_stats_state.name FROM event_json, room_stats_state \
+WHERE room_stats_state.room_id = event_json.room_id" | psql -d synapse -h localhost -U synapse_user -t \
+| sort | uniq -c | sort -n
+
+

Documentation for psql command line parameters: https://www.postgresql.org/docs/current/app-psql.html

+

Sort and order with SQL

+
SELECT COUNT(*), event_json.room_id, room_stats_state.name
+  FROM event_json, room_stats_state
+  WHERE room_stats_state.room_id = event_json.room_id
+  GROUP BY event_json.room_id, room_stats_state.name
+  ORDER BY COUNT(*) DESC
+  LIMIT 50;
+

Result example:

   9459  !FPUfgzXYWTKgIrwKxW:matrix.org              | This Week in Matrix
    9459  !FPUfgzXYWTKgIrwKxW:matrix.org              | This Week in Matrix (TWIM)
@@ -272,13 +300,21 @@ public.state_group_edges - 122 MB
   43601  !iNmaIQExDMeqdITdHH:matrix.org              | Riot Web/Desktop

Lookup room state info by list of room_id

-
SELECT rss.room_id, rss.name, rss.canonical_alias, rss.topic, rss.encryption, rsc.joined_members, rsc.local_users_in_room, rss.join_rules
-FROM room_stats_state rss
-LEFT JOIN room_stats_current rsc USING (room_id)
-WHERE room_id IN (WHERE room_id IN (
- '!OGEhHVWSdvArJzumhm:matrix.org',
- '!YTvKGNlinIzlkMTVRl:matrix.org'
-)
+
You get the same information when you use the
+admin API.

+
SELECT rss.room_id, rss.name, rss.canonical_alias, rss.topic, rss.encryption,
+    rsc.joined_members, rsc.local_users_in_room, rss.join_rules
+  FROM room_stats_state rss
+  LEFT JOIN room_stats_current rsc USING (room_id)
+  WHERE room_id IN ( WHERE room_id IN (
+    '!OGEhHVWSdvArJzumhm:matrix.org',
+    '!YTvKGNlinIzlkMTVRl:matrix.org' 
+  );
+

+
Show users and devices that have not been online for a while

+
SELECT user_id, device_id, user_agent, TO_TIMESTAMP(last_seen / 1000) AS "last_seen"
+  FROM devices
+  WHERE last_seen < DATE_PART('epoch', NOW() - INTERVAL '3 month') * 1000;
 

 
                     
diff --git a/latest/usage/configuration/config_documentation.html b/latest/usage/configuration/config_documentation.html
index e0c2459f3b..0603e07295 100644
--- a/latest/usage/configuration/config_documentation.html
+++ b/latest/usage/configuration/config_documentation.html
@@ -660,6 +660,17 @@ session. Defaults to 0. 

 
mau_trial_days: 5
 

 

+
Config option: mau_appservice_trial_days

+
The option mau_appservice_trial_days is similar to mau_trial_days, but applies a different
+trial number if the user was registered by an appservice. A value
+of 0 means no trial days are applied. Appservices not listed in this dictionary
+use the value of mau_trial_days instead.

+
Example configuration:

+
mau_appservice_trial_days: 
+  my_appservice_id: 3
+  another_appservice_id: 6
+

+

 
Config option: mau_limit_alerting

 
The option mau_limit_alerting is a means of limiting client-side alerting
 should the mau limit be reached. This is useful for small instances
@@ -975,11 +986,11 @@ on this homeserver.

Config option: allow_device_name_lookup_over_federation

-

Set this option to false to disable device display name lookup over federation. By default, the -Federation API allows other homeservers to obtain device display names of any user +

Set this option to true to allow device display name lookup over federation. By default, the +Federation API prevents other homeservers from obtaining the display names of any user devices on this homeserver.

Example configuration:

-
allow_device_name_lookup_over_federation: false
+
allow_device_name_lookup_over_federation: true
 

 

 
Caching

diff --git a/latest/usage/configuration/homeserver_sample_config.html b/latest/usage/configuration/homeserver_sample_config.html
index 836ae803f0..ec9c6791ec 100644
--- a/latest/usage/configuration/homeserver_sample_config.html
+++ b/latest/usage/configuration/homeserver_sample_config.html
@@ -563,6 +563,11 @@ manhole_settings:
 # sign up in a short space of time never to return after their initial
 # session.
 #
+# The option `mau_appservice_trial_days` is similar to `mau_trial_days`, but
+# applies a different trial number if the user was registered by an appservice.
+# A value of 0 means no trial days are applied. Appservices not listed in this
+# dictionary use the value of `mau_trial_days` instead.
+#
 # 'mau_limit_alerting' is a means of limiting client side alerting
 # should the mau limit be reached. This is useful for small instances
 # where the admin has 5 mau seats (say) for 5 specific people and no
@@ -573,6 +578,8 @@ manhole_settings:
 #max_mau_value: 50
 #mau_trial_days: 2
 #mau_limit_alerting: false
+#mau_appservice_trial_days:
+#  "appservice-id": 1
 
 # If enabled, the metrics for the number of monthly active users will
 # be populated, however no one will be limited. If limit_usage_by_mau
@@ -865,11 +872,11 @@ retention:
 #
 #allow_profile_lookup_over_federation: false
 
-# Uncomment to disable device display name lookup over federation. By default, the
-# Federation API allows other homeservers to obtain device display names of any user
-# on this homeserver. Defaults to 'true'.
+# Uncomment to allow device display name lookup over federation. By default, the
+# Federation API prevents other homeservers from obtaining the display names of
+# user devices on this homeserver. Defaults to 'false'.
 #
-#allow_device_name_lookup_over_federation: false
+#allow_device_name_lookup_over_federation: true
 
 
 ## Caching ##
@@ -1479,6 +1486,12 @@ oembed:
 #
 #registration_requires_token: true
 
+# Allow users to submit a token during registration to bypass any required 3pid
+# steps configured in `registrations_require_3pid`.
+# Defaults to false, requiring that registration tokens (if enabled) complete a 3pid flow.
+#
+#enable_registration_token_3pid_bypass: false
+
 # If set, allows registration of standard or admin accounts by anyone who
 # has the shared secret, even if registration is otherwise disabled.
 #
diff --git a/latest/usage/configuration/logging_sample_config.html b/latest/usage/configuration/logging_sample_config.html
index fca0918503..7f22f2cba4 100644
--- a/latest/usage/configuration/logging_sample_config.html
+++ b/latest/usage/configuration/logging_sample_config.html
@@ -218,13 +218,6 @@ loggers:
         # information such as access tokens.
         level: INFO
 
-    twisted:
-        # We send the twisted logging directly to the file handler,
-        # to work around https://github.com/matrix-org/synapse/issues/3471
-        # when using "buffer" logger. Use "console" to log to stderr instead.
-        handlers: [file]
-        propagate: false
-
 root:
     level: INFO
 
diff --git a/latest/workers.html b/latest/workers.html
index 347b4b514a..495acf8d34 100644
--- a/latest/workers.html
+++ b/latest/workers.html
@@ -520,7 +520,7 @@ background tasks. For example, to move background tasks to a dedicated worker,
 the shared configuration would include:

 
run_background_tasks_on: background_worker
 

-
You might also wish to investigate the update_user_directory and
+
You might also wish to investigate the update_user_directory_from_worker and
 media_instance_running_background_jobs settings.

 
An example for a dedicated background worker instance:

 
worker_app: synapse.app.generic_worker
@@ -532,6 +532,24 @@ worker_replication_http_port: 9093
 
 worker_log_config: /etc/matrix-synapse/background-worker-log.yaml
 

+
Updating the User Directory

+
You can designate one generic worker to update the user directory.

+
Specify its name in the shared configuration as follows:

+
update_user_directory_from_worker: worker_name
+

+
This work cannot be load-balanced; please ensure the main process is restarted
+after setting this option in the shared configuration!

+
This style of configuration supersedes the legacy synapse.app.user_dir
+worker application type.

+
Notifying Application Services

+
You can designate one generic worker to send output traffic to Application Services.

+
Specify its name in the shared configuration as follows:

+
notify_appservices_from_worker: worker_name
+

+
This work cannot be load-balanced; please ensure the main process is restarted
+after setting this option in the shared configuration!

+
This style of configuration supersedes the legacy synapse.app.appservice
+worker application type.

 
synapse.app.pusher

 
Handles sending push notifications to sygnal and email. Doesn't handle any
 REST endpoints itself, but you should set start_pushers: False in the
@@ -543,6 +561,8 @@ pusher instances by their worker name, e.g.:

     - pusher_worker2

synapse.app.appservice

+

Deprecated as of Synapse v1.59. Use synapse.app.generic_worker with the +notify_appservices_from_worker option instead.

Handles sending output traffic to Application Services. Doesn't handle any REST endpoints itself, but you should set notify_appservices: False in the shared configuration file to stop the main synapse sending appservice notifications.

@@ -590,6 +610,8 @@ and you must configure a single instance to run the background tasks, e.g.:

Note that if a reverse proxy is used , then /_matrix/media/ must be routed for both inbound client and federation requests (if they are handled separately).

synapse.app.user_dir

+

Deprecated as of Synapse v1.59. Use synapse.app.generic_worker with the +update_user_directory_from_worker option instead.

Handles searches in the user directory. It can handle REST endpoints matching the following regular expressions:

^/_matrix/client/(r0|v3|unstable)/user_directory/search$