mirrors/synapse
mirrors/synapse
1
0
Fork 0
mirror of https://github.com/element-hq/synapse.git synced 2025-03-28 18:38:31 +00:00
Code Activity

deploy: 8a499d7a60

Browse source
This commit is contained in:
reivilibre 2022-06-07 16:00:12 +00:00
parent 98d09b5ec3
commit 31bff6083e
10 changed files with 94 additions and 92 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
latest/admin_api/user_admin_api.html
View file

@ -246,7 +246,9 @@ specific <code>user_id</code>.</p>
<p>Body parameters:</p>
<ul>
<li><code>password</code> - string, optional. If provided, the user's password is updated and all
devices are logged out.</li>
devices are logged out, unless <code>logout_devices</code> is set to <code>false</code>.</li>
<li><code>logout_devices</code> - bool, optional, defaults to <code>true</code>. If set to false, devices aren't
logged out even when <code>password</code> is provided.</li>
<li><code>displayname</code> - string, optional, defaults to the value of <code>user_id</code>.</li>
<li><code>threepids</code> - array, optional, allows setting the third-party IDs (email, msisdn)
<ul>

2
latest/message_retention_policies.html
View file

@ -239,7 +239,7 @@ policy's <code>max_lifetime</code> is greater than a week.</li>
<p>Note that this example is tailored to show different configurations and
features slightly more jobs than it's probably necessary (in practice, a
server admin would probably consider it better to replace the two last
jobs with one that runs once a day and handles rooms which which
jobs with one that runs once a day and handles rooms which
policy's <code>max_lifetime</code> is greater than 3 days).</p>
<p>Keep in mind, when configuring these jobs, that a purge job can become
quite heavy on the server if it targets many rooms, therefore prefer

86
latest/print.html
View file

@ -3579,6 +3579,13 @@ The default value is 10.</p>
<pre><code class="language-yaml">dummy_events_threshold: 5
</code></pre>
<hr />
<p>Config option <code>delete_stale_devices_after</code></p>
<p>An optional duration. If set, Synapse will run a daily background task to log out and
delete any device that hasn't been accessed for more than the specified amount of time.</p>
<p>Defaults to no duration, which means devices are never pruned.</p>
<p>Example configuration:</p>
<pre><code class="language-yaml">delete_stale_devices_after: 1y
</code></pre>
<h2 id="homeserver-blocking"><a class="header" href="#homeserver-blocking">Homeserver blocking</a></h2>
<p>Useful options for Synapse admins.</p>
<hr />
@ -4296,7 +4303,7 @@ into fewer transactions. Defaults to 50. </p>
</code></pre>
<hr />
<h2 id="media-store"><a class="header" href="#media-store">Media Store</a></h2>
<p>Config options relating to Synapse media store.</p>
<p>Config options related to Synapse's media store.</p>
<hr />
<p>Config option: <code>enable_media_repo</code> </p>
<p>Enable the media store service in the Synapse master. Defaults to true.
@ -4381,6 +4388,33 @@ from a precalculated list. Defaults to false. </p>
height: 600
method: scale
</code></pre>
<hr />
<p>Config option: <code>media_retention</code></p>
<p>Controls whether local media and entries in the remote media cache
(media that is downloaded from other homeservers) should be removed
under certain conditions, typically for the purpose of saving space.</p>
<p>Purging media files will be the carried out by the media worker
(that is, the worker that has the <code>enable_media_repo</code> homeserver config
option set to 'true'). This may be the main process.</p>
<p>The <code>media_retention.local_media_lifetime</code> and
<code>media_retention.remote_media_lifetime</code> config options control whether
media will be purged if it has not been accessed in a given amount of
time. Note that media is 'accessed' when loaded in a room in a client, or
otherwise downloaded by a local or remote user. If the media has never
been accessed, the media's creation time is used instead. Both thumbnails
and the original media will be removed. If either of these options are unset,
then media of that type will not be purged.</p>
<p>Local or cached remote media that has been
<a href="usage/configuration/../../admin_api/media_admin_api.html#quarantining-media-in-a-room">quarantined</a>
will not be deleted. Similarly, local media that has been marked as
<a href="usage/configuration/../../admin_api/media_admin_api.html#protecting-media-from-being-quarantined">protected from quarantine</a>
will not be deleted.</p>
<p>Example configuration:</p>
<pre><code class="language-yaml">media_retention:
local_media_lifetime: 90d
remote_media_lifetime: 14d
</code></pre>
<hr />
<p>Config option: <code>url_preview_enabled</code></p>
<p>This setting determines whether the preview URL API is enabled.
It is disabled by default. Set to true to enable. If enabled you must specify a
@ -5778,19 +5812,6 @@ will also not affect rooms created by other servers.</p>
<pre><code class="language-yaml">encryption_enabled_by_default_for_room_type: invite
</code></pre>
<hr />
<p>Config option: <code>enable_group_creation</code></p>
<p>Set to true to allow non-server-admin users to create groups on this server</p>
<p>Example configuration:</p>
<pre><code class="language-yaml">enable_group_creation: true
</code></pre>
<hr />
<p>Config option: <code>group_creation_prefix</code></p>
<p>If enabled/present, non-server admins can only create groups with local parts
starting with this prefix.</p>
<p>Example configuration:</p>
<pre><code class="language-yaml">group_creation_prefix: &quot;unofficial_&quot;
</code></pre>
<hr />
<p>Config option: <code>user_directory</code></p>
<p>This setting defines options related to the user directory. </p>
<p>This option has the following sub-options:</p>
@ -8659,16 +8680,6 @@ push:
# &quot;events_default&quot;: 1
# Uncomment to allow non-server-admin users to create groups on this server
#
#enable_group_creation: true
# If enabled, non server admins can only create groups with local parts
# starting with this prefix
#
#group_creation_prefix: &quot;unofficial_&quot;
# User Directory configuration
#
@ -9123,7 +9134,7 @@ loggers:
</code></pre>
<p>The above logging config will set Synapse as 'INFO' logging level by default,
with the SQL layer at 'WARNING', and will log to a file, stored as JSON.</p>
<p>It is also possible to figure Synapse to log to a remote endpoint by using the
<p>It is also possible to configure Synapse to log to a remote endpoint by using the
<code>synapse.logging.RemoteHandler</code> class included with Synapse. It takes the
following arguments:</p>
<ul>
@ -11056,7 +11067,7 @@ policy's <code>max_lifetime</code> is greater than a week.</li>
<p>Note that this example is tailored to show different configurations and
features slightly more jobs than it's probably necessary (in practice, a
server admin would probably consider it better to replace the two last
jobs with one that runs once a day and handles rooms which which
jobs with one that runs once a day and handles rooms which
policy's <code>max_lifetime</code> is greater than 3 days).</p>
<p>Keep in mind, when configuring these jobs, that a purge job can become
quite heavy on the server if it targets many rooms, therefore prefer
@ -12185,7 +12196,7 @@ changes to the database should now be made by the module using the module API cl
use the new <code>modules</code> section in Synapse's configuration file (see <a href="modules/index.html#using-modules">this section</a>
for more info).</p>
<div style="break-before: page; page-break-before: always;"></div><h1 id="scaling-synapse-via-workers"><a class="header" href="#scaling-synapse-via-workers">Scaling synapse via workers</a></h1>
<p>For small instances it recommended to run Synapse in the default monolith mode.
<p>For small instances it is recommended to run Synapse in the default monolith mode.
For larger instances where performance is a concern it can be helpful to split
out functionality into multiple separate python processes. These processes are
called 'workers', and are (eventually) intended to scale horizontally
@ -12343,9 +12354,8 @@ information.</p>
^/_matrix/federation/v1/event_auth/
^/_matrix/federation/v1/exchange_third_party_invite/
^/_matrix/federation/v1/user/devices/
^/_matrix/federation/v1/get_groups_publicised$
^/_matrix/key/v2/query
^/_matrix/federation/(v1|unstable/org.matrix.msc2946)/hierarchy/
^/_matrix/federation/v1/hierarchy/
# Inbound federation transaction request
^/_matrix/federation/v1/send/
@ -12357,15 +12367,14 @@ information.</p>
^/_matrix/client/(api/v1|r0|v3|unstable)/rooms/.*/context/.*$
^/_matrix/client/(api/v1|r0|v3|unstable)/rooms/.*/members$
^/_matrix/client/(api/v1|r0|v3|unstable)/rooms/.*/state$
^/_matrix/client/(v1|unstable/org.matrix.msc2946)/rooms/.*/hierarchy$
^/_matrix/client/v1/rooms/.*/hierarchy$
^/_matrix/client/unstable/org.matrix.msc2716/rooms/.*/batch_send$
^/_matrix/client/unstable/im.nheko.summary/rooms/.*/summary$
^/_matrix/client/(r0|v3|unstable)/account/3pid$
^/_matrix/client/(r0|v3|unstable)/account/whoami$
^/_matrix/client/(r0|v3|unstable)/devices$
^/_matrix/client/versions$
^/_matrix/client/(api/v1|r0|v3|unstable)/voip/turnServer$
^/_matrix/client/(r0|v3|unstable)/joined_groups$
^/_matrix/client/(r0|v3|unstable)/publicised_groups$
^/_matrix/client/(r0|v3|unstable)/publicised_groups/
^/_matrix/client/(api/v1|r0|v3|unstable)/rooms/.*/event/
^/_matrix/client/(api/v1|r0|v3|unstable)/joined_rooms$
^/_matrix/client/(api/v1|r0|v3|unstable)/search$
@ -12389,9 +12398,6 @@ information.</p>
^/_matrix/client/(api/v1|r0|v3|unstable)/join/
^/_matrix/client/(api/v1|r0|v3|unstable)/profile/
# Device requests
^/_matrix/client/(r0|v3|unstable)/sendToDevice/
# Account data requests
^/_matrix/client/(r0|v3|unstable)/.*/tags
^/_matrix/client/(r0|v3|unstable)/.*/account_data
@ -12407,9 +12413,7 @@ information.</p>
^/_matrix/client/(r0|v3|unstable)/user_directory/search$
</code></pre>
<p>Additionally, the following REST endpoints can be handled for GET requests:</p>
<pre><code>^/_matrix/federation/v1/groups/
^/_matrix/client/(api/v1|r0|v3|unstable)/pushrules/
^/_matrix/client/(r0|v3|unstable)/groups/
<pre><code>^/_matrix/client/(api/v1|r0|v3|unstable)/pushrules/
</code></pre>
<p>Pagination requests can also be handled, but all requests for a given
room must be routed to the same instance. Additionally, care must be taken to
@ -14747,7 +14751,9 @@ specific <code>user_id</code>.</p>
<p>Body parameters:</p>
<ul>
<li><code>password</code> - string, optional. If provided, the user's password is updated and all
devices are logged out.</li>
devices are logged out, unless <code>logout_devices</code> is set to <code>false</code>.</li>
<li><code>logout_devices</code> - bool, optional, defaults to <code>true</code>. If set to false, devices aren't
logged out even when <code>password</code> is provided.</li>
<li><code>displayname</code> - string, optional, defaults to the value of <code>user_id</code>.</li>
<li><code>threepids</code> - array, optional, allows setting the third-party IDs (email, msisdn)
<ul>

10
latest/sample_config.yaml
View file

@ -2523,16 +2523,6 @@ push:
# "events_default": 1
# Uncomment to allow non-server-admin users to create groups on this server
#
#enable_group_creation: true
# If enabled, non server admins can only create groups with local parts
# starting with this prefix
#
#group_creation_prefix: "unofficial_"
# User Directory configuration
#

2
latest/searchindex.js
View file

File diff suppressed because one or more lines are too long

2
latest/searchindex.json
View file

File diff suppressed because one or more lines are too long

2
latest/structured_logging.html
View file

@ -183,7 +183,7 @@ loggers:
</code></pre>
<p>The above logging config will set Synapse as 'INFO' logging level by default,
with the SQL layer at 'WARNING', and will log to a file, stored as JSON.</p>
<p>It is also possible to figure Synapse to log to a remote endpoint by using the
<p>It is also possible to configure Synapse to log to a remote endpoint by using the
<code>synapse.logging.RemoteHandler</code> class included with Synapse. It takes the
following arguments:</p>
<ul>

49
latest/usage/configuration/config_documentation.html
View file

@ -624,6 +624,13 @@ The default value is 10.</p>
<pre><code class="language-yaml">dummy_events_threshold: 5
</code></pre>
<hr />
<p>Config option <code>delete_stale_devices_after</code></p>
<p>An optional duration. If set, Synapse will run a daily background task to log out and
delete any device that hasn't been accessed for more than the specified amount of time.</p>
<p>Defaults to no duration, which means devices are never pruned.</p>
<p>Example configuration:</p>
<pre><code class="language-yaml">delete_stale_devices_after: 1y
</code></pre>
<h2 id="homeserver-blocking"><a class="header" href="#homeserver-blocking">Homeserver blocking</a></h2>
<p>Useful options for Synapse admins.</p>
<hr />
@ -1341,7 +1348,7 @@ into fewer transactions. Defaults to 50. </p>
</code></pre>
<hr />
<h2 id="media-store"><a class="header" href="#media-store">Media Store</a></h2>
<p>Config options relating to Synapse media store.</p>
<p>Config options related to Synapse's media store.</p>
<hr />
<p>Config option: <code>enable_media_repo</code> </p>
<p>Enable the media store service in the Synapse master. Defaults to true.
@ -1426,6 +1433,33 @@ from a precalculated list. Defaults to false. </p>
height: 600
method: scale
</code></pre>
<hr />
<p>Config option: <code>media_retention</code></p>
<p>Controls whether local media and entries in the remote media cache
(media that is downloaded from other homeservers) should be removed
under certain conditions, typically for the purpose of saving space.</p>
<p>Purging media files will be the carried out by the media worker
(that is, the worker that has the <code>enable_media_repo</code> homeserver config
option set to 'true'). This may be the main process.</p>
<p>The <code>media_retention.local_media_lifetime</code> and
<code>media_retention.remote_media_lifetime</code> config options control whether
media will be purged if it has not been accessed in a given amount of
time. Note that media is 'accessed' when loaded in a room in a client, or
otherwise downloaded by a local or remote user. If the media has never
been accessed, the media's creation time is used instead. Both thumbnails
and the original media will be removed. If either of these options are unset,
then media of that type will not be purged.</p>
<p>Local or cached remote media that has been
<a href="../../admin_api/media_admin_api.html#quarantining-media-in-a-room">quarantined</a>
will not be deleted. Similarly, local media that has been marked as
<a href="../../admin_api/media_admin_api.html#protecting-media-from-being-quarantined">protected from quarantine</a>
will not be deleted.</p>
<p>Example configuration:</p>
<pre><code class="language-yaml">media_retention:
local_media_lifetime: 90d
remote_media_lifetime: 14d
</code></pre>
<hr />
<p>Config option: <code>url_preview_enabled</code></p>
<p>This setting determines whether the preview URL API is enabled.
It is disabled by default. Set to true to enable. If enabled you must specify a
@ -2823,19 +2857,6 @@ will also not affect rooms created by other servers.</p>
<pre><code class="language-yaml">encryption_enabled_by_default_for_room_type: invite
</code></pre>
<hr />
<p>Config option: <code>enable_group_creation</code></p>
<p>Set to true to allow non-server-admin users to create groups on this server</p>
<p>Example configuration:</p>
<pre><code class="language-yaml">enable_group_creation: true
</code></pre>
<hr />
<p>Config option: <code>group_creation_prefix</code></p>
<p>If enabled/present, non-server admins can only create groups with local parts
starting with this prefix.</p>
<p>Example configuration:</p>
<pre><code class="language-yaml">group_creation_prefix: &quot;unofficial_&quot;
</code></pre>
<hr />
<p>Config option: <code>user_directory</code></p>
<p>This setting defines options related to the user directory. </p>
<p>This option has the following sub-options:</p>

10
latest/usage/configuration/homeserver_sample_config.html
View file

@ -2679,16 +2679,6 @@ push:
# &quot;events_default&quot;: 1
# Uncomment to allow non-server-admin users to create groups on this server
#
#enable_group_creation: true
# If enabled, non server admins can only create groups with local parts
# starting with this prefix
#
#group_creation_prefix: &quot;unofficial_&quot;
# User Directory configuration
#

19
latest/workers.html
View file

@ -147,7 +147,7 @@
</div>
<h1 id="scaling-synapse-via-workers"><a class="header" href="#scaling-synapse-via-workers">Scaling synapse via workers</a></h1>
<p>For small instances it recommended to run Synapse in the default monolith mode.
<p>For small instances it is recommended to run Synapse in the default monolith mode.
For larger instances where performance is a concern it can be helpful to split
out functionality into multiple separate python processes. These processes are
called 'workers', and are (eventually) intended to scale horizontally
@ -305,9 +305,8 @@ information.</p>
^/_matrix/federation/v1/event_auth/
^/_matrix/federation/v1/exchange_third_party_invite/
^/_matrix/federation/v1/user/devices/
^/_matrix/federation/v1/get_groups_publicised$
^/_matrix/key/v2/query
^/_matrix/federation/(v1|unstable/org.matrix.msc2946)/hierarchy/
^/_matrix/federation/v1/hierarchy/
# Inbound federation transaction request
^/_matrix/federation/v1/send/
@ -319,15 +318,14 @@ information.</p>
^/_matrix/client/(api/v1|r0|v3|unstable)/rooms/.*/context/.*$
^/_matrix/client/(api/v1|r0|v3|unstable)/rooms/.*/members$
^/_matrix/client/(api/v1|r0|v3|unstable)/rooms/.*/state$
^/_matrix/client/(v1|unstable/org.matrix.msc2946)/rooms/.*/hierarchy$
^/_matrix/client/v1/rooms/.*/hierarchy$
^/_matrix/client/unstable/org.matrix.msc2716/rooms/.*/batch_send$
^/_matrix/client/unstable/im.nheko.summary/rooms/.*/summary$
^/_matrix/client/(r0|v3|unstable)/account/3pid$
^/_matrix/client/(r0|v3|unstable)/account/whoami$
^/_matrix/client/(r0|v3|unstable)/devices$
^/_matrix/client/versions$
^/_matrix/client/(api/v1|r0|v3|unstable)/voip/turnServer$
^/_matrix/client/(r0|v3|unstable)/joined_groups$
^/_matrix/client/(r0|v3|unstable)/publicised_groups$
^/_matrix/client/(r0|v3|unstable)/publicised_groups/
^/_matrix/client/(api/v1|r0|v3|unstable)/rooms/.*/event/
^/_matrix/client/(api/v1|r0|v3|unstable)/joined_rooms$
^/_matrix/client/(api/v1|r0|v3|unstable)/search$
@ -351,9 +349,6 @@ information.</p>
^/_matrix/client/(api/v1|r0|v3|unstable)/join/
^/_matrix/client/(api/v1|r0|v3|unstable)/profile/
# Device requests
^/_matrix/client/(r0|v3|unstable)/sendToDevice/
# Account data requests
^/_matrix/client/(r0|v3|unstable)/.*/tags
^/_matrix/client/(r0|v3|unstable)/.*/account_data
@ -369,9 +364,7 @@ information.</p>
^/_matrix/client/(r0|v3|unstable)/user_directory/search$
</code></pre>
<p>Additionally, the following REST endpoints can be handled for GET requests:</p>
<pre><code>^/_matrix/federation/v1/groups/
^/_matrix/client/(api/v1|r0|v3|unstable)/pushrules/
^/_matrix/client/(r0|v3|unstable)/groups/
<pre><code>^/_matrix/client/(api/v1|r0|v3|unstable)/pushrules/
</code></pre>
<p>Pagination requests can also be handled, but all requests for a given
room must be routed to the same instance. Additionally, care must be taken to