diff --git a/latest/print.html b/latest/print.html
index a034ec9dc0..8b5ea5623c 100644
--- a/latest/print.html
+++ b/latest/print.html
@@ -101,7 +101,7 @@
<nav id="sidebar" class="sidebar" aria-label="Table of contents">
<div class="sidebar-scrollbox">
- <ol class="chapter"><li class="chapter-item expanded affix "><li class="part-title">Introduction</li><li class="chapter-item expanded "><a href="welcome_and_overview.html">Welcome and Overview</a></li><li class="chapter-item expanded affix "><li class="part-title">Setup</li><li class="chapter-item expanded "><a href="setup/installation.html">Installation</a></li><li class="chapter-item expanded "><a href="postgres.html">Using Postgres</a></li><li class="chapter-item expanded "><a href="reverse_proxy.html">Configuring a Reverse Proxy</a></li><li class="chapter-item expanded "><a href="setup/forward_proxy.html">Configuring a Forward/Outbound Proxy</a></li><li class="chapter-item expanded "><a href="turn-howto.html">Configuring a Turn Server</a></li><li class="chapter-item expanded "><a href="delegate.html">Delegation</a></li><li class="chapter-item expanded affix "><li class="part-title">Upgrading</li><li class="chapter-item expanded "><a href="upgrade.html">Upgrading between Synapse Versions</a></li><li class="chapter-item expanded "><a href="MSC1711_certificates_FAQ.html">Upgrading from pre-Synapse 1.0</a></li><li class="chapter-item expanded affix "><li class="part-title">Usage</li><li class="chapter-item expanded "><a href="federate.html">Federation</a></li><li class="chapter-item expanded "><a href="usage/configuration/index.html">Configuration</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="usage/configuration/homeserver_sample_config.html">Homeserver Sample Config File</a></li><li class="chapter-item expanded "><a href="usage/configuration/logging_sample_config.html">Logging Sample Config File</a></li><li class="chapter-item expanded "><a href="structured_logging.html">Structured Logging</a></li><li class="chapter-item expanded "><a href="templates.html">Templates</a></li><li class="chapter-item expanded "><a href="usage/configuration/user_authentication/index.html">User Authentication</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="usage/configuration/user_authentication/single_sign_on/index.html">Single-Sign On</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="openid.html">OpenID Connect</a></li><li class="chapter-item expanded "><a href="usage/configuration/user_authentication/single_sign_on/saml.html">SAML</a></li><li class="chapter-item expanded "><a href="usage/configuration/user_authentication/single_sign_on/cas.html">CAS</a></li><li class="chapter-item expanded "><a href="sso_mapping_providers.html">SSO Mapping Providers</a></li></ol></li><li class="chapter-item expanded "><a href="password_auth_providers.html">Password Auth Providers</a></li><li class="chapter-item expanded "><a href="jwt.html">JSON Web Tokens</a></li><li class="chapter-item expanded "><a href="usage/configuration/user_authentication/refresh_tokens.html">Refresh Tokens</a></li></ol></li><li class="chapter-item expanded "><a href="CAPTCHA_SETUP.html">Registration Captcha</a></li><li class="chapter-item expanded "><a href="application_services.html">Application Services</a></li><li class="chapter-item expanded "><a href="server_notices.html">Server Notices</a></li><li class="chapter-item expanded "><a href="consent_tracking.html">Consent Tracking</a></li><li class="chapter-item expanded "><a href="development/url_previews.html">URL Previews</a></li><li class="chapter-item expanded "><a href="user_directory.html">User Directory</a></li><li class="chapter-item expanded "><a href="message_retention_policies.html">Message Retention Policies</a></li><li class="chapter-item expanded "><a href="modules/index.html">Pluggable Modules</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="modules/writing_a_module.html">Writing a module</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="modules/spam_checker_callbacks.html">Spam checker callbacks</a></li><li class="chapter-item expanded "><a href="modules/third_party_rules_callbacks.html">Third-party rules callbacks</a></li><li class="chapter-item expanded "><a href="modules/presence_router_callbacks.html">Presence router callbacks</a></li><li class="chapter-item expanded "><a href="modules/account_validity_callbacks.html">Account validity callbacks</a></li><li class="chapter-item expanded "><a href="modules/password_auth_provider_callbacks.html">Password auth provider callbacks</a></li><li class="chapter-item expanded "><a href="modules/background_update_controller_callbacks.html">Background update controller callbacks</a></li><li class="chapter-item expanded "><a href="modules/porting_legacy_module.html">Porting a legacy module to the new interface</a></li></ol></li></ol></li><li class="chapter-item expanded "><a href="workers.html">Workers</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="synctl_workers.html">Using synctl with Workers</a></li><li class="chapter-item expanded "><a href="systemd-with-workers/index.html">Systemd</a></li></ol></li></ol></li><li class="chapter-item expanded "><a href="usage/administration/index.html">Administration</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="usage/administration/admin_api/index.html">Admin API</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="admin_api/account_validity.html">Account Validity</a></li><li class="chapter-item expanded "><a href="usage/administration/admin_api/background_updates.html">Background Updates</a></li><li class="chapter-item expanded "><a href="admin_api/delete_group.html">Delete Group</a></li><li class="chapter-item expanded "><a href="admin_api/event_reports.html">Event Reports</a></li><li class="chapter-item expanded "><a href="admin_api/media_admin_api.html">Media</a></li><li class="chapter-item expanded "><a href="admin_api/purge_history_api.html">Purge History</a></li><li class="chapter-item expanded "><a href="admin_api/register_api.html">Register Users</a></li><li class="chapter-item expanded "><a href="usage/administration/admin_api/registration_tokens.html">Registration Tokens</a></li><li class="chapter-item expanded "><a href="admin_api/room_membership.html">Manipulate Room Membership</a></li><li class="chapter-item expanded "><a href="admin_api/rooms.html">Rooms</a></li><li class="chapter-item expanded "><a href="admin_api/server_notices.html">Server Notices</a></li><li class="chapter-item expanded "><a href="admin_api/statistics.html">Statistics</a></li><li class="chapter-item expanded "><a href="admin_api/user_admin_api.html">Users</a></li><li class="chapter-item expanded "><a href="admin_api/version_api.html">Server Version</a></li><li class="chapter-item expanded "><a href="usage/administration/admin_api/federation.html">Federation</a></li></ol></li><li class="chapter-item expanded "><a href="manhole.html">Manhole</a></li><li class="chapter-item expanded "><a href="metrics-howto.html">Monitoring</a></li><li class="chapter-item expanded "><a href="usage/administration/understanding_synapse_through_grafana_graphs.html">Understanding Synapse Through Grafana Graphs</a></li><li class="chapter-item expanded "><a href="usage/administration/useful_sql_for_admins.html">Useful SQL for Admins</a></li><li class="chapter-item expanded "><a href="usage/administration/database_maintenance_tools.html">Database Maintenance Tools</a></li><li class="chapter-item expanded "><a href="usage/administration/state_groups.html">State Groups</a></li><li class="chapter-item expanded "><a href="usage/administration/request_log.html">Request log format</a></li><li class="chapter-item expanded "><a href="usage/administration/admin_faq.html">Admin FAQ</a></li><li class="chapter-item expanded "><div>Scripts</div></li></ol></li><li class="chapter-item expanded "><li class="part-title">Development</li><li class="chapter-item expanded "><a href="development/contributing_guide.html">Contributing Guide</a></li><li class="chapter-item expanded "><a href="code_style.html">Code Style</a></li><li class="chapter-item expanded "><a href="development/git.html">Git Usage</a></li><li class="chapter-item expanded "><div>Testing</div></li><li class="chapter-item expanded "><a href="opentracing.html">OpenTracing</a></li><li class="chapter-item expanded "><a href="development/database_schema.html">Database Schemas</a></li><li class="chapter-item expanded "><a href="development/experimental_features.html">Experimental features</a></li><li class="chapter-item expanded "><div>Synapse Architecture</div></li><li><ol class="section"><li class="chapter-item expanded "><a href="log_contexts.html">Log Contexts</a></li><li class="chapter-item expanded "><a href="replication.html">Replication</a></li><li class="chapter-item expanded "><a href="tcp_replication.html">TCP Replication</a></li></ol></li><li class="chapter-item expanded "><a href="development/internal_documentation/index.html">Internal Documentation</a></li><li><ol class="section"><li class="chapter-item expanded "><div>Single Sign-On</div></li><li><ol class="section"><li class="chapter-item expanded "><a href="development/saml.html">SAML</a></li><li class="chapter-item expanded "><a href="development/cas.html">CAS</a></li></ol></li><li class="chapter-item expanded "><a href="development/room-dag-concepts.html">Room DAG concepts</a></li><li class="chapter-item expanded "><div>State Resolution</div></li><li><ol class="section"><li class="chapter-item expanded "><a href="auth_chain_difference_algorithm.html">The Auth Chain Difference Algorithm</a></li></ol></li><li class="chapter-item expanded "><a href="media_repository.html">Media Repository</a></li><li class="chapter-item expanded "><a href="room_and_user_statistics.html">Room and User Statistics</a></li></ol></li><li class="chapter-item expanded "><div>Scripts</div></li><li class="chapter-item expanded affix "><li class="part-title">Other</li><li class="chapter-item expanded "><a href="deprecation_policy.html">Dependency Deprecation Policy</a></li><li class="chapter-item expanded "><a href="other/running_synapse_on_single_board_computers.html">Running Synapse on a Single-Board Computer</a></li></ol>
+ <ol class="chapter"><li class="chapter-item expanded affix "><li class="part-title">Introduction</li><li class="chapter-item expanded "><a href="welcome_and_overview.html">Welcome and Overview</a></li><li class="chapter-item expanded affix "><li class="part-title">Setup</li><li class="chapter-item expanded "><a href="setup/installation.html">Installation</a></li><li class="chapter-item expanded "><a href="postgres.html">Using Postgres</a></li><li class="chapter-item expanded "><a href="reverse_proxy.html">Configuring a Reverse Proxy</a></li><li class="chapter-item expanded "><a href="setup/forward_proxy.html">Configuring a Forward/Outbound Proxy</a></li><li class="chapter-item expanded "><a href="turn-howto.html">Configuring a Turn Server</a></li><li class="chapter-item expanded "><a href="delegate.html">Delegation</a></li><li class="chapter-item expanded affix "><li class="part-title">Upgrading</li><li class="chapter-item expanded "><a href="upgrade.html">Upgrading between Synapse Versions</a></li><li class="chapter-item expanded affix "><li class="part-title">Usage</li><li class="chapter-item expanded "><a href="federate.html">Federation</a></li><li class="chapter-item expanded "><a href="usage/configuration/index.html">Configuration</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="usage/configuration/homeserver_sample_config.html">Homeserver Sample Config File</a></li><li class="chapter-item expanded "><a href="usage/configuration/logging_sample_config.html">Logging Sample Config File</a></li><li class="chapter-item expanded "><a href="structured_logging.html">Structured Logging</a></li><li class="chapter-item expanded "><a href="templates.html">Templates</a></li><li class="chapter-item expanded "><a href="usage/configuration/user_authentication/index.html">User Authentication</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="usage/configuration/user_authentication/single_sign_on/index.html">Single-Sign On</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="openid.html">OpenID Connect</a></li><li class="chapter-item expanded "><a href="usage/configuration/user_authentication/single_sign_on/saml.html">SAML</a></li><li class="chapter-item expanded "><a href="usage/configuration/user_authentication/single_sign_on/cas.html">CAS</a></li><li class="chapter-item expanded "><a href="sso_mapping_providers.html">SSO Mapping Providers</a></li></ol></li><li class="chapter-item expanded "><a href="password_auth_providers.html">Password Auth Providers</a></li><li class="chapter-item expanded "><a href="jwt.html">JSON Web Tokens</a></li><li class="chapter-item expanded "><a href="usage/configuration/user_authentication/refresh_tokens.html">Refresh Tokens</a></li></ol></li><li class="chapter-item expanded "><a href="CAPTCHA_SETUP.html">Registration Captcha</a></li><li class="chapter-item expanded "><a href="application_services.html">Application Services</a></li><li class="chapter-item expanded "><a href="server_notices.html">Server Notices</a></li><li class="chapter-item expanded "><a href="consent_tracking.html">Consent Tracking</a></li><li class="chapter-item expanded "><a href="development/url_previews.html">URL Previews</a></li><li class="chapter-item expanded "><a href="user_directory.html">User Directory</a></li><li class="chapter-item expanded "><a href="message_retention_policies.html">Message Retention Policies</a></li><li class="chapter-item expanded "><a href="modules/index.html">Pluggable Modules</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="modules/writing_a_module.html">Writing a module</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="modules/spam_checker_callbacks.html">Spam checker callbacks</a></li><li class="chapter-item expanded "><a href="modules/third_party_rules_callbacks.html">Third-party rules callbacks</a></li><li class="chapter-item expanded "><a href="modules/presence_router_callbacks.html">Presence router callbacks</a></li><li class="chapter-item expanded "><a href="modules/account_validity_callbacks.html">Account validity callbacks</a></li><li class="chapter-item expanded "><a href="modules/password_auth_provider_callbacks.html">Password auth provider callbacks</a></li><li class="chapter-item expanded "><a href="modules/background_update_controller_callbacks.html">Background update controller callbacks</a></li><li class="chapter-item expanded "><a href="modules/porting_legacy_module.html">Porting a legacy module to the new interface</a></li></ol></li></ol></li><li class="chapter-item expanded "><a href="workers.html">Workers</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="synctl_workers.html">Using synctl with Workers</a></li><li class="chapter-item expanded "><a href="systemd-with-workers/index.html">Systemd</a></li></ol></li></ol></li><li class="chapter-item expanded "><a href="usage/administration/index.html">Administration</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="usage/administration/admin_api/index.html">Admin API</a></li><li><ol class="section"><li class="chapter-item expanded "><a href="admin_api/account_validity.html">Account Validity</a></li><li class="chapter-item expanded "><a href="usage/administration/admin_api/background_updates.html">Background Updates</a></li><li class="chapter-item expanded "><a href="admin_api/delete_group.html">Delete Group</a></li><li class="chapter-item expanded "><a href="admin_api/event_reports.html">Event Reports</a></li><li class="chapter-item expanded "><a href="admin_api/media_admin_api.html">Media</a></li><li class="chapter-item expanded "><a href="admin_api/purge_history_api.html">Purge History</a></li><li class="chapter-item expanded "><a href="admin_api/register_api.html">Register Users</a></li><li class="chapter-item expanded "><a href="usage/administration/admin_api/registration_tokens.html">Registration Tokens</a></li><li class="chapter-item expanded "><a href="admin_api/room_membership.html">Manipulate Room Membership</a></li><li class="chapter-item expanded "><a href="admin_api/rooms.html">Rooms</a></li><li class="chapter-item expanded "><a href="admin_api/server_notices.html">Server Notices</a></li><li class="chapter-item expanded "><a href="admin_api/statistics.html">Statistics</a></li><li class="chapter-item expanded "><a href="admin_api/user_admin_api.html">Users</a></li><li class="chapter-item expanded "><a href="admin_api/version_api.html">Server Version</a></li><li class="chapter-item expanded "><a href="usage/administration/admin_api/federation.html">Federation</a></li></ol></li><li class="chapter-item expanded "><a href="manhole.html">Manhole</a></li><li class="chapter-item expanded "><a href="metrics-howto.html">Monitoring</a></li><li class="chapter-item expanded "><a href="usage/administration/understanding_synapse_through_grafana_graphs.html">Understanding Synapse Through Grafana Graphs</a></li><li class="chapter-item expanded "><a href="usage/administration/useful_sql_for_admins.html">Useful SQL for Admins</a></li><li class="chapter-item expanded "><a href="usage/administration/database_maintenance_tools.html">Database Maintenance Tools</a></li><li class="chapter-item expanded "><a href="usage/administration/state_groups.html">State Groups</a></li><li class="chapter-item expanded "><a href="usage/administration/request_log.html">Request log format</a></li><li class="chapter-item expanded "><a href="usage/administration/admin_faq.html">Admin FAQ</a></li><li class="chapter-item expanded "><div>Scripts</div></li></ol></li><li class="chapter-item expanded "><li class="part-title">Development</li><li class="chapter-item expanded "><a href="development/contributing_guide.html">Contributing Guide</a></li><li class="chapter-item expanded "><a href="code_style.html">Code Style</a></li><li class="chapter-item expanded "><a href="development/releases.html">Release Cycle</a></li><li class="chapter-item expanded "><a href="development/git.html">Git Usage</a></li><li class="chapter-item expanded "><div>Testing</div></li><li class="chapter-item expanded "><a href="opentracing.html">OpenTracing</a></li><li class="chapter-item expanded "><a href="development/database_schema.html">Database Schemas</a></li><li class="chapter-item expanded "><a href="development/experimental_features.html">Experimental features</a></li><li class="chapter-item expanded "><div>Synapse Architecture</div></li><li><ol class="section"><li class="chapter-item expanded "><a href="log_contexts.html">Log Contexts</a></li><li class="chapter-item expanded "><a href="replication.html">Replication</a></li><li class="chapter-item expanded "><a href="tcp_replication.html">TCP Replication</a></li></ol></li><li class="chapter-item expanded "><a href="development/internal_documentation/index.html">Internal Documentation</a></li><li><ol class="section"><li class="chapter-item expanded "><div>Single Sign-On</div></li><li><ol class="section"><li class="chapter-item expanded "><a href="development/saml.html">SAML</a></li><li class="chapter-item expanded "><a href="development/cas.html">CAS</a></li></ol></li><li class="chapter-item expanded "><a href="development/room-dag-concepts.html">Room DAG concepts</a></li><li class="chapter-item expanded "><div>State Resolution</div></li><li><ol class="section"><li class="chapter-item expanded "><a href="auth_chain_difference_algorithm.html">The Auth Chain Difference Algorithm</a></li></ol></li><li class="chapter-item expanded "><a href="media_repository.html">Media Repository</a></li><li class="chapter-item expanded "><a href="room_and_user_statistics.html">Room and User Statistics</a></li></ol></li><li class="chapter-item expanded "><div>Scripts</div></li><li class="chapter-item expanded affix "><li class="part-title">Other</li><li class="chapter-item expanded "><a href="deprecation_policy.html">Dependency Deprecation Policy</a></li><li class="chapter-item expanded "><a href="other/running_synapse_on_single_board_computers.html">Running Synapse on a Single-Board Computer</a></li></ol>
</div>
<div id="sidebar-resize-handle" class="sidebar-resize-handle"></div>
</nav>
@@ -1638,6 +1638,52 @@ dpkg -i matrix-synapse-py3_1.3.0+stretch1_amd64.deb
</code></pre>
</li>
</ul>
+<h1 id="upgrading-to-v1530"><a class="header" href="#upgrading-to-v1530">Upgrading to v1.53.0</a></h1>
+<h2 id="dropping-support-for-webclient-listeners-and-non-https-web_client_location"><a class="header" href="#dropping-support-for-webclient-listeners-and-non-https-web_client_location">Dropping support for <code>webclient</code> listeners and non-HTTP(S) <code>web_client_location</code></a></h2>
+<p>Per the deprecation notice in Synapse v1.51.0, listeners of type <code>webclient</code>
+are no longer supported and configuring them is a now a configuration error.</p>
+<p>Configuring a non-HTTP(S) <code>web_client_location</code> configuration is is now a
+configuration error. Since the <code>webclient</code> listener is no longer supported, this
+setting only applies to the root path <code>/</code> of Synapse's web server and no longer
+the <code>/_matrix/client/</code> path.</p>
+<h2 id="stablisation-of-msc3231"><a class="header" href="#stablisation-of-msc3231">Stablisation of MSC3231</a></h2>
+<p>The unstable validity-check endpoint for the
+<a href="https://spec.matrix.org/v1.2/client-server-api/#get_matrixclientv1registermloginregistration_tokenvalidity">Registration Tokens</a>
+feature has been stabilised and moved from:</p>
+<p><code>/_matrix/client/unstable/org.matrix.msc3231/register/org.matrix.msc3231.login.registration_token/validity</code></p>
+<p>to:</p>
+<p><code>/_matrix/client/v1/register/m.login.registration_token/validity</code></p>
+<p>Please update any relevant reverse proxy or firewall configurations appropriately.</p>
+<h2 id="time-based-cache-expiry-is-now-enabled-by-default"><a class="header" href="#time-based-cache-expiry-is-now-enabled-by-default">Time-based cache expiry is now enabled by default</a></h2>
+<p>Formerly, entries in the cache were not evicted regardless of whether they were accessed after storing.
+This behavior has now changed. By default entries in the cache are now evicted after 30m of not being accessed.
+To change the default behavior, go to the <code>caches</code> section of the config and change the <code>expire_caches</code> and
+<code>cache_entry_ttl</code> flags as necessary. Please note that these flags replace the <code>expiry_time</code> flag in the config.<br />
+The <code>expiry_time</code> flag will still continue to work, but it has been deprecated and will be removed in the future.</p>
+<h2 id="deprecation-of-capability-orgmatrixmsc3283"><a class="header" href="#deprecation-of-capability-orgmatrixmsc3283">Deprecation of <code>capability</code> <code>org.matrix.msc3283.*</code></a></h2>
+<p>The <code>capabilities</code> of MSC3283 from the REST API <code>/_matrix/client/r0/capabilities</code>
+becomes stable.</p>
+<p>The old <code>capabilities</code></p>
+<ul>
+<li><code>org.matrix.msc3283.set_displayname</code>,</li>
+<li><code>org.matrix.msc3283.set_avatar_url</code> and</li>
+<li><code>org.matrix.msc3283.3pid_changes</code></li>
+</ul>
+<p>are deprecated and scheduled to be removed in Synapse v1.54.0.</p>
+<p>The new <code>capabilities</code></p>
+<ul>
+<li><code>m.set_displayname</code>,</li>
+<li><code>m.set_avatar_url</code> and</li>
+<li><code>m.3pid_changes</code></li>
+</ul>
+<p>are now active by default.</p>
+<h2 id="removal-of-user_may_create_room_with_invites"><a class="header" href="#removal-of-user_may_create_room_with_invites">Removal of <code>user_may_create_room_with_invites</code></a></h2>
+<p>As announced with the release of <a href="upgrade.html#deprecation-of-the-user_may_create_room_with_invites-module-callback">Synapse 1.47.0</a>,
+the deprecated <code>user_may_create_room_with_invites</code> module callback has been removed.</p>
+<p>Modules relying on it can instead implement <a href="https://matrix-org.github.io/synapse/latest/modules/spam_checker_callbacks.html#user_may_invite"><code>user_may_invite</code></a>
+and use the <a href="https://github.com/matrix-org/synapse/blob/872f23b95fa980a61b0866c1475e84491991fa20/synapse/module_api/__init__.py#L869-L876"><code>get_room_state</code></a>
+module API to infer whether the invite is happening while creating a room (see <a href="https://github.com/matrix-org/synapse-domain-rule-checker/blob/e7d092dd9f2a7f844928771dbfd9fd24c2332e48/synapse_domain_rule_checker/__init__.py#L56-L89">this function</a>
+as an example). Alternately, modules can also implement <a href="https://matrix-org.github.io/synapse/latest/modules/third_party_rules_callbacks.html#on_create_room"><code>on_create_room</code></a>.</p>
<h1 id="upgrading-to-v1520"><a class="header" href="#upgrading-to-v1520">Upgrading to v1.52.0</a></h1>
<h2 id="twisted-security-release"><a class="header" href="#twisted-security-release">Twisted security release</a></h2>
<p>Note that <a href="https://github.com/twisted/twisted/releases/tag/twisted-22.1.0">Twisted 22.1.0</a>
@@ -2463,8 +2509,7 @@ more details on upgrading your database.</p>
<h2 id="validation-of-tls-certificates"><a class="header" href="#validation-of-tls-certificates">Validation of TLS certificates</a></h2>
<p>Synapse v1.0 is the first release to enforce validation of TLS
certificates for the federation API. It is therefore essential that your
-certificates are correctly configured. See the
-<a href="MSC1711_certificates_FAQ.html">FAQ</a> for more information.</p>
+certificates are correctly configured.</p>
<p>Note, v1.0 installations will also no longer be able to federate with
servers that have not correctly configured their certificates.</p>
<p>In rare cases, it may be desirable to disable certificate checking: for
@@ -2514,8 +2559,6 @@ sent to them.</p>
you will need to replace any self-signed certificates with those
verified by a root CA. Information on how to do so can be found at the
ACME docs.</p>
-<p>For more information on configuring TLS certificates see the
-<a href="MSC1711_certificates_FAQ.html">FAQ</a>.</p>
<h1 id="upgrading-to-v0340"><a class="header" href="#upgrading-to-v0340">Upgrading to v0.34.0</a></h1>
<ol>
<li>
@@ -2804,257 +2847,6 @@ longer to restart than usual as it reinitializes the database.</p>
using room aliases or by being reinvited. Alternatively, if any other
homeserver sends a message to a room that the homeserver was previously
in the local HS will automatically rejoin the room.</p>
-<div id="chapter_begin" style="break-before: page; page-break-before: always;"></div><h1 id="msc1711-certificates-faq"><a class="header" href="#msc1711-certificates-faq">MSC1711 Certificates FAQ</a></h1>
-<h2 id="historical-note"><a class="header" href="#historical-note">Historical Note</a></h2>
-<p>This document was originally written to guide server admins through the upgrade
-path towards Synapse 1.0. Specifically,
-<a href="https://github.com/matrix-org/matrix-doc/blob/main/proposals/1711-x509-for-federation.md">MSC1711</a>
-required that all servers present valid TLS certificates on their federation
-API. Admins were encouraged to achieve compliance from version 0.99.0 (released
-in February 2019) ahead of version 1.0 (released June 2019) enforcing the
-certificate checks.</p>
-<p>Much of what follows is now outdated since most admins will have already
-upgraded, however it may be of use to those with old installs returning to the
-project.</p>
-<p>If you are setting up a server from scratch you almost certainly should look at
-the <a href="setup/installation.html">installation guide</a> instead.</p>
-<h2 id="introduction-1"><a class="header" href="#introduction-1">Introduction</a></h2>
-<p>The goal of Synapse 0.99.0 is to act as a stepping stone to Synapse 1.0.0. It
-supports the r0.1 release of the server to server specification, but is
-compatible with both the legacy Matrix federation behaviour (pre-r0.1) as well
-as post-r0.1 behaviour, in order to allow for a smooth upgrade across the
-federation.</p>
-<p>The most important thing to know is that Synapse 1.0.0 will require a valid TLS
-certificate on federation endpoints. Self signed certificates will not be
-sufficient.</p>
-<p>Synapse 0.99.0 makes it easy to configure TLS certificates and will
-interoperate with both >= 1.0.0 servers as well as existing servers yet to
-upgrade.</p>
-<p><strong>It is critical that all admins upgrade to 0.99.0 and configure a valid TLS
-certificate.</strong> Admins will have 1 month to do so, after which 1.0.0 will be
-released and those servers without a valid certificate will not longer be able
-to federate with >= 1.0.0 servers.</p>
-<p>Full details on how to carry out this configuration change is given
-<a href="MSC1711_certificates_FAQ.html#configuring-certificates-for-compatibility-with-synapse-100">below</a>. A
-timeline and some frequently asked questions are also given below.</p>
-<p>For more details and context on the release of the r0.1 Server/Server API and
-imminent Matrix 1.0 release, you can also see our
-<a href="https://matrix.org/blog/2019/02/04/matrix-at-fosdem-2019/">main talk from FOSDEM 2019</a>.</p>
-<h2 id="timeline"><a class="header" href="#timeline">Timeline</a></h2>
-<p><strong>5th Feb 2019 - Synapse 0.99.0 is released.</strong></p>
-<p>All server admins are encouraged to upgrade.</p>
-<p>0.99.0:</p>
-<ul>
-<li>
-<p>provides support for ACME to make setting up Let's Encrypt certs easy, as
-well as .well-known support.</p>
-</li>
-<li>
-<p>does not enforce that a valid CA cert is present on the federation API, but
-rather makes it easy to set one up.</p>
-</li>
-<li>
-<p>provides support for .well-known</p>
-</li>
-</ul>
-<p>Admins should upgrade and configure a valid CA cert. Homeservers that require a
-.well-known entry (see below), should retain their SRV record and use it
-alongside their .well-known record.</p>
-<p><strong>10th June 2019 - Synapse 1.0.0 is released</strong></p>
-<p>1.0.0 is scheduled for release on 10th June. In
-accordance with the the <a href="https://matrix.org/docs/spec/server_server/r0.1.0.html">S2S spec</a>
-1.0.0 will enforce certificate validity. This means that any homeserver without a
-valid certificate after this point will no longer be able to federate with
-1.0.0 servers.</p>
-<h2 id="configuring-certificates-for-compatibility-with-synapse-100"><a class="header" href="#configuring-certificates-for-compatibility-with-synapse-100">Configuring certificates for compatibility with Synapse 1.0.0</a></h2>
-<h3 id="if-you-do-not-currently-have-an-srv-record"><a class="header" href="#if-you-do-not-currently-have-an-srv-record">If you do not currently have an SRV record</a></h3>
-<p>In this case, your <code>server_name</code> points to the host where your Synapse is
-running. There is no need to create a <code>.well-known</code> URI or an SRV record, but
-you will need to give Synapse a valid, signed, certificate.</p>
-<h3 id="if-you-do-have-an-srv-record-currently"><a class="header" href="#if-you-do-have-an-srv-record-currently">If you do have an SRV record currently</a></h3>
-<p>If you are using an SRV record, your matrix domain (<code>server_name</code>) may not
-point to the same host that your Synapse is running on (the 'target
-domain'). (If it does, you can follow the recommendation above; otherwise, read
-on.)</p>
-<p>Let's assume that your <code>server_name</code> is <code>example.com</code>, and your Synapse is
-hosted at a target domain of <code>customer.example.net</code>. Currently you should have
-an SRV record which looks like:</p>
-<pre><code>_matrix._tcp.example.com. IN SRV 10 5 8000 customer.example.net.
-</code></pre>
-<p>In this situation, you have three choices for how to proceed:</p>
-<h4 id="option-1-give-synapse-a-certificate-for-your-matrix-domain"><a class="header" href="#option-1-give-synapse-a-certificate-for-your-matrix-domain">Option 1: give Synapse a certificate for your matrix domain</a></h4>
-<p>Synapse 1.0 will expect your server to present a TLS certificate for your
-<code>server_name</code> (<code>example.com</code> in the above example). You can achieve this by acquiring a
-certificate for the <code>server_name</code> yourself (for example, using <code>certbot</code>), and giving it
-and the key to Synapse via <code>tls_certificate_path</code> and <code>tls_private_key_path</code>.</p>
-<h4 id="option-2-run-synapse-behind-a-reverse-proxy"><a class="header" href="#option-2-run-synapse-behind-a-reverse-proxy">Option 2: run Synapse behind a reverse proxy</a></h4>
-<p>If you have an existing reverse proxy set up with correct TLS certificates for
-your domain, you can simply route all traffic through the reverse proxy by
-updating the SRV record appropriately (or removing it, if the proxy listens on
-8448).</p>
-<p>See <a href="reverse_proxy.html">the reverse proxy documentation</a> for information on setting up a
-reverse proxy.</p>
-<h4 id="option-3-add-a-well-known-file-to-delegate-your-matrix-traffic"><a class="header" href="#option-3-add-a-well-known-file-to-delegate-your-matrix-traffic">Option 3: add a .well-known file to delegate your matrix traffic</a></h4>
-<p>This will allow you to keep Synapse on a separate domain, without having to
-give it a certificate for the matrix domain.</p>
-<p>You can do this with a <code>.well-known</code> file as follows:</p>
-<ol>
-<li>
-<p>Keep the SRV record in place - it is needed for backwards compatibility
-with Synapse 0.34 and earlier.</p>
-</li>
-<li>
-<p>Give Synapse a certificate corresponding to the target domain
-(<code>customer.example.net</code> in the above example). You can do this by acquire a
-certificate for the target domain and giving it to Synapse via <code>tls_certificate_path</code>
-and <code>tls_private_key_path</code>.</p>
-</li>
-<li>
-<p>Restart Synapse to ensure the new certificate is loaded.</p>
-</li>
-<li>
-<p>Arrange for a <code>.well-known</code> file at
-<code>https://<server_name>/.well-known/matrix/server</code> with contents:</p>
-<pre><code class="language-json">{"m.server": "<target server name>"}
-</code></pre>
-<p>where the target server name is resolved as usual (i.e. SRV lookup, falling
-back to talking to port 8448).</p>
-<p>In the above example, where synapse is listening on port 8000,
-<code>https://example.com/.well-known/matrix/server</code> should have <code>m.server</code> set to one of:</p>
-<ol>
-<li>
-<p><code>customer.example.net</code> ─ with a SRV record on
-<code>_matrix._tcp.customer.example.com</code> pointing to port 8000, or:</p>
-</li>
-<li>
-<p><code>customer.example.net</code> ─ updating synapse to listen on the default port
-8448, or:</p>
-</li>
-<li>
-<p><code>customer.example.net:8000</code> ─ ensuring that if there is a reverse proxy
-on <code>customer.example.net:8000</code> it correctly handles HTTP requests with
-Host header set to <code>customer.example.net:8000</code>.</p>
-</li>
-</ol>
-</li>
-</ol>
-<h2 id="faq"><a class="header" href="#faq">FAQ</a></h2>
-<h3 id="synapse-0990-has-just-been-released-what-do-i-need-to-do-right-now"><a class="header" href="#synapse-0990-has-just-been-released-what-do-i-need-to-do-right-now">Synapse 0.99.0 has just been released, what do I need to do right now?</a></h3>
-<p>Upgrade as soon as you can in preparation for Synapse 1.0.0, and update your
-TLS certificates as <a href="MSC1711_certificates_FAQ.html#configuring-certificates-for-compatibility-with-synapse-100">above</a>.</p>
-<h3 id="what-will-happen-if-i-do-not-set-up-a-valid-federation-certificate-immediately"><a class="header" href="#what-will-happen-if-i-do-not-set-up-a-valid-federation-certificate-immediately">What will happen if I do not set up a valid federation certificate immediately?</a></h3>
-<p>Nothing initially, but once 1.0.0 is in the wild it will not be possible to
-federate with 1.0.0 servers.</p>
-<h3 id="what-will-happen-if-i-do-nothing-at-all"><a class="header" href="#what-will-happen-if-i-do-nothing-at-all">What will happen if I do nothing at all?</a></h3>
-<p>If the admin takes no action at all, and remains on a Synapse < 0.99.0 then the
-homeserver will be unable to federate with those who have implemented
-.well-known. Then, as above, once the month upgrade window has expired the
-homeserver will not be able to federate with any Synapse >= 1.0.0</p>
-<h3 id="when-do-i-need-a-srv-record-or-well-known-uri"><a class="header" href="#when-do-i-need-a-srv-record-or-well-known-uri">When do I need a SRV record or .well-known URI?</a></h3>
-<p>If your homeserver listens on the default federation port (8448), and your
-<code>server_name</code> points to the host that your homeserver runs on, you do not need an
-SRV record or <code>.well-known/matrix/server</code> URI.</p>
-<p>For instance, if you registered <code>example.com</code> and pointed its DNS A record at a
-fresh Upcloud VPS or similar, you could install Synapse 0.99 on that host,
-giving it a server_name of <code>example.com</code>, and it would automatically generate a
-valid TLS certificate for you via Let's Encrypt and no SRV record or
-<code>.well-known</code> URI would be needed.</p>
-<p>This is the common case, although you can add an SRV record or
-<code>.well-known/matrix/server</code> URI for completeness if you wish.</p>
-<p><strong>However</strong>, if your server does not listen on port 8448, or if your <code>server_name</code>
-does not point to the host that your homeserver runs on, you will need to let
-other servers know how to find it.</p>
-<p>In this case, you should see <a href="MSC1711_certificates_FAQ.html#if-you-do-have-an-srv-record-currently">"If you do have an SRV record
-currently"</a> above.</p>
-<h3 id="can-i-still-use-an-srv-record"><a class="header" href="#can-i-still-use-an-srv-record">Can I still use an SRV record?</a></h3>
-<p>Firstly, if you didn't need an SRV record before (because your server is
-listening on port 8448 of your server_name), you certainly don't need one now:
-the defaults are still the same.</p>
-<p>If you previously had an SRV record, you can keep using it provided you are
-able to give Synapse a TLS certificate corresponding to your server name. For
-example, suppose you had the following SRV record, which directs matrix traffic
-for example.com to matrix.example.com:443:</p>
-<pre><code>_matrix._tcp.example.com. IN SRV 10 5 443 matrix.example.com
-</code></pre>
-<p>In this case, Synapse must be given a certificate for example.com - or be
-configured to acquire one from Let's Encrypt.</p>
-<p>If you are unable to give Synapse a certificate for your server_name, you will
-also need to use a .well-known URI instead. However, see also "I have created a
-.well-known URI. Do I still need an SRV record?".</p>
-<h3 id="i-have-created-a-well-known-uri-do-i-still-need-an-srv-record"><a class="header" href="#i-have-created-a-well-known-uri-do-i-still-need-an-srv-record">I have created a .well-known URI. Do I still need an SRV record?</a></h3>
-<p>As of Synapse 0.99, Synapse will first check for the existence of a <code>.well-known</code>
-URI and follow any delegation it suggests. It will only then check for the
-existence of an SRV record.</p>
-<p>That means that the SRV record will often be redundant. However, you should
-remember that there may still be older versions of Synapse in the federation
-which do not understand <code>.well-known</code> URIs, so if you removed your SRV record you
-would no longer be able to federate with them.</p>
-<p>It is therefore best to leave the SRV record in place for now. Synapse 0.34 and
-earlier will follow the SRV record (and not care about the invalid
-certificate). Synapse 0.99 and later will follow the .well-known URI, with the
-correct certificate chain.</p>
-<h3 id="it-used-to-work-just-fine-why-are-you-breaking-everything"><a class="header" href="#it-used-to-work-just-fine-why-are-you-breaking-everything">It used to work just fine, why are you breaking everything?</a></h3>
-<p>We have always wanted Matrix servers to be as easy to set up as possible, and
-so back when we started federation in 2014 we didn't want admins to have to go
-through the cumbersome process of buying a valid TLS certificate to run a
-server. This was before Let's Encrypt came along and made getting a free and
-valid TLS certificate straightforward. So instead, we adopted a system based on
-<a href="https://en.wikipedia.org/wiki/Convergence_(SSL)">Perspectives</a>: an approach
-where you check a set of "notary servers" (in practice, homeservers) to vouch
-for the validity of a certificate rather than having it signed by a CA. As long
-as enough different notaries agree on the certificate's validity, then it is
-trusted.</p>
-<p>However, in practice this has never worked properly. Most people only use the
-default notary server (matrix.org), leading to inadvertent centralisation which
-we want to eliminate. Meanwhile, we never implemented the full consensus
-algorithm to query the servers participating in a room to determine consensus
-on whether a given certificate is valid. This is fiddly to get right
-(especially in face of sybil attacks), and we found ourselves questioning
-whether it was worth the effort to finish the work and commit to maintaining a
-secure certificate validation system as opposed to focusing on core Matrix
-development.</p>
-<p>Meanwhile, Let's Encrypt came along in 2016, and put the final nail in the
-coffin of the Perspectives project (which was already pretty dead). So, the
-Spec Core Team decided that a better approach would be to mandate valid TLS
-certificates for federation alongside the rest of the Web. More details can be
-found in
-<a href="https://github.com/matrix-org/matrix-doc/blob/main/proposals/1711-x509-for-federation.md#background-the-failure-of-the-perspectives-approach">MSC1711</a>.</p>
-<p>This results in a breaking change, which is disruptive, but absolutely critical
-for the security model. However, the existence of Let's Encrypt as a trivial
-way to replace the old self-signed certificates with valid CA-signed ones helps
-smooth things over massively, especially as Synapse can now automate Let's
-Encrypt certificate generation if needed.</p>
-<h3 id="can-i-manage-my-own-certificates-rather-than-having-synapse-renew-certificates-itself"><a class="header" href="#can-i-manage-my-own-certificates-rather-than-having-synapse-renew-certificates-itself">Can I manage my own certificates rather than having Synapse renew certificates itself?</a></h3>
-<p>Yes, you are welcome to manage your certificates yourself. Synapse will only
-attempt to obtain certificates from Let's Encrypt if you configure it to do
-so.The only requirement is that there is a valid TLS cert present for
-federation end points.</p>
-<h3 id="do-you-still-recommend-against-using-a-reverse-proxy-on-the-federation-port"><a class="header" href="#do-you-still-recommend-against-using-a-reverse-proxy-on-the-federation-port">Do you still recommend against using a reverse proxy on the federation port?</a></h3>
-<p>We no longer actively recommend against using a reverse proxy. Many admins will
-find it easier to direct federation traffic to a reverse proxy and manage their
-own TLS certificates, and this is a supported configuration.</p>
-<p>See <a href="reverse_proxy.html">the reverse proxy documentation</a> for information on setting up a
-reverse proxy.</p>
-<h3 id="do-i-still-need-to-give-my-tls-certificates-to-synapse-if-i-am-using-a-reverse-proxy"><a class="header" href="#do-i-still-need-to-give-my-tls-certificates-to-synapse-if-i-am-using-a-reverse-proxy">Do I still need to give my TLS certificates to Synapse if I am using a reverse proxy?</a></h3>
-<p>Practically speaking, this is no longer necessary.</p>
-<p>If you are using a reverse proxy for all of your TLS traffic, then you can set
-<code>no_tls: True</code>. In that case, the only reason Synapse needs the certificate is
-to populate a legacy 'tls_fingerprints' field in the federation API. This is
-ignored by Synapse 0.99.0 and later, and the only time pre-0.99 Synapses will
-check it is when attempting to fetch the server keys - and generally this is
-delegated via <code>matrix.org</code>, which is on 0.99.0.</p>
-<p>However, there is a bug in Synapse 0.99.0
-<a href="https://github.com/matrix-org/synapse/issues/4554">4554</a> which prevents
-Synapse from starting if you do not give it a TLS certificate. To work around
-this, you can give it any TLS certificate at all. This will be fixed soon.</p>
-<h3 id="do-i-need-the-same-certificate-for-the-client-and-federation-port"><a class="header" href="#do-i-need-the-same-certificate-for-the-client-and-federation-port">Do I need the same certificate for the client and federation port?</a></h3>
-<p>No. There is nothing stopping you from using different certificates,
-particularly if you are using a reverse proxy. However, Synapse will use the
-same certificate on any ports where TLS is configured.</p>
-<h3 id="how-do-i-tell-synapse-to-reload-my-keyscertificates-after-i-replace-them"><a class="header" href="#how-do-i-tell-synapse-to-reload-my-keyscertificates-after-i-replace-them">How do I tell Synapse to reload my keys/certificates after I replace them?</a></h3>
-<p>Synapse will reload the keys and certificates when it receives a SIGHUP - for
-example <code>kill -HUP $(cat homeserver.pid)</code>. Alternatively, simply restart
-Synapse, though this will result in downtime while it restarts.</p>
<div id="chapter_begin" style="break-before: page; page-break-before: always;"></div><h1 id="setting-up-federation"><a class="header" href="#setting-up-federation">Setting up federation</a></h1>
<p>Federation is the process by which users on different servers can participate
in the same room. For this to work, those other servers must be able to contact
@@ -3871,11 +3663,16 @@ caches:
per_cache_factors:
#get_users_who_share_room_with_user: 2.0
- # Controls how long an entry can be in a cache without having been
- # accessed before being evicted. Defaults to None, which means
- # entries are never evicted based on time.
+ # Controls whether cache entries are evicted after a specified time
+ # period. Defaults to true. Uncomment to disable this feature.
+ #
+ #expire_caches: false
+
+ # If expire_caches is enabled, this flag controls how long an entry can
+ # be in a cache without having been accessed before being evicted.
+ # Defaults to 30m. Uncomment to set a different time to live for cache entries.
#
- #expiry_time: 30m
+ #cache_entry_ttl: 30m
# Controls how long the results of a /sync request are cached for after
# a successful response is returned. A higher duration can help clients with
@@ -3977,6 +3774,9 @@ log_config: "CONFDIR/SERVERNAME.log.config"
# - one for ratelimiting how often a user or IP can attempt to validate a 3PID.
# - two for ratelimiting how often invites can be sent in a room or to a
# specific user.
+# - one for ratelimiting 3PID invites (i.e. invites sent to a third-party ID
+# such as an email address or a phone number) based on the account that's
+# sending the invite.
#
# The defaults are as shown below.
#
@@ -4026,6 +3826,10 @@ log_config: "CONFDIR/SERVERNAME.log.config"
# per_user:
# per_second: 0.003
# burst_count: 5
+#
+#rc_third_party_invite:
+# per_second: 0.2
+# burst_count: 10
# Ratelimiting settings for incoming federation
#
@@ -6054,7 +5858,7 @@ formatters:
handlers:
console:
class: logging.StreamHandler
- location: ext://sys.stdout
+ stream: ext://sys.stdout
file:
class: logging.FileHandler
formatter: json
@@ -8702,7 +8506,7 @@ Here's an example featuring all currently supported keys:</p>
"address": "33123456789",
"validated_at": 1642701357084,
},
- "org.matrix.msc3231.login.registration_token": "sometoken", # User has registered through the flow described in MSC3231
+ "m.login.registration_token": "sometoken", # User has registered through a registration token
}
</code></pre>
<p>The second dictionary contains the parameters provided by the user's client in the request
@@ -8716,6 +8520,20 @@ callback that does not return <code>None</code> will be used. If this happens, S
any of the subsequent implementations of this callback. If every callback return <code>None</code>,
the username provided by the user is used, if any (otherwise one is automatically
generated).</p>
+<h2 id="is_3pid_allowed"><a class="header" href="#is_3pid_allowed"><code>is_3pid_allowed</code></a></h2>
+<p><em>First introduced in Synapse v1.53.0</em></p>
+<pre><code class="language-python">async def is_3pid_allowed(self, medium: str, address: str, registration: bool) -> bool
+</code></pre>
+<p>Called when attempting to bind a third-party identifier (i.e. an email address or a phone
+number). The module is given the medium of the third-party identifier (which is <code>email</code> if
+the identifier is an email address, or <code>msisdn</code> if the identifier is a phone number) and
+its address, as well as a boolean indicating whether the attempt to bind is happening as
+part of registering a new user. The module must return a boolean indicating whether the
+identifier can be allowed to be bound to an account on the local homeserver.</p>
+<p>If multiple modules implement this callback, they will be considered in order. If a
+callback returns <code>True</code>, Synapse falls through to the next one. The value of the first
+callback that does not return <code>True</code> will be used. If this happens, Synapse will not call
+any of the subsequent implementations of this callback.</p>
<h2 id="example-3"><a class="header" href="#example-3">Example</a></h2>
<p>The example module below implements authentication checkers for two different login types: </p>
<ul>
@@ -9049,7 +8867,7 @@ expressions:</p>
# Registration/login requests
^/_matrix/client/(api/v1|r0|v3|unstable)/login$
^/_matrix/client/(r0|v3|unstable)/register$
-^/_matrix/client/unstable/org.matrix.msc3231/register/org.matrix.msc3231.login.registration_token/validity$
+^/_matrix/client/v1/register/m.login.registration_token/validity$
# Event sending requests
^/_matrix/client/(api/v1|r0|v3|unstable)/rooms/.*/redact
@@ -9694,6 +9512,8 @@ have a canonical alias set.</li>
</ul>
<div id="chapter_begin" style="break-before: page; page-break-before: always;"></div><h1 id="querying-media"><a class="header" href="#querying-media">Querying media</a></h1>
<p>These APIs allow extracting media information from the homeserver.</p>
+<p>Details about the format of the <code>media_id</code> and storage of the media in the file system
+are documented under <a href="admin_api/../media_repository.html">media repository</a>.</p>
<p>To use it, you will need to authenticate by providing an <code>access_token</code>
for a server admin: see <a href="admin_api/../usage/administration/admin_api">Admin API</a>.</p>
<h2 id="list-all-media-in-a-room"><a class="header" href="#list-all-media-in-a-room">List all media in a room</a></h2>
@@ -11499,7 +11319,7 @@ were sent, but hidden from users joining the room afterwards.</p>
An empty body may be passed for backwards compatibility.</p>
<p>The following actions are performed when deactivating an user:</p>
<ul>
-<li>Try to unpind 3PIDs from the identity server</li>
+<li>Try to unbind 3PIDs from the identity server</li>
<li>Remove all 3PIDs from the homeserver</li>
<li>Delete all devices and E2EE keys</li>
<li>Delete all access tokens</li>
@@ -11666,7 +11486,11 @@ member are returned.</p>
<h2 id="user-media"><a class="header" href="#user-media">User media</a></h2>
<h3 id="list-media-uploaded-by-a-user"><a class="header" href="#list-media-uploaded-by-a-user">List media uploaded by a user</a></h3>
<p>Gets a list of all local media that a specific <code>user_id</code> has created.
-By default, the response is ordered by descending creation date and ascending media ID.
+These are media that the user has uploaded themselves
+(<a href="admin_api/../media_repository.html#local-media">local media</a>), as well as
+<a href="admin_api/../media_repository.html#url-previews">URL preview images</a> requested by the user if the
+<a href="admin_api/../development/url_previews.html">feature is enabled</a>.</p>
+<p>By default, the response is ordered by descending creation date and ascending media ID.
The newest media is on top. You can change the order with parameters
<code>order_by</code> and <code>dir</code>.</p>
<p>The API is:</p>
@@ -11760,7 +11584,9 @@ Media objects contain the following fields:
<ul>
<li><code>created_ts</code> - integer - Timestamp when the content was uploaded in ms.</li>
<li><code>last_access_ts</code> - integer - Timestamp when the content was last accessed in ms.</li>
-<li><code>media_id</code> - string - The id used to refer to the media.</li>
+<li><code>media_id</code> - string - The id used to refer to the media. Details about the format
+are documented under
+<a href="admin_api/../media_repository.html">media repository</a>.</li>
<li><code>media_length</code> - integer - Length of the media in bytes.</li>
<li><code>media_type</code> - string - The MIME-type of the media.</li>
<li><code>quarantined_by</code> - string - The user ID that initiated the quarantine request
@@ -13507,6 +13333,36 @@ frobber:
and is maintained by a script, <code>scripts-dev/generate_sample_config</code>.
Making sure that the output from this script matches the desired format
is left as an exercise for the reader!</p>
+<div id="chapter_begin" style="break-before: page; page-break-before: always;"></div><h1 id="synapse-release-cycle"><a class="header" href="#synapse-release-cycle">Synapse Release Cycle</a></h1>
+<p>Releases of Synapse follow a two week release cycle with new releases usually
+occurring on Tuesdays:</p>
+<ul>
+<li>Day 0: Synapse <code>N - 1</code> is released.</li>
+<li>Day 7: Synapse <code>N</code> release candidate 1 is released.</li>
+<li>Days 7 - 13: Synapse <code>N</code> release candidates 2+ are released, if bugs are found.</li>
+<li>Day 14: Synapse <code>N</code> is released.</li>
+</ul>
+<p>Note that this schedule might be modified depending on the availability of the
+Synapse team, e.g. releases may be skipped to avoid holidays.</p>
+<p>Release announcements can be found in the
+<a href="https://matrix.org/blog/category/releases">release category of the Matrix blog</a>.</p>
+<h2 id="bugfix-releases"><a class="header" href="#bugfix-releases">Bugfix releases</a></h2>
+<p>If a bug is found after release that is deemed severe enough (by a combination
+of the impacted users and the impact on those users) then a bugfix release may
+be issued. This may be at any point in the release cycle.</p>
+<h2 id="security-releases"><a class="header" href="#security-releases">Security releases</a></h2>
+<p>Security will sometimes be backported to the previous version and released
+immediately before the next release candidate. An example of this might be:</p>
+<ul>
+<li>Day 0: Synapse N - 1 is released.</li>
+<li>Day 7: Synapse (N - 1).1 is released as Synapse N - 1 + the security fix.</li>
+<li>Day 7: Synapse N release candidate 1 is released (including the security fix).</li>
+</ul>
+<p>Depending on the impact and complexity of security fixes, multiple fixes might
+be held to be released together.</p>
+<p>In some cases, a pre-disclosure of a security release will be issued as a notice
+to Synapse operators that there is an upcoming security release. These can be
+found in the <a href="https://matrix.org/blog/category/security">security category of the Matrix blog</a>.</p>
<div id="chapter_begin" style="break-before: page; page-break-before: always;"></div><h1 id="some-notes-on-how-we-use-git"><a class="header" href="#some-notes-on-how-we-use-git">Some notes on how we use git</a></h1>
<h2 id="on-keeping-the-commit-history-clean"><a class="header" href="#on-keeping-the-commit-history-clean">On keeping the commit history clean</a></h2>
<p>In an ideal world, our git commit history would be a linear progression of
|
