Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Commit

Permalink
(#5849) Convert rst to markdown (#6040)
Browse files Browse the repository at this point in the history
Converting some of the rst documentation to markdown.  Attempted to
preserve whitespace and line breaks to minimize cosmetic change.
  • Loading branch information
dstipp authored and richvdh committed Sep 17, 2019
1 parent 70c5282 commit 379d2a8
Show file tree
Hide file tree
Showing 41 changed files with 2,088 additions and 2,192 deletions.
2 changes: 1 addition & 1 deletion CONTRIBUTING.rst
Original file line number Diff line number Diff line change
Expand Up @@ -56,7 +56,7 @@ Code style

All Matrix projects have a well-defined code-style - and sometimes we've even
got as far as documenting it... For instance, synapse's code style doc lives
at https://github.com/matrix-org/synapse/tree/master/docs/code_style.rst.
at https://github.com/matrix-org/synapse/tree/master/docs/code_style.md.

Please ensure your changes match the cosmetic style of the existing project,
and **never** mix cosmetic and functional changes in the same commit, as it
Expand Down
4 changes: 2 additions & 2 deletions INSTALL.md
Original file line number Diff line number Diff line change
Expand Up @@ -373,7 +373,7 @@ is suitable for local testing, but for any practical use, you will either need
to enable a reverse proxy, or configure Synapse to expose an HTTPS port.

For information on using a reverse proxy, see
[docs/reverse_proxy.rst](docs/reverse_proxy.rst).
[docs/reverse_proxy.md](docs/reverse_proxy.md).

To configure Synapse to expose an HTTPS port, you will need to edit
`homeserver.yaml`, as follows:
Expand Down Expand Up @@ -446,7 +446,7 @@ on your server even if `enable_registration` is `false`.
## Setting up a TURN server

For reliable VoIP calls to be routed via this homeserver, you MUST configure
a TURN server. See [docs/turn-howto.rst](docs/turn-howto.rst) for details.
a TURN server. See [docs/turn-howto.md](docs/turn-howto.md) for details.

## URL previews

Expand Down
6 changes: 3 additions & 3 deletions README.rst
Original file line number Diff line number Diff line change
Expand Up @@ -115,7 +115,7 @@ Registering a new user from a client

By default, registration of new users via Matrix clients is disabled. To enable
it, specify ``enable_registration: true`` in ``homeserver.yaml``. (It is then
recommended to also set up CAPTCHA - see `<docs/CAPTCHA_SETUP.rst>`_.)
recommended to also set up CAPTCHA - see `<docs/CAPTCHA_SETUP.md>`_.)

Once ``enable_registration`` is set to ``true``, it is possible to register a
user via `riot.im <https://riot.im/app/#/register>`_ or other Matrix clients.
Expand Down Expand Up @@ -186,7 +186,7 @@ Almost all installations should opt to use PostreSQL. Advantages include:
synapse itself.

For information on how to install and use PostgreSQL, please see
`docs/postgres.rst <docs/postgres.rst>`_.
`docs/postgres.md <docs/postgres.md>`_.

.. _reverse-proxy:

Expand All @@ -201,7 +201,7 @@ It is recommended to put a reverse proxy such as
doing so is that it means that you can expose the default https port (443) to
Matrix clients without needing to run Synapse with root privileges.

For information on configuring one, see `<docs/reverse_proxy.rst>`_.
For information on configuring one, see `<docs/reverse_proxy.md>`_.

Identity Servers
================
Expand Down
2 changes: 1 addition & 1 deletion UPGRADE.rst
Original file line number Diff line number Diff line change
Expand Up @@ -103,7 +103,7 @@ Upgrading to v1.2.0
===================

Some counter metrics have been renamed, with the old names deprecated. See
`the metrics documentation <docs/metrics-howto.rst#renaming-of-metrics--deprecation-of-old-names-in-12>`_
`the metrics documentation <docs/metrics-howto.md#renaming-of-metrics--deprecation-of-old-names-in-12>`_
for details.

Upgrading to v1.1.0
Expand Down
1 change: 1 addition & 0 deletions changelog.d/5849.doc
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
Convert documentation to markdown (from rst)
29 changes: 15 additions & 14 deletions docs/CAPTCHA_SETUP.rst → docs/CAPTCHA_SETUP.md
Original file line number Diff line number Diff line change
@@ -1,30 +1,31 @@
# Overview
Captcha can be enabled for this home server. This file explains how to do that.
The captcha mechanism used is Google's ReCaptcha. This requires API keys from Google.

Getting keys
------------
## Getting keys

Requires a public/private key pair from:

https://developers.google.com/recaptcha/
<https://developers.google.com/recaptcha/>

Must be a reCAPTCHA v2 key using the "I'm not a robot" Checkbox option

Setting ReCaptcha Keys
----------------------
## Setting ReCaptcha Keys

The keys are a config option on the home server config. If they are not
visible, you can generate them via --generate-config. Set the following value::
visible, you can generate them via `--generate-config`. Set the following value:

recaptcha_public_key: YOUR_PUBLIC_KEY
recaptcha_private_key: YOUR_PRIVATE_KEY

recaptcha_public_key: YOUR_PUBLIC_KEY
recaptcha_private_key: YOUR_PRIVATE_KEY
In addition, you MUST enable captchas via:

In addition, you MUST enable captchas via::
enable_registration_captcha: true

enable_registration_captcha: true
## Configuring IP used for auth

Configuring IP used for auth
----------------------------
The ReCaptcha API requires that the IP address of the user who solved the
captcha is sent. If the client is connecting through a proxy or load balancer,
it may be required to use the X-Forwarded-For (XFF) header instead of the origin
IP address. This can be configured using the x_forwarded directive in the
it may be required to use the `X-Forwarded-For` (XFF) header instead of the origin
IP address. This can be configured using the `x_forwarded` directive in the
listeners section of the homeserver.yaml configuration file.
4 changes: 2 additions & 2 deletions docs/MSC1711_certificates_FAQ.md
Original file line number Diff line number Diff line change
Expand Up @@ -147,7 +147,7 @@ your domain, you can simply route all traffic through the reverse proxy by
updating the SRV record appropriately (or removing it, if the proxy listens on
8448).

See [reverse_proxy.rst](reverse_proxy.rst) for information on setting up a
See [reverse_proxy.md](reverse_proxy.md) for information on setting up a
reverse proxy.

#### Option 3: add a .well-known file to delegate your matrix traffic
Expand Down Expand Up @@ -319,7 +319,7 @@ We no longer actively recommend against using a reverse proxy. Many admins will
find it easier to direct federation traffic to a reverse proxy and manage their
own TLS certificates, and this is a supported configuration.
See [reverse_proxy.rst](reverse_proxy.rst) for information on setting up a
See [reverse_proxy.md](reverse_proxy.md) for information on setting up a
reverse proxy.
### Do I still need to give my TLS certificates to Synapse if I am using a reverse proxy?
Expand Down
7 changes: 7 additions & 0 deletions docs/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
# Synapse Documentation

This directory contains documentation specific to the `synapse` homeserver.

All matrix-generic documentation now lives in its own project, located at [matrix-org/matrix-doc](https://github.com/matrix-org/matrix-doc)

(Note: some items here may be moved to [matrix-org/matrix-doc](https://github.com/matrix-org/matrix-doc) at some point in the future.)
6 changes: 0 additions & 6 deletions docs/README.rst

This file was deleted.

81 changes: 81 additions & 0 deletions docs/ancient_architecture_notes.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,81 @@
> **Warning**
> These architecture notes are spectacularly old, and date back
> to when Synapse was just federation code in isolation. This should be
> merged into the main spec.
# Server to Server

## Server to Server Stack

To use the server to server stack, home servers should only need to
interact with the Messaging layer.

The server to server side of things is designed into 4 distinct layers:

1. Messaging Layer
2. Pdu Layer
3. Transaction Layer
4. Transport Layer

Where the bottom (the transport layer) is what talks to the internet via
HTTP, and the top (the messaging layer) talks to the rest of the Home
Server with a domain specific API.

1. **Messaging Layer**

This is what the rest of the Home Server hits to send messages, join rooms,
etc. It also allows you to register callbacks for when it get's notified by
lower levels that e.g. a new message has been received.

It is responsible for serializing requests to send to the data
layer, and to parse requests received from the data layer.

2. **PDU Layer**

This layer handles:

- duplicate `pdu_id`'s - i.e., it makes sure we ignore them.
- responding to requests for a given `pdu_id`
- responding to requests for all metadata for a given context (i.e. room)
- handling incoming backfill requests

So it has to parse incoming messages to discover which are metadata and
which aren't, and has to correctly clobber existing metadata where
appropriate.

For incoming PDUs, it has to check the PDUs it references to see
if we have missed any. If we have go and ask someone (another
home server) for it.

3. **Transaction Layer**

This layer makes incoming requests idempotent. i.e., it stores
which transaction id's we have seen and what our response were.
If we have already seen a message with the given transaction id,
we do not notify higher levels but simply respond with the
previous response.

`transaction_id` is from "`GET /send/<tx_id>/`"

It's also responsible for batching PDUs into single transaction for
sending to remote destinations, so that we only ever have one
transaction in flight to a given destination at any one time.

This is also responsible for answering requests for things after a
given set of transactions, i.e., ask for everything after 'ver' X.

4. **Transport Layer**

This is responsible for starting a HTTP server and hitting the
correct callbacks on the Transaction layer, as well as sending
both data and requests for data.

## Persistence

We persist things in a single sqlite3 database. All database queries get
run on a separate, dedicated thread. This that we only ever have one
query running at a time, making it a lot easier to do things in a safe
manner.

The queries are located in the `synapse.persistence.transactions` module,
and the table information in the `synapse.persistence.tables` module.
59 changes: 0 additions & 59 deletions docs/ancient_architecture_notes.rst

This file was deleted.

31 changes: 31 additions & 0 deletions docs/application_services.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
# Registering an Application Service

The registration of new application services depends on the homeserver used.
In synapse, you need to create a new configuration file for your AS and add it
to the list specified under the `app_service_config_files` config
option in your synapse config.

For example:

```yaml
app_service_config_files:
- /home/matrix/.synapse/<your-AS>.yaml
```
The format of the AS configuration file is as follows:
```yaml
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>
namespaces:
users: # List of users we're interested in
- exclusive: <bool>
regex: <regex>
- ...
aliases: [] # List of aliases we're interested in
rooms: [] # List of room ids we're interested in
```
See the [spec](https://matrix.org/docs/spec/application_service/unstable.html) for further details on how application services work.
35 changes: 0 additions & 35 deletions docs/application_services.rst

This file was deleted.

Loading

0 comments on commit 379d2a8

Please sign in to comment.