diff --git a/latest/print.html b/latest/print.html
index 7f1d209324..eccc95ce08 100644
--- a/latest/print.html
+++ b/latest/print.html
@@ -77,7 +77,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><ol class="section"><li class="chapter-item expanded "><a href="setup/turn/coturn.html">coturn TURN server</a></li><li class="chapter-item expanded "><a href="setup/turn/eturnal.html">eturnal TURN server</a></li></ol></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/config_documentation.html">Configuration Manual</a></li><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="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/account_data_callbacks.html">Account data 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/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><ol class="section"><li class="chapter-item expanded "><a href="usage/administration/monitoring/reporting_homeserver_usage_statistics.html">Reporting Homeserver Usage Statistics</a></li></ol></li><li class="chapter-item expanded "><a href="usage/administration/monthly_active_users.html">Monthly Active Users</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/reviews.html">Reviewing Code</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><ol class="section"><li class="chapter-item expanded "><a href="development/demo.html">Demo scripts</a></li></ol></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 "><a href="development/dependencies.html">Dependency management</a></li><li class="chapter-item expanded "><div>Synapse Architecture</div></li><li><ol class="section"><li class="chapter-item expanded "><a href="development/synapse_architecture/cancellation.html">Cancellation</a></li><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><ol class="section"><li class="chapter-item expanded "><a href="setup/turn/coturn.html">coturn TURN server</a></li><li class="chapter-item expanded "><a href="setup/turn/eturnal.html">eturnal TURN server</a></li></ol></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/config_documentation.html">Configuration Manual</a></li><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="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/account_data_callbacks.html">Account data 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/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><ol class="section"><li class="chapter-item expanded "><a href="usage/administration/monitoring/reporting_homeserver_usage_statistics.html">Reporting Homeserver Usage Statistics</a></li></ol></li><li class="chapter-item expanded "><a href="usage/administration/monthly_active_users.html">Monthly Active Users</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/reviews.html">Reviewing Code</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><ol class="section"><li class="chapter-item expanded "><a href="development/demo.html">Demo scripts</a></li></ol></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 "><a href="development/dependencies.html">Dependency management</a></li><li class="chapter-item expanded "><div>Synapse Architecture</div></li><li><ol class="section"><li class="chapter-item expanded "><a href="development/synapse_architecture/cancellation.html">Cancellation</a></li><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><li class="chapter-item expanded "><a href="development/synapse_architecture/faster_joins.html">Faster remote joins</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>
@@ -1771,6 +1771,27 @@ dpkg -i matrix-synapse-py3_1.3.0+stretch1_amd64.deb
</code></pre>
</li>
</ul>
+<h1 id="upgrading-to-v1760"><a class="header" href="#upgrading-to-v1760">Upgrading to v1.76.0</a></h1>
+<h2 id="faster-joins-are-enabled-by-default"><a class="header" href="#faster-joins-are-enabled-by-default">Faster joins are enabled by default</a></h2>
+<p>When joining a room for the first time, Synapse 1.76.0 will request a partial join from the other server by default. Previously, server admins had to opt-in to this using an experimental config flag.</p>
+<p>Server admins can opt out of this feature for the time being by setting</p>
+<pre><code class="language-yaml">experimental:
+ faster_joins: false
+</code></pre>
+<p>in their server config.</p>
+<h2 id="changes-to-the-account-data-replication-streams"><a class="header" href="#changes-to-the-account-data-replication-streams">Changes to the account data replication streams</a></h2>
+<p>Synapse has changed the format of the account data and devices replication
+streams (between workers). This is a forwards- and backwards-incompatible
+change: v1.75 workers cannot process account data replicated by v1.76 workers,
+and vice versa.</p>
+<p>Once all workers are upgraded to v1.76 (or downgraded to v1.75), account data
+and device replication will resume as normal.</p>
+<h2 id="minimum-version-of-poetry-is-now-132"><a class="header" href="#minimum-version-of-poetry-is-now-132">Minimum version of Poetry is now 1.3.2</a></h2>
+<p>The minimum supported version of Poetry is now 1.3.2 (previously 1.2.0, <a href="upgrade.html#upgrading-to-v1670">since
+Synapse 1.67</a>). If you have used <code>poetry install</code> to
+install Synapse from a source checkout, you should upgrade poetry: see its
+<a href="https://python-poetry.org/docs/#installation">installation instructions</a>.
+For all other installation methods, no acction is required.</p>
<h1 id="upgrading-to-v1740"><a class="header" href="#upgrading-to-v1740">Upgrading to v1.74.0</a></h1>
<h2 id="unicode-support-in-user-search"><a class="header" href="#unicode-support-in-user-search">Unicode support in user search</a></h2>
<p>This version introduces optional support for an <a href="https://github.com/matrix-org/synapse/pull/14464">improved user search dealing with Unicode characters</a>.</p>
@@ -3709,7 +3730,8 @@ rooms directory via federation. Defaults to false.</p>
<p>Known room versions are listed <a href="https://spec.matrix.org/latest/rooms/#complete-list-of-room-versions">here</a></p>
<p>For example, for room version 1, <code>default_room_version</code> should be set
to "1".</p>
-<p>Currently defaults to "9".</p>
+<p>Currently defaults to <a href="https://spec.matrix.org/v1.5/rooms/v10/">"10"</a>.</p>
+<p><em>Changed in Synapse 1.76:</em> the default version room version was increased from <a href="https://spec.matrix.org/v1.5/rooms/v9/">9</a> to <a href="https://spec.matrix.org/v1.5/rooms/v10/">10</a>.</p>
<p>Example configuration:</p>
<pre><code class="language-yaml">default_room_version: "8"
</code></pre>
@@ -3806,6 +3828,11 @@ configuration.</p>
<p><code>port</code>: the TCP port to bind to.</p>
</li>
<li>
+<p><code>tag</code>: An alias for the port in the logger name. If set the tag is logged instead
+of the port. Default to <code>None</code>, is optional and only valid for listener with <code>type: http</code>.
+See the docs <a href="usage/configuration/../administration/request_log.html">request log format</a>.</p>
+</li>
+<li>
<p><code>bind_addresses</code>: a list of local addresses to listen on. The default is
'all local interfaces'.</p>
</li>
@@ -3883,6 +3910,13 @@ additional endpoints which should be loaded via dynamic modules.</p>
<li>
<p><code>static</code>: static resources under synapse/static (/_matrix/static). (Mostly useful for 'fallback authentication'.)</p>
</li>
+<li>
+<p><code>health</code>: the <a href="usage/configuration/../../reverse_proxy.html#health-check-endpoint">health check endpoint</a>. This endpoint
+is by default active for all other resources and does not have to be activated separately.
+This is only useful if you want to use the health endpoint explicitly on a dedicated port or
+for <a href="usage/configuration/../../workers.html">workers</a> and containers without listener e.g.
+<a href="usage/configuration/../../workers.html#notifying-application-services">application services</a>.</p>
+</li>
</ul>
<p>Example configuration #1:</p>
<pre><code class="language-yaml">listeners:
@@ -6449,8 +6483,8 @@ will also not affect rooms created by other servers.</p>
empty responses are returned to all queries. Defaults to true.</p>
</li>
<li>
-<p><code>search_all_users</code>: Defines whether to search all users visible to your HS when searching
-the user directory. If false, search results will only contain users
+<p><code>search_all_users</code>: Defines whether to search all users visible to your HS at the time the search is performed. If set to true, will return all users who share a room with the user from the homeserver.
+If false, search results will only contain users
visible in public rooms and users sharing a room with the requester.
Defaults to false.</p>
<p>NB. If you set this to true, and the last time the user_directory search
@@ -6907,6 +6941,20 @@ other workers.</p>
- names: [client, federation]
</code></pre>
<hr />
+<h3 id="worker_manhole"><a class="header" href="#worker_manhole"><code>worker_manhole</code></a></h3>
+<p>A worker may have a listener for <a href="usage/configuration/../../manhole.html"><code>manhole</code></a>.
+It allows server administrators to access a Python shell on the worker.</p>
+<p>Example configuration:</p>
+<pre><code class="language-yaml">worker_manhole: 9000
+</code></pre>
+<p>This is a short form for:</p>
+<pre><code class="language-yaml">worker_listeners:
+ - port: 9000
+ bind_addresses: ['127.0.0.1']
+ type: manhole
+</code></pre>
+<p>It needs also an additional <a href="usage/configuration/config_documentation.html#manhole_settings"><code>manhole_settings</code></a> configuration.</p>
+<hr />
<h3 id="worker_daemonize"><a class="header" href="#worker_daemonize"><code>worker_daemonize</code></a></h3>
<p>Specifies whether the worker should be started as a daemon process.
If Synapse is being managed by <a href="usage/configuration/../../systemd-with-workers/">systemd</a>, this option
@@ -7018,9 +7066,10 @@ trusted_key_servers:
</code></pre>
<div style="break-before: page; page-break-before: always;"></div><h1 id="logging-sample-configuration-file"><a class="header" href="#logging-sample-configuration-file">Logging Sample Configuration File</a></h1>
<p>Below is a sample logging configuration file. This file can be tweaked to control how your
-homeserver will output logs. A restart of the server is generally required to apply any
-changes made to this file. The value of the <code>log_config</code> option in your homeserver
-config should be the path to this file.</p>
+homeserver will output logs. The value of the <code>log_config</code> option in your homeserver config
+should be the path to this file.</p>
+<p>To apply changes made to this file, send Synapse a SIGHUP signal (or, if using <code>systemd</code>, run
+<code>systemctl reload</code> on the Synapse service).</p>
<p>Note that a default logging configuration (shown below) is created automatically alongside
the homeserver config when following the <a href="usage/configuration/../../setup/installation.html">installation instructions</a>.
It should be named <code><SERVERNAME>.log.config</code> by default.</p>
@@ -8708,7 +8757,8 @@ option in your synapse config.</p>
- /home/matrix/.synapse/<your-AS>.yaml
</code></pre>
<p>The format of the AS configuration file is as follows:</p>
-<pre><code class="language-yaml">url: <base url of AS>
+<pre><code class="language-yaml">id: <your-AS-id>
+url: <base url of AS>
as_token: <token AS will add to requests to HS>
hs_token: <token HS will add to requests to AS>
sender_localpart: <localpart of AS user>
@@ -10434,11 +10484,10 @@ worker_name: generic_worker1
worker_replication_host: 127.0.0.1
worker_replication_http_port: 9093
-worker_main_http_uri: http://localhost:8008/
-
worker_listeners:
- type: http
port: 8083
+ x_forwarded: true
resources:
- names: [client, federation]
@@ -10650,6 +10699,7 @@ worker_listeners:
#
#- type: http
# port: 8035
+ # x_forwarded: true
# resources:
# - names: [client]
@@ -10873,6 +10923,7 @@ worker_replication_http_port: 9093
worker_listeners:
- type: http
port: 8085
+ x_forwarded: true
resources:
- names: [media]
@@ -10997,11 +11048,10 @@ worker_name: generic_worker1
worker_replication_host: 127.0.0.1
worker_replication_http_port: 9093
-worker_main_http_uri: http://localhost:8008/
-
worker_listeners:
- type: http
port: 8083
+ x_forwarded: true
resources:
- names: [client, federation]
@@ -14985,7 +15035,7 @@ WHERE room_stats_state.room_id = event_json.room_id" | psql -d synapse -h l
</code></pre>
<table><thead><tr><th>Part</th><th>Explanation</th></tr></thead><tbody>
<tr><td>AAAA</td><td>Timestamp request was logged (not received)</td></tr>
-<tr><td>BBBB</td><td>Logger name (<code>synapse.access.(http\|https).<tag></code>, where 'tag' is defined in the <code>listeners</code> config section, normally the port)</td></tr>
+<tr><td>BBBB</td><td>Logger name (<code>synapse.access.(http\|https).<tag></code>, where 'tag' is defined in the <a href="usage/administration/../configuration/config_documentation.html#listeners"><code>listeners</code></a> config section, normally the port)</td></tr>
<tr><td>CCCC</td><td>Line number in code</td></tr>
<tr><td>DDDD</td><td>Log Level</td></tr>
<tr><td>EEEE</td><td>Request Identifier (This identifier is shared by related log lines)</td></tr>
@@ -15032,6 +15082,11 @@ small processing times.</p>
<h2 id="what-users-are-registered-on-my-server"><a class="header" href="#what-users-are-registered-on-my-server">What users are registered on my server?</a></h2>
<pre><code class="language-sql">SELECT NAME from users;
</code></pre>
+<h2 id="how-can-i-export-user-data"><a class="header" href="#how-can-i-export-user-data">How can I export user data?</a></h2>
+<p>Synapse includes a Python command to export data for a specific user. It takes the homeserver
+configuration file and the full Matrix ID of the user to export:</p>
+<pre><code class="language-console">python -m synapse.app.admin_cmd -c <config_file> export-data <user_id>
+</code></pre>
<h2 id="manually-resetting-passwords"><a class="header" href="#manually-resetting-passwords">Manually resetting passwords</a></h2>
<p>Users can reset their password through their client. Alternatively, a server admin
can reset a user's password using the <a href="usage/administration/../../admin_api/user_admin_api.html#reset-password">admin API</a>.</p>
@@ -15179,7 +15234,7 @@ pipx install poetry
</code></pre>
<p>but see poetry's <a href="https://python-poetry.org/docs/#installation">installation instructions</a>
for other installation methods.</p>
-<p>Synapse requires Poetry version 1.2.0 or later.</p>
+<p>Developing Synapse requires Poetry version 1.3.2 or later.</p>
<p>Next, open a terminal and install dependencies as follows:</p>
<pre><code class="language-sh">cd path/where/you/have/cloned/the/repository
poetry install --extras all
@@ -15573,17 +15628,13 @@ errors in code.</p>
<li><a href="https://github.com/charliermarsh/ruff">ruff</a>, which can spot common errors; and</li>
<li><a href="https://mypy.readthedocs.io/en/stable/">mypy</a>, a type checker.</li>
</ul>
-<p>Install them with:</p>
-<pre><code class="language-sh">pip install -e ".[lint,mypy]"
-</code></pre>
-<p>The easiest way to run the lints is to invoke the linter script as follows.</p>
-<pre><code class="language-sh">scripts-dev/lint.sh
-</code></pre>
+<p>See <a href="development/contributing_guide.html#run-the-linters">the contributing guide</a> for instructions
+on how to install the above tools and run the linters.</p>
<p>It's worth noting that modern IDEs and text editors can run these tools
automatically on save. It may be worth looking into whether this
functionality is supported in your editor for a more convenient
development workflow. It is not, however, recommended to run <code>mypy</code>
-on save as they take a while and can be very resource intensive.</p>
+on save as it takes a while and can be very resource intensive.</p>
<h2 id="general-rules"><a class="header" href="#general-rules">General rules</a></h2>
<ul>
<li><strong>Naming</strong>:
@@ -16190,6 +16241,10 @@ configuration key (see the <code>synapse.config.experimental</code> file) and ei
(briefly) what is being enabled, or include the MSC number.</p>
<div style="break-before: page; page-break-before: always;"></div><h1 id="managing-dependencies-with-poetry"><a class="header" href="#managing-dependencies-with-poetry">Managing dependencies with Poetry</a></h1>
<p>This is a quick cheat sheet for developers on how to use <a href="https://python-poetry.org/"><code>poetry</code></a>.</p>
+<h1 id="installing"><a class="header" href="#installing">Installing</a></h1>
+<p>See the <a href="development/contributing_guide.html#4-install-the-dependencies">contributing guide</a>.</p>
+<p>Developers should use Poetry 1.3.2 or higher. If you encounter problems related
+to poetry, please <a href="development/dependencies.html#check-the-version-of-poetry-with-poetry---version">double-check your poetry version</a>.</p>
<h1 id="background-1"><a class="header" href="#background-1">Background</a></h1>
<p>Synapse uses a variety of third-party Python packages to function as a homeserver.
Some of these are direct dependencies, listed in <code>pyproject.toml</code> under the
@@ -16282,7 +16337,7 @@ e.g. <code>mypy</code> instead of <code>poetry run mypy</code>; <code>python</co
context of poetry's venv, without having to run <code>poetry shell</code> beforehand.</p>
<h1 id="how-do-i"><a class="header" href="#how-do-i">How do I...</a></h1>
<h2 id="reset-my-venv-to-the-locked-environment"><a class="header" href="#reset-my-venv-to-the-locked-environment">...reset my venv to the locked environment?</a></h2>
-<pre><code class="language-shell">poetry install --extras all --remove-untracked
+<pre><code class="language-shell">poetry install --all-extras --sync
</code></pre>
<h2 id="delete-everything-and-start-over-from-scratch"><a class="header" href="#delete-everything-and-start-over-from-scratch">...delete everything and start over from scratch?</a></h2>
<pre><code class="language-shell"># Stop the current virtualenv if active
@@ -16328,11 +16383,7 @@ useful.</p>
<ul>
<li>manually update <code>pyproject.toml</code>; then <code>poetry lock --no-update</code>; or else</li>
<li><code>poetry add packagename</code>. See <code>poetry add --help</code>; note the <code>--dev</code>,
-<code>--extras</code> and <code>--optional</code> flags in particular.
-<ul>
-<li><strong>NB</strong>: this specifies the new package with a version given by a "caret bound". This won't get forced to its lowest version in the old deps CI job: see <a href="https://github.com/matrix-org/synapse/blob/4e1374373857f2f7a911a31c50476342d9070681/.ci/scripts/test_old_deps.sh#L35-L39">this TODO</a>.</li>
-</ul>
-</li>
+<code>--extras</code> and <code>--optional</code> flags in particular.</li>
</ul>
<p>Include the updated <code>pyproject.toml</code> and <code>poetry.lock</code> files in your commit.</p>
<h2 id="remove-a-dependency"><a class="header" href="#remove-a-dependency">...remove a dependency?</a></h2>
@@ -16340,7 +16391,7 @@ useful.</p>
<pre><code class="language-shell">poetry remove packagename
</code></pre>
<p>ought to do the trick. Alternatively, manually update <code>pyproject.toml</code> and
-<code>poetry lock --no-update</code>. Include the updated <code>pyproject.toml</code> and poetry.lock`
+<code>poetry lock --no-update</code>. Include the updated <code>pyproject.toml</code> and <code>poetry.lock</code>
files in your commit.</p>
<h2 id="update-the-version-range-for-an-existing-dependency"><a class="header" href="#update-the-version-range-for-an-existing-dependency">...update the version range for an existing dependency?</a></h2>
<p>Best done by manually editing <code>pyproject.toml</code>, then <code>poetry lock --no-update</code>.
@@ -16368,8 +16419,6 @@ poetry lock --no-update
<pre><code class="language-shell">poetry export --extras all
</code></pre>
<p>Be wary of bugs in <code>poetry export</code> and <code>pip install -r requirements.txt</code>.</p>
-<p>Note: <code>poetry export</code> will be made a plugin in Poetry 1.2. Additional config may
-be required.</p>
<h2 id="build-a-test-wheel"><a class="header" href="#build-a-test-wheel">...build a test wheel?</a></h2>
<p>I usually use</p>
<pre><code class="language-shell">poetry run pip install build && poetry run python -m build
@@ -16379,7 +16428,7 @@ doesn't require poetry. (It's what we use in CI too). However, you could try
<code>poetry build</code> too.</p>
<h1 id="troubleshooting-4"><a class="header" href="#troubleshooting-4">Troubleshooting</a></h1>
<h2 id="check-the-version-of-poetry-with-poetry---version"><a class="header" href="#check-the-version-of-poetry-with-poetry---version">Check the version of poetry with <code>poetry --version</code>.</a></h2>
-<p>The minimum version of poetry supported by Synapse is 1.2.</p>
+<p>The minimum version of poetry supported by Synapse is 1.3.2.</p>
<p>It can also be useful to check the version of <code>poetry-core</code> in use. If you've
installed <code>poetry</code> with <code>pipx</code>, try <code>pipx runpip poetry list | grep poetry-core</code>.</p>
<h2 id="clear-caches-poetry-cache-clear---all-pypi"><a class="header" href="#clear-caches-poetry-cache-clear---all-pypi">Clear caches: <code>poetry cache clear --all pypi</code>.</a></h2>
@@ -17263,6 +17312,347 @@ workers understand to mean to expand to invalidate the correct caches.</p>
<li><code>cs_cache_fake</code> ─ invalidates caches that depend on the current
state</li>
</ol>
+<div style="break-before: page; page-break-before: always;"></div><h1 id="how-do-faster-joins-work"><a class="header" href="#how-do-faster-joins-work">How do faster joins work?</a></h1>
+<p>This is a work-in-progress set of notes with two goals:</p>
+<ul>
+<li>act as a reference, explaining how Synapse implements faster joins; and</li>
+<li>record the rationale behind our choices.</li>
+</ul>
+<p>See also <a href="https://github.com/matrix-org/matrix-spec-proposals/pull/3902">MSC3902</a>.</p>
+<p>The key idea is described by <a href="https://github.com/matrix-org/matrix-spec-proposals/pull/3902">MSC706</a>. This allows servers to
+request a lightweight response to the federation <code>/send_join</code> endpoint.
+This is called a <strong>faster join</strong>, also known as a <strong>partial join</strong>. In these
+notes we'll usually use the word "partial" as it matches the database schema.</p>
+<h2 id="overview-processing-events-in-a-partially-joined-room"><a class="header" href="#overview-processing-events-in-a-partially-joined-room">Overview: processing events in a partially-joined room</a></h2>
+<p>The response to a partial join consists of</p>
+<ul>
+<li>the requested join event <code>J</code>,</li>
+<li>a list of the servers in the room (according to the state before <code>J</code>),</li>
+<li>a subset of the state of the room before <code>J</code>,</li>
+<li>the full auth chain of that state subset.</li>
+</ul>
+<p>Synapse marks the room as partially joined by adding a row to the database table
+<code>partial_state_rooms</code>. It also marks the join event <code>J</code> as "partially stated",
+meaning that we have neither received nor computed the full state before/after
+<code>J</code>. This is done by adding a row to <code>partial_state_events</code>.</p>
+<details><summary>DB schema</summary>
+<pre><code>matrix=> \d partial_state_events
+Table "matrix.partial_state_events"
+ Column │ Type │ Collation │ Nullable │ Default
+══════════╪══════╪═══════════╪══════════╪═════════
+ room_id │ text │ │ not null │
+ event_id │ text │ │ not null │
+
+matrix=> \d partial_state_rooms
+ Table "matrix.partial_state_rooms"
+ Column │ Type │ Collation │ Nullable │ Default
+════════════════════════╪════════╪═══════════╪══════════╪═════════
+ room_id │ text │ │ not null │
+ device_lists_stream_id │ bigint │ │ not null │ 0
+ join_event_id │ text │ │ │
+ joined_via │ text │ │ │
+
+matrix=> \d partial_state_rooms_servers
+ Table "matrix.partial_state_rooms_servers"
+ Column │ Type │ Collation │ Nullable │ Default
+═════════════╪══════╪═══════════╪══════════╪═════════
+ room_id │ text │ │ not null │
+ server_name │ text │ │ not null │
+</code></pre>
+<p>Indices, foreign-keys and check constraints are omitted for brevity.</p>
+</details>
+<p>While partially joined to a room, Synapse receives events <code>E</code> from remote
+homeservers as normal, and can create events at the request of its local users.
+However, we run into trouble when we enforce the <a href="https://spec.matrix.org/v1.5/server-server-api/#checks-performed-on-receipt-of-a-pdu">checks on an event</a>.</p>
+<blockquote>
+<ol>
+<li>Is a valid event, otherwise it is dropped. For an event to be valid, it
+must contain a room_id, and it must comply with the event format of that
+room version.</li>
+<li>Passes signature checks, otherwise it is dropped.</li>
+<li>Passes hash checks, otherwise it is redacted before being processed further.</li>
+<li>Passes authorization rules based on the event’s auth events, otherwise it
+is rejected.</li>
+<li><strong>Passes authorization rules based on the state before the event, otherwise
+it is rejected.</strong></li>
+<li><strong>Passes authorization rules based on the current state of the room,
+otherwise it is “soft failed”.</strong></li>
+</ol>
+</blockquote>
+<p>We can enforce checks 1--4 without any problems.
+But we cannot enforce checks 5 or 6 with complete certainty, since Synapse does
+not know the full state before <code>E</code>, nor that of the room.</p>
+<h3 id="partial-state"><a class="header" href="#partial-state">Partial state</a></h3>
+<p>Instead, we make a best-effort approximation.
+While the room is considered partially joined, Synapse tracks the "partial
+state" before events.
+This works in a similar way as regular state:</p>
+<ul>
+<li>The partial state before <code>J</code> is that given to us by the partial join response.</li>
+<li>The partial state before an event <code>E</code> is the resolution of the partial states
+after each of <code>E</code>'s <code>prev_event</code>s.</li>
+<li>If <code>E</code> is rejected or a message event, the partial state after <code>E</code> is the
+partial state before <code>E</code>.</li>
+<li>Otherwise, the partial state after <code>E</code> is the partial state before <code>E</code>, plus
+<code>E</code> itself.</li>
+</ul>
+<p>More concisely, partial state propagates just like full state; the only
+difference is that we "seed" it with an incomplete initial state.
+Synapse records that we have only calculated partial state for this event with
+a row in <code>partial_state_events</code>.</p>
+<p>While the room remains partially stated, check 5 on incoming events to that
+room becomes:</p>
+<blockquote>
+<ol start="5">
+<li>Passes authorization rules based on <strong>the resolution between the partial
+state before <code>E</code> and <code>E</code>'s auth events.</strong> If the event fails to pass
+authorization rules, it is rejected.</li>
+</ol>
+</blockquote>
+<p>Additionally, check 6 is deleted: no soft-failures are enforced.</p>
+<p>While partially joined, the current partial state of the room is defined as the
+resolution across the partial states after all forward extremities in the room.</p>
+<p><em>Remark.</em> Events with partial state are <em>not</em> considered
+<a href="development/synapse_architecture/../room-dag-concepts.html#outliers">outliers</a>.</p>
+<h3 id="approximation-error"><a class="header" href="#approximation-error">Approximation error</a></h3>
+<p>Using partial state means the auth checks can fail in a few different ways<sup class="footnote-reference"><a href="#2">1</a></sup>.</p>
+<div class="footnote-definition" id="2"><sup class="footnote-definition-label">1</sup>
+<p>Is this exhaustive?</p>
+</div>
+<ul>
+<li>We may erroneously accept an incoming event in check 5 based on partial state
+when it would have been rejected based on full state, or vice versa.</li>
+<li>This means that an event could erroneously be added to the current partial
+state of the room when it would not be present in the full state of the room,
+or vice versa.</li>
+<li>Additionally, we may have skipped soft-failing an event that would have been
+soft-failed based on full state.</li>
+</ul>
+<p>(Note that the discrepancies described in the last two bullets are user-visible.)</p>
+<p>This means that we have to be very careful when we want to lookup pieces of room
+state in a partially-joined room. Our approximation of the state may be
+incorrect or missing. But we can make some educated guesses. If</p>
+<ul>
+<li>our partial state is likely to be correct, or</li>
+<li>the consequences of our partial state being incorrect are minor,</li>
+</ul>
+<p>then we proceed as normal, and let the resync process fix up any mistakes (see
+below).</p>
+<p>When is our partial state likely to be correct?</p>
+<ul>
+<li>It's more accurate the closer we are to the partial join event. (So we should
+ideally complete the resync as soon as possible.)</li>
+<li>Non-member events: we will have received them as part of the partial join
+response, if they were part of the room state at that point. We may
+incorrectly accept or reject updates to that state (at first because we lack
+remote membership information; later because of compounding errors), so these
+can become incorrect over time.</li>
+<li>Local members' memberships: we are the only ones who can create join and
+knock events for our users. We can't be completely confident in the
+correctness of bans, invites and kicks from other homeservers, but the resync
+process should correct any mistakes.</li>
+<li>Remote members' memberships: we did not receive these in the /send_join
+response, so we have essentially no idea if these are correct or not.</li>
+</ul>
+<p>In short, we deem it acceptable to trust the partial state for non-membership
+and local membership events. For remote membership events, we wait for the
+resync to complete, at which point we have the full state of the room and can
+proceed as normal.</p>
+<h3 id="fixing-the-approximation-with-a-resync"><a class="header" href="#fixing-the-approximation-with-a-resync">Fixing the approximation with a resync</a></h3>
+<p>The partial-state approximation is only a temporary affair. In the background,
+synapse beings a "resync" process. This is a continuous loop, starting at the
+partial join event and proceeding downwards through the event graph. For each
+<code>E</code> seen in the room since partial join, Synapse will fetch </p>
+<ul>
+<li>the event ids in the state of the room before <code>E</code>, via
+<a href="https://spec.matrix.org/v1.5/server-server-api/#get_matrixfederationv1state_idsroomid"><code>/state_ids</code></a>;</li>
+<li>the event ids in the full auth chain of <code>E</code>, included in the <code>/state_ids</code>
+response; and</li>
+<li>any events from the previous two bullets that Synapse hasn't persisted, via
+<a href="https://spec.matrix.org/v1.5/server-server-api/#get_matrixfederationv1stateroomid">`/state</a>.</li>
+</ul>
+<p>This means Synapse has (or can compute) the full state before <code>E</code>, which allows
+Synapse to properly authorise or reject <code>E</code>. At this point ,the event
+is considered to have "full state" rather than "partial state". We record this
+by removing <code>E</code> from the <code>partial_state_events</code> table.</p>
+<p>[<strong>TODO:</strong> Does Synapse persist a new state group for the full state
+before <code>E</code>, or do we alter the (partial-)state group in-place? Are state groups
+ever marked as partially-stated? ]</p>
+<p>This scheme means it is possible for us to have accepted and sent an event to
+clients, only to reject it during the resync. From a client's perspective, the
+effect is similar to a retroactive
+state change due to state resolution---i.e. a "state reset".<sup class="footnote-reference"><a href="#3">2</a></sup></p>
+<div class="footnote-definition" id="3"><sup class="footnote-definition-label">2</sup>
+<p>Clients should refresh caches to detect such a change. Rumour has it that
+sliding sync will fix this.</p>
+</div>
+<p>When all events since the join <code>J</code> have been fully-stated, the room resync
+process is complete. We record this by removing the room from
+<code>partial_state_rooms</code>.</p>
+<h2 id="faster-joins-on-workers"><a class="header" href="#faster-joins-on-workers">Faster joins on workers</a></h2>
+<p>For the time being, the resync process happens on the master worker.
+A new replication stream <code>un_partial_stated_room</code> is added. Whenever a resync
+completes and a partial-state room becomes fully stated, a new message is sent
+into that stream containing the room ID.</p>
+<h2 id="notes-on-specific-cases"><a class="header" href="#notes-on-specific-cases">Notes on specific cases</a></h2>
+<blockquote>
+<p><strong>NB.</strong> The notes below are rough. Some of them are hidden under <code><details></code>
+disclosures because they have yet to be implemented in mainline Synapse.</p>
+</blockquote>
+<h3 id="creating-events-during-a-partial-join"><a class="header" href="#creating-events-during-a-partial-join">Creating events during a partial join</a></h3>
+<p>When sending out messages during a partial join, we assume our partial state is
+accurate and proceed as normal. For this to have any hope of succeeding at all,
+our partial state must contain an entry for each of the (type, state key) pairs
+<a href="https://spec.matrix.org/v1.3/rooms/v10/#authorization-rules">specified by the auth rules</a>:</p>
+<ul>
+<li><code>m.room.create</code></li>
+<li><code>m.room.join_rules</code></li>
+<li><code>m.room.power_levels</code></li>
+<li><code>m.room.third_party_invite</code></li>
+<li><code>m.room.member</code></li>
+</ul>
+<p>The first four of these should be present in the state before <code>J</code> that is given
+to us in the partial join response; only membership events are omitted. In order
+for us to consider the user joined, we must have their membership event. That
+means the only possible omission is the target's membership in an invite, kick
+or ban.</p>
+<p>The worst possibility is that we locally invite someone who is banned according to
+the full state, because we lack their ban in our current partial state. The rest
+of the federation---at least, those who are fully joined---should correctly
+enforce the <a href="https://spec.matrix.org/v1.3/client-server-api/#room-membership">membership transition constraints</a>. So any the erroneous invite should be ignored by fully-joined
+homeservers and resolved by the resync for partially-joined homeservers.</p>
+<p>In more generality, there are two problems we're worrying about here:</p>
+<ul>
+<li>We might create an event that is valid under our partial state, only to later
+find out that is actually invalid according to the full state.</li>
+<li>Or: we might refuse to create an event that is invalid under our partial
+state, even though it would be perfectly valid under the full state.</li>
+</ul>
+<p>However we expect such problems to be unlikely in practise, because</p>
+<ul>
+<li>We trust that the room has sensible power levels, e.g. that bad actors with
+high power levels are demoted before their ban.</li>
+<li>We trust that the resident server provides us up-to-date power levels, join
+rules, etc.</li>
+<li>State changes in rooms are relatively infrequent, and the resync period is
+relatively quick.</li>
+</ul>
+<h4 id="sending-out-the-event-over-federation"><a class="header" href="#sending-out-the-event-over-federation">Sending out the event over federation</a></h4>
+<p><strong>TODO:</strong> needs prose fleshing out.</p>
+<p>Normally: send out in a fed txn to all HSes in the room.
+We only know that some HSes were in the room at some point. Wat do.
+Send it out to the list of servers from the first join.
+<strong>TODO</strong> what do we do here if we have full state?
+If the prev event was created by us, we can risk sending it to the wrong HS. (Motivation: privacy concern of the content. Not such a big deal for a public room or an encrypted room. But non-encrypted invite-only...)
+But don't want to send out sensitive data in other HS's events in this way.</p>
+<p>Suppose we discover after resync that we shouldn't have sent out one our events (not a prev_event) to a target HS. Not much we can do.
+What about if we didn't send them an event but shouldn't've?
+E.g. what if someone joined from a new HS shortly after you did? We wouldn't talk to them.
+Could imagine sending out the "Missed" events after the resync but... painful to work out what they shuld have seen if they joined/left.
+Instead, just send them the latest event (if they're still in the room after resync) and let them backfill.(?)</p>
+<ul>
+<li>Don't do this currently.</li>
+<li>If anyone who has received our messages sends a message to a HS we missed, they can backfill our messages</li>
+<li>Gap: rooms which are infrequently used and take a long time to resync.</li>
+</ul>
+<h3 id="joining-after-a-partial-join"><a class="header" href="#joining-after-a-partial-join">Joining after a partial join</a></h3>
+<p><strong>NB.</strong> Not yet implemented.</p>
+<details>
+<p><strong>TODO:</strong> needs prose fleshing out. Liase with Matthieu. Explain why /send_join
+(Rich was surprised we didn't just create it locally. Answer: to try and avoid
+a join which then gets rejected after resync.)</p>
+<p>We don't know for sure that any join we create would be accepted.
+E.g. the joined user might have been banned; the join rules might have changed in a way that we didn't realise... some way in which the partial state was mistaken.
+Instead, do another partial make-join/send-join handshake to confirm that the join works.</p>
+<ul>
+<li>Probably going to get a bunch of duplicate state events and auth events.... but the point of partial joins is that these should be small. Many are already persisted = good.</li>
+<li>What if the second send_join response includes a different list of reisdent HSes? Could ignore it.
+<ul>
+<li>Could even have a special flag that says "just make me a join", i.e. don't bother giving me state or servers in room. Deffo want the auth chain tho.</li>
+</ul>
+</li>
+<li>SQ: wrt device lists it's a lot safer to ignore it!!!!!</li>
+<li>What if the state at the second join is inconsistent with what we have? Ignore it?</li>
+</ul>
+</details>
+<h3 id="leaving-and-kicks-and-bans-after-a-partial-join"><a class="header" href="#leaving-and-kicks-and-bans-after-a-partial-join">Leaving (and kicks and bans) after a partial join</a></h3>
+<p><strong>NB.</strong> Not yet implemented.</p>
+<details>
+<p>When you're fully joined to a room, to have <code>U</code> leave a room their homeserver
+needs to</p>
+<ul>
+<li>create a new leave event for <code>U</code> which will be accepted by other homeservers,
+and</li>
+<li>send that event <code>U</code> out to the homeservers in the federation.</li>
+</ul>
+<p>When is a leave event accepted? See
+<a href="https://spec.matrix.org/v1.5/rooms/v10/#authorization-rules">v10 auth rules</a>:</p>
+<blockquote>
+<ol start="4">
+<li>If type is m.room.member: [...]
+>
+> 5. If membership is leave:
+>
+> 1. If the sender matches state_key, allow if and only if that user’s current membership state is invite, join, or knock.
+2. [...]</li>
+</ol>
+</blockquote>
+<p>I think this means that (well-formed!) self-leaves are governed entirely by
+4.5.1. This means that if we correctly calculate state which says that <code>U</code> is
+invited, joined or knocked and include it in the leave's auth events, our event
+is accepted by checks 4 and 5 on incoming events.</p>
+<blockquote>
+<ol start="4">
+<li>Passes authorization rules based on the event’s auth events, otherwise
+> it is rejected.</li>
+<li>Passes authorization rules based on the state before the event, otherwise
+> it is rejected.</li>
+</ol>
+</blockquote>
+<p>The only way to fail check 6 is if the receiving server's current state of the
+room says that <code>U</code> is banned, has left, or has no membership event. But this is
+fine: the receiving server already thinks that <code>U</code> isn't in the room.</p>
+<blockquote>
+<ol start="6">
+<li>Passes authorization rules based on the current state of the room,
+> otherwise it is “soft failed”.</li>
+</ol>
+</blockquote>
+<p>For the second point (publishing the leave event), the best thing we can do is
+to is publish to all HSes we know to be currently in the room. If they miss that
+event, they might send us traffic in the room that we don't care about. This is
+a problem with leaving after a "full" join; we don't seek to fix this with
+partial joins.</p>
+<p>(With that said: there's nothing machine-readable in the /send response. I don't
+think we can deduce "destination has left the room" from a failure to /send an
+event into that room?)</p>
+<h4 id="can-we-still-do-this-during-a-partial-join"><a class="header" href="#can-we-still-do-this-during-a-partial-join">Can we still do this during a partial join?</a></h4>
+<p>We can create leave events and can choose what gets included in our auth events,
+so we can be sure that we pass check 4 on incoming events. For check 5, we might
+have an incorrect view of the state before an event.
+The only way we might erroneously think a leave is valid is if</p>
+<ul>
+<li>the partial state before the leave has <code>U</code> joined, invited or knocked, but</li>
+<li>the full state before the leave has <code>U</code> banned, left or not present,</li>
+</ul>
+<p>in which case the leave doesn't make anything worse: other HSes already consider
+us as not in the room, and will continue to do so after seeing the leave.</p>
+<p>The remaining obstacle is then: can we safely broadcast the leave event? We may
+miss servers or incorrectly think that a server is in the room. Or the
+destination server may be offline and miss the transaction containing our leave
+event.This should self-heal when they see an event whose <code>prev_events</code> descends
+from our leave.</p>
+<p>Another option we considered was to use federation <code>/send_leave</code> to ask a
+fully-joined server to send out the event on our behalf. But that introduces
+complexity without much benefit. Besides, as Rich put it,</p>
+<blockquote>
+<p>sending out leaves is pretty best-effort currently</p>
+</blockquote>
+<p>so this is probably good enough as-is.</p>
+<h4 id="cleanup-after-the-last-leave"><a class="header" href="#cleanup-after-the-last-leave">Cleanup after the last leave</a></h4>
+<p><strong>TODO</strong>: what cleanup is necessary? Is it all just nice-to-have to save unused
+work?</p>
+</details>
<div style="break-before: page; page-break-before: always;"></div><h1 id="internal-documentation"><a class="header" href="#internal-documentation">Internal Documentation</a></h1>
<p>This section covers implementation documentation for various parts of Synapse.</p>
<p>If a developer is planning to make a change to a feature of Synapse, it can be useful for
|
