65 lines
5.4 KiB
Markdown
65 lines
5.4 KiB
Markdown
---
|
|
title: Matrix is a pain
|
|
date: 2026-10-05T14:37:00
|
|
draft: true
|
|
description: you read the title
|
|
---
|
|
|
|
# Matrix in general
|
|
|
|
Most chat platforms have one signing server, which if you think about it is like the internet having one dns server. If discord goes down, you're kinda fucked. Matrix solves this through communism.
|
|
|
|
## Homeservers and awayservers
|
|
|
|
Homeservers are just servers. On servers you can host users and rooms, and through special properties, rooms can be voice chats or spaces. Pretty simple stuff. The biggest one is, obviously, matrix.org, because signing up is free. Matrix.org also allows free hosting for spaces, the equivalent of discord servers in this context. Spaces are just rooms with special parameters, but we can get to that in a minute. Finally, matrix.org manages federation with other servers. Federation can be oversimplified into lots of encrypted API calls that result in profile information and messages being validated and fetched from a remote homeserver.
|
|
|
|
Using the given certificate, there is a mutual understanding between different homeservers that as long as the cert is right, the enclosed information will be correct as well. Federation used to act over port 8448, resulting in some funky port forwarding, but in matrix 2 and 3, you can make it run in parallel with the http api, only on port 443. This also lets federation leverage ssl instead of dodgy round robin encryption, making man in the middle attacks nearly impossible unless someone manages to steal your private key, not to mention you can run the whole thing behind a reverse proxy.
|
|
|
|
Matrix as a protocol was initially built to be like IRC, with many public connectable rooms and no real worry about impersonation or chat history. Discord then started being shit, meaning there was a demand for an end to end encrypted decentralised chat network that somehow managed to maintain some level of identity. Hence, the whole protocol was rebuilt and iterated on to be what it is today
|
|
|
|
## Running Matrix
|
|
|
|
As usual with apps, there is a server and a client. The officially maintained server is called synapse (who knows why), and is runnable as a docker container fairly easily. Of course, I have to jump through a bunch of nix shaped hoops to get it to work, but other than that I had a server "running" that I could log into almost immediately. However, when DNS is involved, nothing is ever easy.
|
|
|
|
First of all, federation requests don't work through cloudflare's esoteric proxy bullshit, so you have to be on DNS only. Its not as if anyone can hack me, but if you wanted to get a pretty accurate location of where I live, you can do that now I guess. Then there's the not-so-obvious server settings that are basically required if you want anything to work, `dynamic_thumbnails = true` being necessary if you have any icons ever.
|
|
|
|
### WE HATE DNS
|
|
|
|
Beyond that, you have to set headers for the actual domain, and if you don't want to reserve your main url for matrix and matrix only, you have to include .well-known path nonsense. Here's the config for anyone interested:
|
|
|
|
```nginx
|
|
location = /.well-known/matrix/server {
|
|
default_type application/json;
|
|
add_header Access-Control-Allow-Origin "*" always;
|
|
return 200 '{"m.server":"matrix.voidarc.co.uk:443"}';
|
|
}
|
|
location = /.well-known/matrix/client {
|
|
default_type application/json;
|
|
add_header Access-Control-Allow-Origin "*" always;
|
|
return 200 '{"m.homeserver":{"base_url":"https://matrix.voidarc.co.uk"}}';
|
|
}
|
|
```
|
|
|
|
BOTH paths are required for any modern client to be able to federate. In the docs they list the second path as unnecessary, but almost no modern client will accept federation unless the second path is present. At most, with only the server address, you can get private messaging, but you won't be able to join any rooms or let people join any rooms on your server.
|
|
|
|
Just for completeness, this is the header config for the actual matrix domain. This domain should proxy pass to whatever endpoint hosts the /`_matrix/` path.
|
|
|
|
```nginx
|
|
client_max_body_size 100M;
|
|
|
|
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
|
proxy_set_header X-Forwarded-Proto $scheme;
|
|
proxy_set_header Host $host;
|
|
proxy_set_header Access-Control-Allow-Origin: *;
|
|
```
|
|
|
|
Important also to note that a generic cloudflare origin cert (like the default `*.example.com, example.com` cert with an origin CA) will NOT work for matrix. Most other homeservers will ping your server, and then refuse to accept the return packet with a 402 or something because it hasn't been signed against by the actual FQDN. This is simple enough to fix with letsencrypt, just make sure the cert has the same address as whatever you put as the public address in synapse's config file.
|
|
|
|
### Clients and you
|
|
|
|
Matrix is a protocol, not a product. That means anyone can make a new way of interfacing with the protocol, ie a client, and use that to communicate with any other client. It's as simple as that.
|
|
|
|
Synapse is just the server, it provides the protocol endpoints needed to use matrix, but no actual user-facing interface. To actually message people, you need a client. Once again, the most popular is whatever matrix.org reccomends, and that happens to be element. Element is shit, imo. It looks bad, it's bloated, and the desktop version is just a glorified webapp. It also requires either hosting a really heavy service yourself, or relying on someone else's server to stay up. Both pointless options if you want to be decentralised.
|
|
|
|
The best clients are fully local, and the most minimal is iamb. Vim bindings,
|