meta data for this page
Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
digital:server:matrixsynapsemisc [2020/06/17 18:44] natrius |
digital:server:matrixsynapsemisc [2022/05/18 13:08] (current) natrius [Tombstone Event] |
||
---|---|---|---|
Line 3: | Line 3: | ||
Different things, sometimes advanced and some things that just did not fit in the regular guide. | Different things, sometimes advanced and some things that just did not fit in the regular guide. | ||
- | ## Show the public rooms on the server | + | ## Matrix tips they don't tell you |
+ | https:// | ||
- | '' | + | ## Interesting projects |
- | ## Add an SRV Record | + | Moved to [[digital: |
- | To use the domain '' | + | ## Synpase maintenance tools |
- | After the A record is set up, create a SRV Record that looks like | + | * https:// |
- | < | + | ## Show the public rooms on the server |
- | So, for example use | + | * '' |
- | + | ||
- | < | + | |
- | + | ||
- | and when creating the Synapse server use '' | + | |
- | + | ||
- | Stefan | + | |
- | + | ||
- | So, when I'm using the domain matrix.example.com and want to use exmpale.com for the registration and so on, i should use SRV. | + | |
- | If i'm using example.com and making the redirect with nginx, there is no need for a SRV record? | + | |
- | + | ||
- | kythyria | + | |
- | + | ||
- | The SRV record is how other servers find your server (and putting matrix federation behind a reverse proxy is a bit fragile) | + | |
- | + | ||
- | Mathijs | + | |
- | the relevant url is where the federated servers can connect to you | + | |
- | + | ||
- | kythyria | + | |
- | + | ||
- | It's so your server_name (what' | + | |
- | + | ||
- | ### Example 1 | + | |
- | + | ||
- | '' | + | |
- | + | ||
- | ### Example 2 | + | |
- | + | ||
- | '' | + | |
- | + | ||
- | SRV needed. | + | |
- | + | ||
- | ### Example 3 | + | |
- | + | ||
- | FIXME '' | + | |
- | + | ||
- | SRV needed? | + | |
- | + | ||
- | #### Set up SRV (**DON' | + | |
- | + | ||
- | By setting an SRV record in your DNS provider, it is possible to tell other matrix servers where to connect to the server, pointing them to the correct hostname and port, in this example the default port (8448) is still used: | + | |
- | + | ||
- | < | + | |
- | _matrix._tcp.example.com. 3600 IN SRV 10 5 443 synapse.example.com. | + | |
- | </code> | + | |
- | + | ||
- | There is still an A record needed, pointing to the IP-addess of synapse on the subdomain (matrix.example.com). This way others can add your user with '' | + | |
- | + | ||
- | + | ||
- | ## .well-known section | + | |
- | + | ||
- | Mathijs | + | |
- | it's a little early, but you could also add a section about .well-known | + | |
- | which just means you have nginx serve a json file on example.com/ | + | |
- | I did it for apache, but it's probably fairly easy for nginx as well | + | |
- | + | ||
- | Mathijs | + | |
- | https://matrix.org/ | + | |
- | if you like reading spec :) | + | |
- | + | ||
- | #### Proper explanation | + | |
- | + | ||
- | .well-known will be checked before SRV gets checked. | + | |
## Coturn | ## Coturn | ||
Line 88: | Line 27: | ||
opening ports | opening ports | ||
- | |||
- | ## Optional Adminshell | ||
- | |||
- | If you forgot to write '' | ||
- | |||
- | There is another way but you should **not** work like that all the time because its not secure. There is a reason you have to write '' | ||
- | |||
- | ## Synpase maintenance tools | ||
- | |||
- | https:// | ||
## Installing Bots | ## Installing Bots | ||
Line 119: | Line 48: | ||
< | < | ||
- | ## How calls work | + | ## Exclude a server from a channel |
+ | |||
+ | Info von https:// | ||
+ | |||
+ | - Chat `/ | ||
+ | - `Send Custom Event` | ||
+ | - Rechts unten roten Button `Event` drücken | ||
+ | - Event Type: `m.room.server_acl` | ||
+ | - State Key: leer lassen | ||
+ | - Event Content: | ||
+ | |||
+ | ``` | ||
+ | { | ||
+ | " | ||
+ | " | ||
+ | ], | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | ] | ||
+ | } | ||
+ | ``` | ||
+ | |||
+ | - `Send` | ||
+ | - Bestätigung im Chat `[CURRENT USER] set the server ACLs for this room.` | ||
+ | |||
+ | ## Send custom reactions to messages (Powerlevel 1) | ||
+ | |||
+ | - Chat `/ | ||
+ | - `Send Custom Event` | ||
+ | - Event Type: `m.reaction` | ||
+ | - Event Content: | ||
+ | |||
+ | ``` | ||
+ | { | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | } | ||
+ | } | ||
+ | ``` | ||
+ | |||
+ | ## Send custom reactions to messages (Powerlevel >=50) | ||
+ | |||
+ | - Chat `/ | ||
+ | - `Send Custom Event` | ||
+ | - Rechts unten roten Button `Event` drücken | ||
+ | - Event Type: `m.reaction` | ||
+ | - State Key: leer lassen | ||
+ | - Event Content: | ||
+ | |||
+ | ``` | ||
+ | { | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | } | ||
+ | } | ||
+ | ``` | ||
+ | |||
+ | - `Send` | ||
+ | |||
+ | ## Tombstone Event | ||
- | Info about WebRTC: | + | https://spec.matrix.org/latest/client-server-api/#events-17 |
- | more or less like this? https://i.imgur.com/ | + | - Chat `/ |
+ | - `Send Custom Event` | ||
+ | - Rechts unten roten Button `Event` drücken | ||
+ | - Event Type: `m.room.tombstone` | ||
+ | - State Key: leer lassen | ||
+ | - Event Content: | ||
- | more or less, but you can also host your own jitsi server if you want, jitsi is still FOSS and self-hostable | + | ``` |
+ | { | ||
+ | " | ||
+ | " | ||
+ | } | ||
+ | ``` | ||
- | also, it's a bit nitpicky, but if you use turn, you may want to add a turn-server on the left side, because it's not synapse that does the webrtc relay | + | - `Send` |
- | jitsi is its own thing, riot just allows integrating jitsi in riot | + | ## Inactive room blocking address |
- | note that you can self-host jitsi, but if you want riot to use your selfhosted jitsi by default when opening conference calls you'll also want to host an integrations server (ie dimension) | + | IIRC you can request release of alias at support@matrix.org |
- | everybody assumes it works like this, but it doesn' | ||
- | @dave: | ||
- | not sure I quite understand the second diagram | ||
- | in the first. media won't always go through both turn servers | ||
- | the key to thinking about turn, I find, is that the TURN server is a thing that essentially pretends to be your client, but somewhere else on the internet | ||
- | and it tunnels the traffic back to you | ||
- | so you have a point of presence with your own internet connection, and then a second point of presence in your turn server once its opened a channel for you | ||
- | and you then present both of those options to ther other side as ways to talk to you | ||
- | equally you can also use your turn server as a route to send packets out to the internet to talk to the other party |