From 306ba25c38f864280c9f78a06816d713f1113416 Mon Sep 17 00:00:00 2001 From: erikjohnston Date: Wed, 13 Dec 2023 16:39:14 +0000 Subject: [PATCH] deploy: 930dc9e2d3efd6d82b86c2205b80d6ccb9b4bb86 --- develop/consent_tracking.html | 2 +- develop/development/git.html | 6 +- .../synapse_architecture/streams.html | 6 +- develop/index.html | 8 +-- develop/metrics-howto.html | 4 +- develop/modules/writing_a_module.html | 2 +- develop/print.html | 66 +++++++++---------- develop/sso_mapping_providers.html | 4 +- develop/systemd-with-workers/index.html | 8 +-- develop/templates.html | 2 +- develop/upgrade.html | 14 ++-- develop/usage/administration/request_log.html | 2 +- ...anding_synapse_through_grafana_graphs.html | 6 +- .../configuration/config_documentation.html | 2 +- develop/welcome_and_overview.html | 8 +-- 15 files changed, 70 insertions(+), 70 deletions(-) diff --git a/develop/consent_tracking.html b/develop/consent_tracking.html index 3e753eae97..969c6abe48 100644 --- a/develop/consent_tracking.html +++ b/develop/consent_tracking.html @@ -176,7 +176,7 @@ database and shows a success page.

To enable this, first create templates for the policy and success pages. These should be stored on the local filesystem.

These templates use the Jinja2 templating language, -and docs/privacy_policy_templates +and docs/privacy_policy_templates gives examples of the sort of thing that can be done.

Note that the templates must be stored under a name giving the language of the template - currently this must always be en (for "English"); diff --git a/develop/development/git.html b/develop/development/git.html index cd675a4207..854bb64b23 100644 --- a/develop/development/git.html +++ b/develop/development/git.html @@ -168,10 +168,10 @@ before. Here, by way of an arbitrary example, is the top of git log --grap

Note how the commit comment explains clearly what is changing and why. Also note the absence of merge commits, as well as the absence of commits called things like (to pick a few culprits): -“pep8”, “fix broken +“pep8”, “fix broken test”, -“oops”, -“typo”, or “Who's +“oops”, +“typo”, or “Who's the president?”.

There are a number of reasons why keeping a clean commit history is a good thing:

diff --git a/develop/development/synapse_architecture/streams.html b/develop/development/synapse_architecture/streams.html index 485b50dbab..9b8fb5f8b7 100644 --- a/develop/development/synapse_architecture/streams.html +++ b/develop/development/synapse_architecture/streams.html @@ -160,7 +160,7 @@

Streams

-

Synapse has a concept of "streams", which are roughly described in id_generators.py. +

Synapse has a concept of "streams", which are roughly described in id_generators.py. Generally speaking, streams are a series of notifications that something in Synapse's database has changed that the application might need to respond to. For example:

-

See synapse.replication.tcp.streams for the full list of streams.

+

See synapse.replication.tcp.streams for the full list of streams.

It is very helpful to understand the streams mechanism when working on any part of Synapse that needs to respond to changes—especially if those changes are made by different workers. -To that end, let's describe streams formally, paraphrasing from the docstring of AbstractStreamIdGenerator.

+To that end, let's describe streams formally, paraphrasing from the docstring of AbstractStreamIdGenerator.

Definition

A stream is an append-only log T1, T2, ..., Tn, ... of facts1 which grows over time. Only "writers" can add facts to a stream, and there may be multiple writers.

diff --git a/develop/index.html b/develop/index.html index ee4408d5a2..3000c91d2b 100644 --- a/develop/index.html +++ b/develop/index.html @@ -200,7 +200,7 @@ following documentation:

  • Read the Contributing Guide. It is meant to walk new contributors through the process of developing and submitting a -change to the Synapse codebase (which is hosted on +change to the Synapse codebase (which is hosted on GitHub).

  • @@ -210,9 +210,9 @@ how to lint an test your code.

  • -

    Look at the issue tracker for +

    Look at the issue tracker for bugs to fix or features to add. If you're new, it may be best to start with -those labeled good first +those labeled good first issue.

  • @@ -228,7 +228,7 @@ do so!

  • And finally, contribute to this documentation! The source for which is -located here.

    +located here.

    • Reporting a security vulnerability

    diff --git a/develop/metrics-howto.html b/develop/metrics-howto.html index 7ae0bae87f..8a18e621eb 100644 --- a/develop/metrics-howto.html +++ b/develop/metrics-howto.html @@ -239,8 +239,8 @@ the listener port configured with the metrics resource.

    Restart Prometheus.

  • -

    Consider using the grafana dashboard -and required recording rules

    +

    Consider using the grafana dashboard +and required recording rules

    • Monitoring workers

    diff --git a/develop/modules/writing_a_module.html b/develop/modules/writing_a_module.html index 3db68cf8e7..9a1525490c 100644 --- a/develop/modules/writing_a_module.html +++ b/develop/modules/writing_a_module.html @@ -168,7 +168,7 @@ the synapse.module_api.ModuleApi class. The configuration is a dict either the output of the module's parse_config static method (see below), or the configuration associated with the module in Synapse's configuration file.

    See the documentation for the ModuleApi class -here.

    +here.

    When Synapse runs with several modules configured

    If Synapse is running with other modules configured, the order each module appears in within the modules section of the Synapse configuration file might restrict what it can diff --git a/develop/print.html b/develop/print.html index 599fd0e164..c267fcf4ed 100644 --- a/develop/print.html +++ b/develop/print.html @@ -198,7 +198,7 @@ following documentation:

  • Read the Contributing Guide. It is meant to walk new contributors through the process of developing and submitting a -change to the Synapse codebase (which is hosted on +change to the Synapse codebase (which is hosted on GitHub).

  • @@ -208,9 +208,9 @@ how to lint an test your code.

  • -

    Look at the issue tracker for +

    Look at the issue tracker for bugs to fix or features to add. If you're new, it may be best to start with -those labeled good first +those labeled good first issue.

  • @@ -226,7 +226,7 @@ do so!

  • And finally, contribute to this documentation! The source for which is -located here.

    +located here.

    • Reporting a security vulnerability

    @@ -2503,7 +2503,7 @@ becomes stable.

    As announced with the release of Synapse 1.47.0, the deprecated user_may_create_room_with_invites module callback has been removed.

    Modules relying on it can instead implement user_may_invite -and use the get_room_state +and use the get_room_state module API to infer whether the invite is happening while creating a room (see this function as an example). Alternately, modules can also implement on_create_room.

    Upgrading to v1.52.0

    @@ -2540,7 +2540,7 @@ longer supported upstream.

    The user_may_create_room_with_invites is deprecated and will be removed in a future version of Synapse. Modules implementing this callback can instead implement user_may_invite -and use the get_room_state +and use the get_room_state module API method to infer whether the invite is happening in the context of creating a room.

    We plan to remove this callback in January 2022.

    @@ -2573,8 +2573,8 @@ federation requests.

    Delete Room API.

    User-interactive authentication fallback templates can now display errors

    This may affect you if you make use of custom HTML templates for the -reCAPTCHA (synapse/res/templates/recaptcha.html) or -terms (synapse/res/templates/terms.html) fallback pages.

    +reCAPTCHA (synapse/res/templates/recaptcha.html) or +terms (synapse/res/templates/terms.html) fallback pages.

    The template is now provided an error variable if the authentication process failed. See the default templates linked above for an example.

    Removal of out-of-date email pushers

    @@ -2958,7 +2958,7 @@ endpoint can be handled

    update your reverse proxy configuration to reflect this change.

    New HTML templates

    A new HTML template, -password_reset_confirmation.html, +password_reset_confirmation.html, has been added to the synapse/res/templates directory. If you are using a custom template directory, you may want to copy the template over and modify it.

    @@ -3038,7 +3038,7 @@ INSERT INTO background_updates (update_name, progress_json, depends_on) VALUES is configured to use SSO and a custom sso_redirect_confirm_template_dir configuration then these templates will need to be copied from -synapse/res/templates into that directory.

    +synapse/res/templates into that directory.

    Synapse SSO Plugins Method Deprecation

    Plugins using the complete_sso_login method of synapse.module_api.ModuleApi should update to using the async/await @@ -3169,7 +3169,7 @@ included.

    Synapse will expect these files to exist inside the configured template directory, and will fail to start if they are absent. To view the default templates, see -synapse/res/templates.

    +synapse/res/templates.

    3pid verification changes

    Note: As of this release, users will be unable to add phone numbers or email addresses to their accounts, without changes to the Synapse @@ -4933,7 +4933,7 @@ caches:

    If you are running multiple workers, you must individually update the worker config file and send this signal to each worker process.

    -

    If you're using the example systemd service +

    If you're using the example systemd service file in Synapse's contrib directory, you can send a SIGHUP signal by using systemctl reload matrix-synapse.

    @@ -7823,7 +7823,7 @@ remote endpoint at 10.1.2.3:9999.

    Templates

    Synapse uses parametrised templates to generate the content of emails it sends and webpages it shows to users.

    -

    By default, Synapse will use the templates listed here. +

    By default, Synapse will use the templates listed here. Server admins can configure an additional directory for Synapse to look for templates in, allowing them to specify custom templates:

    templates:
@@ -8902,7 +8902,7 @@ usually returned as part of the Default OpenID Mapping Provider
 
    Synapse has a built-in OpenID mapping provider if a custom provider isn't
 specified in the config. It is located at
-synapse.handlers.oidc.JinjaOidcMappingProvider.
    
+synapse.handlers.oidc.JinjaOidcMappingProvider.
    
 
    SAML Mapping Providers
    
 
    The SAML mapping provider can be customized by editing the
 saml2_config.user_mapping_provider.module
@@ -9017,7 +9017,7 @@ complete registration using methods from the ModuleApi.
    
 
    Default SAML Mapping Provider
    
 
    Synapse has a built-in SAML mapping provider if a custom provider isn't
 specified in the config. It is located at
-synapse.handlers.saml.DefaultSamlMappingProvider.
    
+synapse.handlers.saml.DefaultSamlMappingProvider.
    
 
    
 This page of the Synapse documentation is now deprecated. For up to date
 documentation on setting up or writing a password auth provider module, please see
@@ -9477,7 +9477,7 @@ database and shows a success page.
    
 
    To enable this, first create templates for the policy and success pages.
 These should be stored on the local filesystem.
    
 
    These templates use the Jinja2 templating language,
-and docs/privacy_policy_templates
+and docs/privacy_policy_templates
 gives examples of the sort of thing that can be done.
    
 
    Note that the templates must be stored under a name giving the language of the
 template - currently this must always be en (for "English");
@@ -9958,7 +9958,7 @@ the synapse.module_api.ModuleApi class. The configuration is a dict
 either the output of the module's parse_config static method (see below), or the
 configuration associated with the module in Synapse's configuration file.
    
 
    See the documentation for the ModuleApi class
-here.
    
+here.
    
 
    When Synapse runs with several modules configured
    
 
    If Synapse is running with other modules configured, the order each module appears in
 within the modules section of the Synapse configuration file might restrict what it can
@@ -11983,9 +11983,9 @@ managing workers. It provides a matrix-synapse service for the mast
 well as a matrix-synapse-worker@ service template for any workers you
 require. Additionally, to group the required services, it sets up a
 matrix-synapse.target.
    
-
    See the folder system
+
    See the folder system
 for the systemd unit files.
    
-
    The folder workers
+
    The folder workers
 contains an example configuration for the generic_worker worker.
    
 
    Synapse configuration files
    
 
    See the worker documentation for information on how to set up the
@@ -12012,7 +12012,7 @@ the provided *.service files accordingly.
    
 
    Set up
    
 
      
 
    1. Adjust synapse configuration files as above.
      2. 
-
    2. Copy the *.service and *.target files in system
+
    3. Copy the *.service and *.target files in system
 to /etc/systemd/system.
      4. 
 
    4. Run systemctl daemon-reload to tell systemd to load the new unit files.
      5. 
 
    5. Run systemctl enable matrix-synapse.service. This will configure the
@@ -12047,7 +12047,7 @@ systemctl restart matrix-synapse.target
 
      Hardening
      
 
      Optional: If further hardening is desired, the file
 override-hardened.conf may be copied from
-contrib/systemd/override-hardened.conf
+contrib/systemd/override-hardened.conf
 in this repository to the location
 /etc/systemd/system/matrix-synapse.service.d/override-hardened.conf (the
 directory may have to be created). It enables certain sandboxing features in
@@ -15608,8 +15608,8 @@ the listener port configured with the metrics resource.
      
 
      Restart Prometheus.
      
 
      6. 
 
    6. 
-
      Consider using the grafana dashboard
-and required recording rules
      
+
      Consider using the grafana dashboard
+and required recording rules
      
 
      7. 
 
    
 
    Monitoring workers
    
@@ -15938,11 +15938,11 @@ registered accounts on the homeserver.
    
 
    It is possible to monitor much of the internal state of Synapse using Prometheus
 metrics and Grafana.
 A guide for configuring Synapse to provide metrics is available here
-and information on setting up Grafana is here.
+and information on setting up Grafana is here.
 In this setup, Prometheus will periodically scrape the information Synapse provides and
 store a record of it over time. Grafana is then used as an interface to query and
 present this information through a series of pretty graphs.
    
-
    Once you have grafana set up, and assuming you're using our grafana dashboard template, look for the following graphs when debugging a slow/overloaded Synapse:
    
+
    Once you have grafana set up, and assuming you're using our grafana dashboard template, look for the following graphs when debugging a slow/overloaded Synapse:
    
 
    Message Event Send Time
    
 
    image
    
 
    This, along with the CPU and Memory graphs, is a good way to check the general health of your Synapse instance. It represents how long it takes for a user on your homeserver to send a message.
    
@@ -15969,7 +15969,7 @@ present this information through a series of pretty graphs.
    
 
    This is quite a useful graph. It shows how many times Synapse attempts to retrieve a piece of data from a cache which the cache did not contain, thus resulting in a call to the database. We can see here that the _get_joined_profile_from_event_id cache is being requested a lot, and often the data we're after is not cached.
    
 
    Cross-referencing this with the Eviction Rate graph, which shows that entries are being evicted from _get_joined_profile_from_event_id quite often:
    
 
    image
    
-
    we should probably consider raising the size of that cache by raising its cache factor (a multiplier value for the size of an individual cache). Information on doing so is available here (note that the configuration of individual cache factors through the configuration file is available in Synapse v1.14.0+, whereas doing so through environment variables has been supported for a very long time). Note that this will increase Synapse's overall memory usage.
    
+
    we should probably consider raising the size of that cache by raising its cache factor (a multiplier value for the size of an individual cache). Information on doing so is available here (note that the configuration of individual cache factors through the configuration file is available in Synapse v1.14.0+, whereas doing so through environment variables has been supported for a very long time). Note that this will increase Synapse's overall memory usage.
    
 
    Forward Extremities
    
 
    image
    
 
    Forward extremities are the leaf events at the end of a DAG in a room, aka events that have no children. The more that exist in a room, the more state resolution that Synapse needs to perform (hint: it's an expensive operation). While Synapse has code to prevent too many of these existing at one time in a room, bugs can sometimes make them crop up again.
    
@@ -16180,7 +16180,7 @@ WHERE room_stats_state.room_id = event_json.room_id" | psql -d synapse -h l
 
    Compression tool
    
 
    There is a tool at https://github.com/matrix-org/rust-synapse-compress-state which can compress the state_groups_state on a room by-room basis (essentially, it reduces the number of "full" state groups). This can result in dramatic reductions of the storage used.
    
 
    Request log format
    
-
    HTTP request logs are written by synapse (see synapse/http/site.py for details).
    
+
    HTTP request logs are written by synapse (see synapse/http/site.py for details).
    
 
    See the following for how to decode the dense data available from the default logging configuration.
    
 
    2020-10-01 12:00:00,000 - synapse.access.http.8008 - 311 - INFO - PUT-1000- 192.168.0.1 - 8008 - {another-matrix-server.com} Processed request: 0.100sec/-0.000sec (0.000sec, 0.000sec) (0.001sec/0.090sec/3) 11B !200 "PUT /_matrix/federation/v1/send/1600000000000 HTTP/1.1" "Synapse/1.20.1" [0 dbevts]
 -AAAAAAAAAAAAAAAAAAAAA-   -BBBBBBBBBBBBBBBBBBBBBB-   -C-   -DD-   -EEEEEE-  -FFFFFFFFF-   -GG-    -HHHHHHHHHHHHHHHHHHHHHHH-                     -IIIIII- -JJJJJJJ-  -KKKKKK-, -LLLLLL-  -MMMMMMM- -NNNNNN- O  -P- -QQ-  -RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR-   -SSSSSSSSSSSS-   -TTTTTT-
@@ -17065,10 +17065,10 @@ before. Here, by way of an arbitrary example, is the top of git log --grap
 
    Note how the commit comment explains clearly what is changing and why. Also
 note the absence of merge commits, as well as the absence of commits called
 things like (to pick a few culprits):
-“pep8”, “fix broken
+“pep8”, “fix broken
 test”,
-“oops”,
-“typo”, or “Who's
+“oops”,
+“typo”, or “Who's
 the president?”.
    
 
    There are a number of reasons why keeping a clean commit history is a good
 thing:
    
@@ -18544,7 +18544,7 @@ minimal.
    
 the classes interact, can be found in
 synapse/replication/tcp/__init__.py
    
 
    Streams
    
-
    Synapse has a concept of "streams", which are roughly described in id_generators.py.
+
    Synapse has a concept of "streams", which are roughly described in id_generators.py.
 Generally speaking, streams are a series of notifications that something in Synapse's database has changed that the application might need to respond to.
 For example:
    
 
      
@@ -18552,9 +18552,9 @@ For example:
      
 
    • The account data stream reports changes to users' account data.
      • 
 
    • The to-device stream reports when a device has a new to-device message.
      • 
 
    
-
    See synapse.replication.tcp.streams for the full list of streams.
    
+
    See synapse.replication.tcp.streams for the full list of streams.
    
 
    It is very helpful to understand the streams mechanism when working on any part of Synapse that needs to respond to changes—especially if those changes are made by different workers.
-To that end, let's describe streams formally, paraphrasing from the docstring of AbstractStreamIdGenerator.
    
+To that end, let's describe streams formally, paraphrasing from the docstring of AbstractStreamIdGenerator.
    
 
    Definition
    
 
    A stream is an append-only log T1, T2, ..., Tn, ... of facts1 which grows over time.
 Only "writers" can add facts to a stream, and there may be multiple writers.
    
diff --git a/develop/sso_mapping_providers.html b/develop/sso_mapping_providers.html
index 1081f5d053..78b8d7f8f3 100644
--- a/develop/sso_mapping_providers.html
+++ b/develop/sso_mapping_providers.html
@@ -300,7 +300,7 @@ usually returned as part of the Default OpenID Mapping Provider
 
    Synapse has a built-in OpenID mapping provider if a custom provider isn't
 specified in the config. It is located at
-synapse.handlers.oidc.JinjaOidcMappingProvider.
    
+synapse.handlers.oidc.JinjaOidcMappingProvider.
    
 
    SAML Mapping Providers
    
 
    The SAML mapping provider can be customized by editing the
 saml2_config.user_mapping_provider.module
@@ -415,7 +415,7 @@ complete registration using methods from the ModuleApi.
    
 
    Default SAML Mapping Provider
    
 
    Synapse has a built-in SAML mapping provider if a custom provider isn't
 specified in the config. It is located at
-synapse.handlers.saml.DefaultSamlMappingProvider.
    
+synapse.handlers.saml.DefaultSamlMappingProvider.
    
 
                     
 
diff --git a/develop/systemd-with-workers/index.html b/develop/systemd-with-workers/index.html
index 7fb197be27..4061654a3b 100644
--- a/develop/systemd-with-workers/index.html
+++ b/develop/systemd-with-workers/index.html
@@ -165,9 +165,9 @@ managing workers. It provides a matrix-synapse service for the mast
 well as a matrix-synapse-worker@ service template for any workers you
 require. Additionally, to group the required services, it sets up a
 matrix-synapse.target.
    
-
    See the folder system
+
    See the folder system
 for the systemd unit files.
    
-
    The folder workers
+
    The folder workers
 contains an example configuration for the generic_worker worker.
    
 
    Synapse configuration files
    
 
    See the worker documentation for information on how to set up the
@@ -194,7 +194,7 @@ the provided *.service files accordingly.
    
 
    Set up
    
 
      
 
    1. Adjust synapse configuration files as above.
      2. 
-
    2. Copy the *.service and *.target files in system
+
    3. Copy the *.service and *.target files in system
 to /etc/systemd/system.
      4. 
 
    4. Run systemctl daemon-reload to tell systemd to load the new unit files.
      5. 
 
    5. Run systemctl enable matrix-synapse.service. This will configure the
@@ -229,7 +229,7 @@ systemctl restart matrix-synapse.target
 
      Hardening
      
 
      Optional: If further hardening is desired, the file
 override-hardened.conf may be copied from
-contrib/systemd/override-hardened.conf
+contrib/systemd/override-hardened.conf
 in this repository to the location
 /etc/systemd/system/matrix-synapse.service.d/override-hardened.conf (the
 directory may have to be created). It enables certain sandboxing features in
diff --git a/develop/templates.html b/develop/templates.html
index 4c5b1bdb21..00f6d621df 100644
--- a/develop/templates.html
+++ b/develop/templates.html
@@ -162,7 +162,7 @@
                         
      Templates
      
 
      Synapse uses parametrised templates to generate the content of emails it sends and
 webpages it shows to users.
      
-
      By default, Synapse will use the templates listed here.
+
      By default, Synapse will use the templates listed here.
 Server admins can configure an additional directory for Synapse to look for templates
 in, allowing them to specify custom templates:
      
 
      templates:
diff --git a/develop/upgrade.html b/develop/upgrade.html
index f00194b71f..b76caa81e8 100644
--- a/develop/upgrade.html
+++ b/develop/upgrade.html
@@ -955,7 +955,7 @@ becomes stable.
      
 
      As announced with the release of Synapse 1.47.0,
 the deprecated user_may_create_room_with_invites module callback has been removed.
      
 
      Modules relying on it can instead implement user_may_invite
-and use the get_room_state
+and use the get_room_state
 module API to infer whether the invite is happening while creating a room (see this function
 as an example). Alternately, modules can also implement on_create_room.
      
 
      Upgrading to v1.52.0
      
@@ -992,7 +992,7 @@ longer supported upstream.
      
 
      The user_may_create_room_with_invites is deprecated and will be removed in a future
 version of Synapse. Modules implementing this callback can instead implement
 user_may_invite
-and use the get_room_state
+and use the get_room_state
 module API method to infer whether the invite is happening in the context of creating a
 room.
      
 
      We plan to remove this callback in January 2022.
      
@@ -1025,8 +1025,8 @@ federation requests.
      
 Delete Room API.
      
 
      User-interactive authentication fallback templates can now display errors
      
 
      This may affect you if you make use of custom HTML templates for the
-reCAPTCHA (synapse/res/templates/recaptcha.html) or
-terms (synapse/res/templates/terms.html) fallback pages.
      
+reCAPTCHA (synapse/res/templates/recaptcha.html) or
+terms (synapse/res/templates/terms.html) fallback pages.
      
 
      The template is now provided an error variable if the authentication
 process failed. See the default templates linked above for an example.
      
 
      Removal of out-of-date email pushers
      
@@ -1410,7 +1410,7 @@ endpoint can be handled
      
 update your reverse proxy configuration to reflect this change.
      
 
      New HTML templates
      
 
      A new HTML template,
-password_reset_confirmation.html,
+password_reset_confirmation.html,
 has been added to the synapse/res/templates directory. If you are
 using a custom template directory, you may want to copy the template
 over and modify it.
      
@@ -1490,7 +1490,7 @@ INSERT INTO background_updates (update_name, progress_json, depends_on) VALUES
 is configured to use SSO and a custom
 sso_redirect_confirm_template_dir configuration then these templates
 will need to be copied from
-synapse/res/templates into that directory.
      
+synapse/res/templates into that directory.
      
 
      Synapse SSO Plugins Method Deprecation
      
 
      Plugins using the complete_sso_login method of
 synapse.module_api.ModuleApi should update to using the async/await
@@ -1621,7 +1621,7 @@ included.
      
 
      Synapse will expect these files to exist inside the configured template
 directory, and will fail to start if they are absent. To view the
 default templates, see
-synapse/res/templates.
      
+synapse/res/templates.
      
 
      3pid verification changes
      
 
      Note: As of this release, users will be unable to add phone numbers or
 email addresses to their accounts, without changes to the Synapse
diff --git a/develop/usage/administration/request_log.html b/develop/usage/administration/request_log.html
index e426f8a613..ca966d58ae 100644
--- a/develop/usage/administration/request_log.html
+++ b/develop/usage/administration/request_log.html
@@ -160,7 +160,7 @@
                         
 
                         
      Request log format
      
-
      HTTP request logs are written by synapse (see synapse/http/site.py for details).
      
+
      HTTP request logs are written by synapse (see synapse/http/site.py for details).
      
 
      See the following for how to decode the dense data available from the default logging configuration.
      
 
      2020-10-01 12:00:00,000 - synapse.access.http.8008 - 311 - INFO - PUT-1000- 192.168.0.1 - 8008 - {another-matrix-server.com} Processed request: 0.100sec/-0.000sec (0.000sec, 0.000sec) (0.001sec/0.090sec/3) 11B !200 "PUT /_matrix/federation/v1/send/1600000000000 HTTP/1.1" "Synapse/1.20.1" [0 dbevts]
 -AAAAAAAAAAAAAAAAAAAAA-   -BBBBBBBBBBBBBBBBBBBBBB-   -C-   -DD-   -EEEEEE-  -FFFFFFFFF-   -GG-    -HHHHHHHHHHHHHHHHHHHHHHH-                     -IIIIII- -JJJJJJJ-  -KKKKKK-, -LLLLLL-  -MMMMMMM- -NNNNNN- O  -P- -QQ-  -RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR-   -SSSSSSSSSSSS-   -TTTTTT-
diff --git a/develop/usage/administration/understanding_synapse_through_grafana_graphs.html b/develop/usage/administration/understanding_synapse_through_grafana_graphs.html
index 051d85c464..11c85d56b1 100644
--- a/develop/usage/administration/understanding_synapse_through_grafana_graphs.html
+++ b/develop/usage/administration/understanding_synapse_through_grafana_graphs.html
@@ -163,11 +163,11 @@
 
      It is possible to monitor much of the internal state of Synapse using Prometheus
 metrics and Grafana.
 A guide for configuring Synapse to provide metrics is available here
-and information on setting up Grafana is here.
+and information on setting up Grafana is here.
 In this setup, Prometheus will periodically scrape the information Synapse provides and
 store a record of it over time. Grafana is then used as an interface to query and
 present this information through a series of pretty graphs.
      
-
      Once you have grafana set up, and assuming you're using our grafana dashboard template, look for the following graphs when debugging a slow/overloaded Synapse:
      
+
      Once you have grafana set up, and assuming you're using our grafana dashboard template, look for the following graphs when debugging a slow/overloaded Synapse:
      
 
      Message Event Send Time
      
 
      image
      
 
      This, along with the CPU and Memory graphs, is a good way to check the general health of your Synapse instance. It represents how long it takes for a user on your homeserver to send a message.
      
@@ -194,7 +194,7 @@ present this information through a series of pretty graphs.
      
 
      This is quite a useful graph. It shows how many times Synapse attempts to retrieve a piece of data from a cache which the cache did not contain, thus resulting in a call to the database. We can see here that the _get_joined_profile_from_event_id cache is being requested a lot, and often the data we're after is not cached.
      
 
      Cross-referencing this with the Eviction Rate graph, which shows that entries are being evicted from _get_joined_profile_from_event_id quite often:
      
 
      image
      
-
      we should probably consider raising the size of that cache by raising its cache factor (a multiplier value for the size of an individual cache). Information on doing so is available here (note that the configuration of individual cache factors through the configuration file is available in Synapse v1.14.0+, whereas doing so through environment variables has been supported for a very long time). Note that this will increase Synapse's overall memory usage.
      
+
      we should probably consider raising the size of that cache by raising its cache factor (a multiplier value for the size of an individual cache). Information on doing so is available here (note that the configuration of individual cache factors through the configuration file is available in Synapse v1.14.0+, whereas doing so through environment variables has been supported for a very long time). Note that this will increase Synapse's overall memory usage.
      
 
      Forward Extremities
      
 
      image
      
 
      Forward extremities are the leaf events at the end of a DAG in a room, aka events that have no children. The more that exist in a room, the more state resolution that Synapse needs to perform (hint: it's an expensive operation). While Synapse has code to prevent too many of these existing at one time in a room, bugs can sometimes make them crop up again.
      
diff --git a/develop/usage/configuration/config_documentation.html b/develop/usage/configuration/config_documentation.html
index 02fb965b31..f0c18150a6 100644
--- a/develop/usage/configuration/config_documentation.html
+++ b/develop/usage/configuration/config_documentation.html
@@ -1367,7 +1367,7 @@ caches:
 
      
 
      If you are running multiple workers, you must individually update the worker
 config file and send this signal to each worker process.
      
-
      If you're using the example systemd service
+
      If you're using the example systemd service
 file in Synapse's contrib directory, you can send a SIGHUP signal by using
 systemctl reload matrix-synapse.
      
 
      
diff --git a/develop/welcome_and_overview.html b/develop/welcome_and_overview.html
index ee4408d5a2..3000c91d2b 100644
--- a/develop/welcome_and_overview.html
+++ b/develop/welcome_and_overview.html
@@ -200,7 +200,7 @@ following documentation:
      
 
    6. 
 
      Read the Contributing Guide. It is meant
 to walk new contributors through the process of developing and submitting a
-change to the Synapse codebase (which is hosted on
+change to the Synapse codebase (which is hosted on
 GitHub).
      
 
      7. 
 
    7. 
@@ -210,9 +210,9 @@ how to lint an
 test your code.
      
 
      8. 
 
    8. 
-
      Look at the issue tracker for
+
      Look at the issue tracker for
 bugs to fix or features to add. If you're new, it may be best to start with
-those labeled good first
+those labeled good first
 issue.
      
 
      9. 
 
    9. 
@@ -228,7 +228,7 @@ do so!
      
 
      10. 
 
    10. 
 
      And finally, contribute to this documentation! The source for which is
-located here.
      
+located here.
      
 
      11. 
 
 
      Reporting a security vulnerability