* Update docs/configuring-playbook-base-domain-serving.md: add an anchor link to docs/configuring-dns.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update documentation related to server delegation
Summary:
- Add explanation about server delegation and DNS setting for it to docs/configuring-dns.md; "delegation" is a technical term and it is worth being explained simply
- Edit explanation about delegation to docs/configuring-playbook-base-domain-serving.md
- Use common expressions
- Simplify explanation about delegation on docs/configuring-well-known.md and move explanation about the alternative which avoids involving the base domain from that page to its upper documentation, which is docs/howto-server-delegation.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Apply suggestions from code review
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update docs/configuring-dns.md: iterate
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Fix an anchor link to howto-srv-server-delegation.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Minor rewording
* Minor rewording
* Minor rewording
---------
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Co-authored-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update docs/configuring-well-known.md: remove redundant information
For example, anchor links to the headers are distractive as these headers are displayed by scrolling a bit.
Also: edit section headers
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-well-known.md: add "Support service discovery" as a type of well-known service discovery
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-well-known.md: recategorize the sections about installing well-known files on the base domain's server
The commit merges the content of the option 2 with the section above, as both explain how to serve the base domain via the playbook and claim it is the easy way of installing well-known files, and therefore the content is repetitive.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-well-known.md: create a section for types of well-known service discovery mechanism
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-well-known.md: add a link to the Matrix Specification, to which MSC 1929 was implemented
MSC 1929 has no longer been for an early adopter.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-well-known.md: iterate
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-base-domain-serving.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update docs/configuring-well-known.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update docs/installing.md: iterate
Summary:
- Try to reflect review comments
- Declare that the shorter user identifier is recommended
- Add a note about installing the server matrix.example.com directly, with the link to the FAQ entry
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/installing.md: replace the anchor link to docs/configuring-well-known.md with one to docs/howto-server-delegation.md
Service Discovery via .well-known files is one of the two ways for server delegation, and it is possible to set up server delegation via a DNS SRV record instead (though it is more advanced and complicated), so it should be more proper to use the words "delegation/redirection" than "service discovery".
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-well-known.md: fix a typo
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
---------
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Co-authored-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Replace "Element" with "Element Web"
- If Element indicates the web application, then it is changed to Element Web.
- If it indicates clients branded with Element such as Element desktop, web, mobile clients, then it is changed to Element clients.
- If it is combined with location sharing functionality, it is not changed.
with other some changes, including:
- Change "app.element.io" anchor link to "https://github.com/element-hq/element-web" on README.md, following other documentation files
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Replace "SchildiChat" with "SchildiChat Web"
- If SchildiChat indicates the web application, then it is changed to SchildiChat Web.
- If it indicates clients branded with SchildiChat such as SchildiChat desktop, web, mobile clients, then it is changed to SchildiChat clients.
- If it is combined with location sharing functionality, it is not changed.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Rename configuring-playbook-client-schildichat.md to configuring-playbook-client-schildichat-web.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Rename configuring-playbook-client-element.md to configuring-playbook-client-element-web.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
---------
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Co-authored-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
In nginx reverse-proxy, when the upstream server relies on SNI, the reverser-proxy may return 502 by follow error:
```
*10 SSL_do_handshake() failed (SSL: error:0A000410:SSL routines::sslv3 alert handshake failure:SSL alert number 40) while SSL handshaking to upstream, client: 172.19.0.1, server: example.host, request: "GET /.well-known/matrix/client HTTP/2.0", upstream: "https://<ip>/.well-known/matrix/client", host: "<domain>"
```
This problem often arises when the upstream server is behind the CDN, setting `proxy_ssl_server_name` to `on` will solve it.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1931
This does 2 things:
- it fixes the syntax for `matrix_id`. Starting strings with `@` is
invalid YAML, so such strings need to be wrapped in single or double
quotes
- it makes use of the `matrix_domain` variable instead of hardcoding the
domain name. This should be more and mistake-proof (typos or people
mistaking their domain - matrix. vs base domain)
With most people on Synapse v0.99+ and Synapse v1.0 now available,
we should no longer try to be backward compatible with Synapse 0.34,
because this just complicates the instructions for no good reason.
This is provoked by Github issue #46.
No client had made use of the well-known mechanism
so far, so the set up performed by this playbook was not tested
and turned out to be a little deficient.
Even though /.well-known/matrix/client is usually requested with a
simple request (no preflight), it's still considered cross-origin
and [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS)
applies. Thus, the file always needs to be served with the appropriate
`Access-Control-Allow-Origin` header.
Github issue #46 attempts to fix it at the "reverse-proxying" layer,
which may work, but would need to be done for every server.
It's better if it's done "upstream", so that all reverse-proxy
configurations can benefit.
