salix.host

Privacy Is Not Just Encryption

Thu, 20 Aug 2026 00:00:00 +0200

People hear “privacy” and they think of encryption. The idea is clean: your messages get scrambled on one device, unscrambled on another, and nobody in between can read them. End-to-end encryption is a real and important tool. But it is not the whole story. It protects what flows through the pipe, but it does not protect you from the pipe itself.

I keep running into this, both as someone who runs a server and as someone who cares about privacy more broadly. Encryption is necessary, but it is nowhere near sufficient on its own.

Your server still knows who you talk to

Here is something that always surprises people: even with end-to-end encryption turned on, your server can still see a hell of a lot about your conversations. Who you message, when you message them, how often, and for how long. Which rooms you join, which files you share, whether you are online right now.

None of that is “content.” None of it is covered by encryption. But all of it is intimate. A list of your contacts and the timing of your conversations tells a story about your life that most people would not hand over voluntarily.

This is part of why I built salix.host instead of just telling everyone to use Signal. Signal’s encryption is excellent, and I have recommended it plenty of times. But Signal is still a centralized service run by one organization. Your messages are private, but the server still knows who you talk to, when, and how often. And while Signal says they do not store your contacts, groups, or profile data, the server still sees the connection metadata in real-time, including who you talk to, when, and how often, even if it does not keep it.

Matrix gives you a choice. You can pick a server you trust, or one you run yourself. The encryption is the same, but the infrastructure is different. That difference is not a minor detail. It is the difference between renting your digital life from a company and owning a piece of it.

The CAPTCHA I built instead of using Google’s

The same idea shows up in the most unexpected places. Like that weird driving game on salix.host’s registration page.

If you have signed up, you probably noticed it. You survive eighteen seconds of pixel traffic, and if you do not crash, you get a registration token. It is a bit silly, but there is a reason it exists.

Every other site on the internet outsources this problem to Google or Cloudflare. You solve a reCAPTCHA, and in return, Google gets your IP address, your browser fingerprint, and a behavioral profile that feeds into their advertising machine. For a privacy-focused server, that is a contradiction: “We care about your privacy, now please report to Google before entering” is not a very convincing welcome message.

So I built my own. The driving game, the proof-of-work puzzle, the server-side replay validation, the PNG traffic images instead of JSON. None of it is about encryption. It is about not handing your registration data to a third party just to get an account. The privacy boundary does not stop at the message content. It extends to every interaction, including the very first one.

Most people never notice this. They solve the CAPTCHA and move on. But the choice was made for them, by someone else’s server, before they ever typed a message.

Small servers and the laws that threaten them

This is what I keep coming back to: privacy is not just about the messages you send. It is about the systems that carry them.

When you use a service hosted by a large company, you are not just trusting them with your data. You are trusting them with your behavior, your relationships, your habits, your presence. You are trusting them not to be compelled to hand over information, not to change their terms, not to be acquired by someone with different priorities.

Signal has learned this lesson the hard way. They opposed the UK’s Online Safety Bill, and have threatened to leave Canada over similar legislation. They have the resources to fight, and the public profile to make headlines when they do.

But what happens to the small services that cannot afford lawyers? What happens to a homeserver like salix.host when the law says you have to scan messages, whether you want to or not?

This is exactly what Chat Control threatens. I have written about it before, and I will probably write about it again. But the core point is simple: encryption cannot save you from a law that forces you to break it. If the state can compel you to scan messages on your own server, or to build a backdoor into your own software, then the strength of your encryption is irrelevant. The vulnerability is not in the protocol. It is in the infrastructure.

Why I run a server instead of just using one

This is why I frame privacy as an infrastructure problem, not just a cryptography problem. Owning your infrastructure, or at least choosing it carefully, gives you control over the full stack of your digital life.

When you run your own server, you decide:

who can see your metadata
what data is logged, and for how long
whether your server federates with other servers, and on what terms
how your registration process works, and what third parties are involved
what happens when the law comes knocking

You also take on responsibility. Security patches, backups, outages, abuse reports. There is no support desk to call when something breaks at 3am. But there is also no company that can change the rules overnight, no advertiser that can buy access to your data, no government that can compel a service you do not control.

This is not a lifestyle recommendation for everyone. Most people should not have to run their own server to have a private conversation. But the ecosystem needs people who do, because federation only works when there are multiple servers to choose from. If everyone concentrates on a handful of giant platforms, then the infrastructure problem becomes everyone’s problem.

Privacy is a system, not a feature

I did not set out to write a post about infrastructure when I built that driving game. I just wanted to keep bots out without inviting Google in. But it turns out that every privacy decision I make comes back to the same thing: who controls the systems that carry our digital lives.

When I run salix.host on Synapse instead of my experimental Vitis homeserver, I am thinking about reliability as a privacy property. A server that crashes or loses data is not a private server, it is a broken one. When I built the registration dispenser with process separation, I was thinking about limiting the damage if a bug lets an attacker through. When I oppose Chat Control, I am thinking about legal threats to the infrastructure itself.

None of this is about encryption alone. It is about who controls the pipe.

That is why small servers matter. Not because they are perfect, but because they are alternatives. Not because they are easy, but because they are choices. In a world where everything funnels through a handful of giant platforms, a small server run by a real person is a statement that the infrastructure does not have to be owned by someone else.

And sometimes, that is enough.

As always, if you want to talk about this, whether you agree, disagree, or just want to run your own damn server, you know where to find me.

Boring Infrastructure, on Purpose: Why salix.host Runs Synapse While I Build Vitis

Sat, 08 Aug 2026 00:00:00 +0200

salix.host runs Synapse. At the same time, I am building Vitis, an experimental Matrix homeserver in Rust.

That may look a little strange. If I am interested enough in a new homeserver to build one, why do I keep using Synapse in production?

The answer is simple: salix.host has real users. Vitis is still where I am allowed to break things.

Those are two very different jobs.

Real users change the rules

When I run software only for myself, a broken update is annoying. I can restore a backup, read the logs, fix the problem, and call the whole thing a useful lesson.

It is different when other people depend on the server.

A bad update can stop someone from signing in. A database problem can make rooms unavailable. A federation bug can leave messages waiting between servers. Even when a room is end-to-end encrypted, the homeserver still holds the encrypted events and the room data needed to keep everything working.

People did not create an account on salix.host to test my latest database idea. They created one because they wanted a Matrix account that works.

That changes how I make choices. The most interesting option is not always the right option. Sometimes the right choice is the one that has already survived years of strange rooms, failed upgrades, broken network links, and tired administrators.

Boring is a compliment

I call the salix.host setup boring on purpose. In infrastructure, boring is usually good.

Boring software has known behaviour. It has documentation. Other people have already found many of the bad edge cases. When it fails, there is a fair chance that someone else has seen the same problem and written down how to recover from it.

Synapse is not perfect. It can use a lot of resources, its database can become large, and upgrades still need care. Bugs do not disappear just because a project is old.

But Synapse has been used in real Matrix deployments for years. It has a large codebase, a long history, and tools that already understand how it works. Its problems are often known problems. That matters more to me than winning a benchmark or using the newest design.

Reliable software is not software that never fails. That software does not exist. Reliable software is software whose failures are easier to predict, notice, and recover from.

For salix.host, that is a feature.

Then why build Vitis?

Because using reliable software does not mean there is nothing left to improve.

Vitis is my very early Matrix homeserver experiment. It is written in Rust and forked from the Conduit family of homeservers. It is not public yet, it has no releases, and it is not serving real users.

That gives me space to explore ideas without pretending they are ready.

One area is compatibility with the Synapse admin API. Many existing Matrix administration tools are built around Synapse. A different homeserver may support the Matrix protocol correctly and still require a completely different set of admin tools. Supporting useful parts of the Synapse API could make that gap smaller.

I am also looking at how old room state is stored and cleaned up. Matrix rooms collect a lot of state over time. This includes things such as membership, permissions, and room settings. The server also needs enough old state to understand which rules applied to earlier events. Cleaning up unused data can save space, but deleting the wrong data can damage room history or make later events impossible to check. The cleanup needs to be careful, not clever.

Cache management is another part of the work. A cache keeps often-used data in memory so the server can answer faster. The hard part is deciding what to keep, what to remove, and how to stop memory use from growing forever.

Then there is the local smoke-test system. The idea is simple: start a fresh server, perform a set of basic actions, and fail quickly when something important stops working. A small test like that cannot prove the server is safe, but it can catch obvious mistakes before they reach a larger test setup.

None of this makes a very exciting launch screenshot. That is probably why I enjoy it.

Matrix is larger than it first looks

A homeserver can look simple from far away. It accepts requests, stores events, and sends data to other servers.

Then federation enters the room.

A federated server does not only deal with its own users and its own database. It also accepts data from servers run by other people. Some of those servers are slow. Some disappear for weeks and return later. Some have old software. Some send events from rooms with years of complicated history.

The homeserver has to check which events are allowed, keep room state consistent, handle events that arrive late, and continue working when another server does something unexpected. It also needs to support clients, logins, devices, media, moderation, account management, database upgrades, and many other ordinary jobs around the protocol.

This is why a homeserver can pass every small test I wrote and still fail in production. My tests cover the problems I know about. Real rooms are very good at finding the problems I did not imagine.

Synapse has already met a lot of those problems. Vitis has not.

Tests are not the same as trust

A good test suite is important, but production trust needs more than tests.

I need to know what happens when an upgrade stops halfway through. I need to know that a backup can really be restored, not only that a backup file exists. I need to know what happens when the disk becomes full, the database slows down, or another homeserver becomes slow or disappears during a request.

A backup that has never been restored is only a hopeful file.

Monitoring matters too. It is not enough for the process to be running. I need to see when federation queues are stuck, when memory use keeps rising, when database work becomes slow, or when an important task has quietly stopped.

Administration also has to be boring. Creating and disabling accounts, handling abuse, checking federation, reading useful logs, and recovering from mistakes should not require me to edit the database by hand at 3am.

These parts are less fun than designing a new storage system. They are also the parts that decide whether a server is safe to run for other people.

What Vitis would need before production

Vitis does not need to become perfect. It does need to earn trust step by step.

Before I would consider using it for real accounts, I would want at least:

database upgrades that can run safely and fail clearly;
backups that I have restored more than once;
good compatibility with common Matrix clients and other homeservers;
useful monitoring, logs, and administration tools;
long test runs with old rooms, large rooms, and unreliable federation;
a clear way to move back to Synapse if something goes wrong.

That last point is important. A new system is much safer when leaving it is part of the plan. Migration should not be a one-way door.

I would also start small. A private test server with throwaway accounts can find many problems without risking anyone’s real account. After that, I can run my own account on it and learn what daily use feels like. Only much later would it make sense to think about moving a public service.

A fast benchmark would not be enough. A clean codebase would not be enough. Even passing every protocol test would not be enough by itself.

The server would need to survive boring days, boring upgrades, boring backups, and boring failures.

One project, two different jobs

Building Vitis is not a vote against Synapse. Running Synapse is not giving up on Vitis.

Synapse runs the service. Vitis is where I learn, test ideas, and find out which ideas were worse than they looked in my head.

The two projects also help each other. Running Synapse shows me what an administrator actually needs. It reminds me that compatibility, recovery, and clear errors matter just as much as speed. Building Vitis helps me understand the protocol and the storage work below the tools I use every day.

Maybe Vitis will become ready for production one day. Maybe it will stay an experiment and teach me useful things. Both results are fine.

For now, salix.host will keep running Synapse. Vitis will keep breaking in a place where breaking is useful.

That is not a contradiction. It is the line between a project and a service.

A project can be interesting. A service has to be there tomorrow morning.

SimpleX Without Accounts

Sat, 25 Jul 2026 00:00:00 +0200

I already gave SimpleX a section in my private-messenger comparison, but it deserves more than a few paragraphs. It is the newest messenger on that list and, more importantly, the only one built around the idea that the network should not know who its users are at all.

That sounds like a small distinction until you compare it with everything else. Signal still wants a phone number, even if you can hide it from other people. Matrix lets you own your identity, but your server still knows which account is yours. Threema replaces the phone number with a random ID, but that ID still exists.

SimpleX takes a stranger route: no account, no username and no permanent user ID. I like the idea a lot. I also think some of the claims around it deserve a closer look, because a clever protocol does not automatically make a frictionless app or erase every kind of metadata.

An account that does not exist

When you install SimpleX, your device generates cryptographic keys and keeps them locally. It does not register a global identity with a central service. There is no SimpleX equivalent of a phone number, Matrix ID or even a random public account number tying all your conversations together.

Instead, every direct connection gets its own pair of one-way message queues on relay servers. You start a conversation by sharing a link or QR code through another channel. From then on, messages in each direction travel through separate queues. One direction can use SimpleX’s default relays while the other uses different relays, including servers run by you or someone you trust. Ordinary groups are built from many of these pairwise connections; the newer Channels feature uses a different, relay-mediated model that I will come back to later.

From a relay’s point of view, those are separate streams of encrypted blobs. It does not get one convenient account saying that all of these chats belong to the same person. That is the clever part: instead of collecting an identity and promising not to misuse it, SimpleX avoids creating that identity in the first place.

The price of having no account

Of course, removing accounts also removes everything accounts normally do for you.

There is no “find friends by phone number” screen. To add someone, you need to get a link or scan a QR code through some other channel. That is either excellent privacy or annoying friction, depending on whether you are trying to stay anonymous or just get a family group off WhatsApp.

Moving to another phone is less magical too. There is no cloud account waiting to restore your contacts and history after you log in. Your keys and messages live on your device, so moving them means actually transferring the local data. The SimpleX team has made that easier over time, but it still asks more of you than Signal does.

This is the recurring trade-off with SimpleX. The things that make it awkward are often the exact same things that make it private. You cannot remove the server’s knowledge of your identity and then expect every identity-based convenience to keep working unchanged.

Dumb mailboxes, on purpose

The relay servers are basically encrypted mailboxes. They hold queues until the recipient checks in, but they are not part of the end-to-end encryption and cannot read the messages inside them. A relay only needs to know about the anonymous queues it serves, not the people at either end.

You can use the default relays, choose other people’s relays or run your own. Switching does not mean moving an account because, again, there is no account on the server to move. A relay operator can still refuse connections, remove queues or disrupt messages stored on that relay, so it is not powerless. What it cannot do is ban one global SimpleX account everywhere. You can move your connections to queues on other relays without changing identity, although an outage can still be annoying and may interrupt delivery.

That is probably my favourite part of the design. Self-hosting is useful, but SimpleX does not make self-hosting the price of admission. The relays are deliberately unimportant enough that trusting one matters less in the first place.

I have put that into practice now: I run a public salix.host SMP relay at smp.salix.host. The same relay is available as an onion service, and its project page has an add relay button that passes both routes straight to SimpleX. You do not need a salix.host account, and it works alongside any other relays you have configured. It is a personally operated service without an SLA, so use more than one relay rather than turning mine into your only point of failure.

The metadata question

There is still one part of the default setup that bothers me.

Since version 6.0, SimpleX uses private message routing by default when you send to an unknown destination relay. Your client gives each message to a forwarding relay you configured, which passes it to the relay chosen by your contact. The forwarding relay sees your network connection and when you send traffic, but end-to-end encryption hides the destination queue from it. The destination relay sees the queue, but receives the traffic through a shared connection from the forwarding relay instead of seeing your IP address or transport session.

When you receive messages, the relay you chose can still observe your connection and activity while you are online. The SimpleX privacy policy says its preset servers do not log user IP addresses, but a malicious or compromised relay could observe live traffic. Timing data also remains useful to a sufficiently powerful observer. Private routing splits knowledge between relays; it reduces the metadata available to either one, but it does not make traffic analysis impossible.

Tor is useful here, but not as a replacement for private routing. Connecting straight to a destination relay through Tor hides your real IP address, while still allowing that relay to see which queues share a transport session. SimpleX’s packet-by-packet private routing avoids giving the destination relay that view. The stronger setup is to use Tor or another suitable overlay to hide your IP address from the relays you choose while leaving private routing enabled. SimpleX already supports this through a SOCKS proxy, although I would still like to see the app make it easier to set up.

Where it still falls over

SimpleX is young, and sometimes it feels young. The apps have improved a lot, but they are still more fiddly than Signal. Moving keys between devices needs attention, some concepts take explaining, and the whole experience assumes you are willing to understand a little of what is happening underneath.

The bigger limit is traditional groups. A SimpleX group is built from pairwise connections, so every message has to be fanned out to the members separately. SimpleX says this design was intended for groups of roughly 100 people or fewer. Public groups with thousands of members have existed, but sending to each member separately costs traffic, battery and time. Version 6.3 improved the sending process, but did not remove that network cost.

There is an important update here: version 6.5 introduced SimpleX Channels, a beta relay-mediated model for scalable one-to-many publishing. Channels can be public, appear in the SimpleX Directory, retain state and support reading, reactions and comments. That makes SimpleX more useful for broadcasts and public publishing than it used to be. It is not yet the same as a mature, interactive Matrix room or Discord-style community, and SimpleX describes large groups and communities as future uses of the Channels layer.

So if your current use case is shaped like Discord, I would still use Matrix. SimpleX is moving in that direction, but it is not there yet.

Why I am paying attention

For such a young project, SimpleX has built a decent track record. Trail of Bits carried out an implementation assessment of its cryptography and networking in 2022, then a broader protocol-design review in 2024. Neither found a critical issue, but they were not clean bills of health. The first assessment found two medium- and two low-severity issues; SimpleX fixed three in version 4.2. The second found three medium-, one low- and three informational findings; SimpleX says three were improved in version 6.1 and the remaining findings were accepted.

It has also run into the kind of legal pressure that tests the sales pitch. In September 2025, a Moscow court fined SimpleX 800,000 rubles for failing to meet legal obligations imposed on messaging providers. That notice does not say SimpleX refused a specific request for user data. Separately, its architecture limits what relay operators normally have to surrender: they do not host user accounts, profiles or contact lists, and the preset operators say they do not log user IP addresses. Relays can still temporarily hold undelivered encrypted messages and some encrypted public-address data, so “nothing at all” would be too strong.

The project has money behind it now too. Jack Dorsey and Asymmetric Capital Partners put $1.3 million into a pre-seed round in 2024, and Vitalik Buterin donated 128 ETH in 2025. That gives the team more room than most small privacy projects get. It is still venture funding, though, and investors eventually want something back. I would keep half an eye on that rather than pretending funding has no strings attached.

So, should you use it?

SimpleX makes sense if:

you want to avoid giving the service a phone number or permanent network-wide identifier;
most of your conversations are one-to-one or in small trusted groups;
you are willing to trade some polish and convenience for less metadata; and
you do not need mature public rooms or large interactive communities.

It is not the messenger I would hand to everyone who asks for a WhatsApp replacement. Signal is still easier for that. It is not where I would build a community either; Matrix is much better at that job.

But if the question is “which messenger avoids creating a global identity for me?”, SimpleX has the most interesting answer I have seen. It does not ask you to trust a company with that identity. It tries not to create it at all.

That is a strong anonymity property, not a guarantee that nobody can identify you. Your network connection, the way you share a link, information you reveal to contacts, malicious relays and traffic analysis can all matter. The rough edges and those remaining metadata risks keep me from calling the design perfect. Even so, it is one of the few messengers doing something genuinely new, and I think it is worth trying for an evening just to see how different that feels.

As always, if you want to talk about this stuff, you know where to find me.

Keeping Bots Out Without Inviting Google In

Fri, 17 Jul 2026 00:00:00 +0200

If you tried to register on salix.host, you probably noticed the little driving game. You have to survive eighteen seconds of traffic before you get a registration token. It is a bit silly, but there is a reason it exists.

Running an open Matrix server means I need some way to keep automatic signups out. If registration is completely open, bots will find it sooner or later. They can use the accounts for spam, scams, or things I really do not want hosted on my server. Closing registration would solve that, but then normal people cannot join either, which misses the point of running a public server.

The normal answer is adding a CAPTCHA. Usually that means placing a box from Google, Cloudflare, or another large company on the page. It works, but it also means every person who wants an account has to talk to that company first. Their browser sends another request, their IP address goes somewhere else, and sometimes they get asked to identify traffic lights for five minutes because some invisible score did not like them.

That felt a bit wrong for a privacy-focused Matrix server. “We care about your privacy, now please report to Google before entering” is not a very convincing welcome message.

So I made my own.

The first version

The registration system was already using proof of work. The server gives your browser a small SHA-256 puzzle, and the browser tries numbers until it finds the correct one. It takes a few seconds on a normal device, but doing it thousands of times becomes expensive for a spammer.

Proof of work is useful, but by itself it is not enough. A real visitor waits a few seconds once. A bot can solve puzzles all day, especially if the accounts are worth something. It raises the cost, which is good, but it does not really tell humans and scripts apart.

I wanted a second check that needed some interaction, without collecting personal information. For some reason my answer to this was a five-lane road full of badly driven pixel cars and trucks.

The idea was inspired by CAPTCHA Hell, an upcoming game about someone trying to get through a pile of increasingly ridiculous CAPTCHAs. I saw the driving CAPTCHA in it and thought it was funny. Then I started wondering if something like that could work as a real CAPTCHA too. So credit for the strange idea belongs there. I just made my own version and probably took it much too seriously.

You control a small car with a slider. Other vehicles come down the road, some change lanes, and you need to avoid them for eighteen seconds. The car has a bit of momentum, so you cannot instantly jump from one side to the other. If you crash, you can try the same road again.

It is not a scientific test for being human. It is just an annoying enough task that basic signup scripts cannot press a button and receive unlimited accounts.

The browser is not trusted

The obvious problem with a homemade CAPTCHA is that all browser code is visible. Anyone can open the developer tools, read the JavaScript, and change it. If the page simply sent I won to the server, a bot would also send I won, probably much faster than me.

The server therefore does not trust the result reported by the browser. During the game, the browser records the position of the steering slider on every game tick. That list of steering inputs is what gets submitted at the end.

The server then runs the same movement physics again. It starts the car in the middle, applies every steering input, and checks the calculated position against the traffic at that moment. If the replay hits a vehicle, the run is rejected. The browser never gets to decide where the car really was.

There was another issue. If I sent all traffic data as nice structured JSON, a script could read every vehicle position and calculate a perfect route. Instead, the server creates the traffic and renders it into a PNG image. The browser receives the pixels needed to show the road, but not a convenient list saying “truck in lane three at tick 120”.

Of course pixels can still be analysed. I am not claiming I invented some unbreakable bot detector here. But analysing an animated pixel road and producing valid steering input is quite a bit more work than calling an API with the right JSON fields. For a small hobby server, that difference matters.

Making sure the game is fair

Random traffic sounds fun until the game generates a wall of trucks across every lane.

Before sending a challenge, the server checks that the road can actually be completed with the same speed limits as the player’s car. It works backwards through the game and checks which positions still have an escape route. It also rejects roads where sitting in the centre and doing nothing would pass, because then it would be a rather useless driving test.

This part took more work than I expected. Generating random cars is easy. Generating random cars that look unpredictable, require steering, and never put a normal player into an impossible trap is less easy.

Lane-changing cars even blink before moving. That is partly to be fair, and partly because apparently I care about the driving manners of CAPTCHA traffic now.

Several small locks instead of one big lock

The driving game is only one layer. While you are driving, the browser solves the proof-of-work puzzle in the background. The challenge is signed by the server, tied to the visitor’s IP rate-limit bucket, expires after fifteen minutes, and can only be used once. Finishing in less than eighteen seconds is also rejected, for fairly obvious reasons.

There are limits on how many challenges and tokens one address can request, plus a global limit in case somebody arrives with a large number of addresses. IPv6 needs a little care here, because one device can have a huge amount of addresses, so I count them by network instead of pretending every address is a different visitor.

After everything passes, the registration token is valid for ten minutes and can create one account. That is enough time for a person to paste it into Element, but not very useful to someone collecting tokens for later.

None of these protections is perfect alone. Together they make abuse inconvenient enough without making registration terrible for normal people. At least that is the balance I am trying to find.

Keeping the dangerous secret somewhere else

The public dispenser needs permission to hand out registration tokens, but I did not want the public-facing process to hold the Synapse administrator token. If there is a bug in the dispenser, that secret would give an attacker much more power than they should ever get.

So token creation is split into a second, very small service. The public process verifies the puzzle, the driving run, and the rate limits. Only after all of that it asks the second service to mint one token through a local Unix socket.

That second service understands exactly one command: mint. It has its own global rate limit and returns a short-lived, single-use token. It does not listen on a public network port. The public process can talk to it, but cannot read the administrator token it holds.

Process separation is not exciting to show in a screenshot, but it might be the part I care most about. A public web service will always have some attack surface. Giving it fewer secrets makes a mistake less disastrous.

What it does not solve

I know a driving game has accessibility problems. It needs vision and reasonably precise input, and it might be difficult or impossible for some people. That is the biggest weakness of this design. At the moment, contacting me for an account is the fallback, but that is not as good as having an accessible option built into the page. I still need a better answer for this.

It also will not stop a determined attacker forever. Someone could build computer vision for it, automate a browser, or simply pay humans to solve challenges. CAPTCHAs are an arms race and a small custom one does not magically escape that.

What it does stop is cheap, generic automation. There is no standard CAPTCHA-solving service already prepared for this exact strange road. There are no cookies, no fingerprinting, and no third-party script learning who visited the registration page. The temporary IP limits live on my server, where the signup is happening anyway.

That is good enough for my current threat model. salix.host is a small homeserver, not a bank and not the next giant social network. I do not need to defeat every bot on earth. I need to make mass signup more trouble than this server is worth abusing.

And if people get a tiny pixel racing game out of it, honestly, that is nicer than clicking nine blurry bicycles.

Chat Control Passed in the European Parliament. I Am Against It.

Mon, 13 Jul 2026 00:00:00 +0200

You may have seen the headlines this week: Chat Control passed in the European Parliament.

The full situation is more complicated, because of course EU lawmaking cannot be explained without several different proposals, readings and voting rules. But my own opinion is not complicated: I am against Chat Control 1.0, and I am against Chat Control 2.0.

I don’t want companies scanning private messages without suspicion. I don’t want it when the scanning is called “voluntary”, and I especially don’t want it turned into a permanent European system. A private message should be private unless there is a specific reason and proper legal approval to investigate somebody.

Two versions of the same bad idea

What people call Chat Control 1.0 is a temporary exception to the EU’s ePrivacy rules. It allows messaging and email providers to “voluntarily” scan private communications for child sexual abuse material, and to report and remove it. It does not force every provider to scan, but it gives companies the legal space to inspect messages which people reasonably believe are private.

The word “voluntarily” does a lot of work here. The provider may volunteer to scan. The person sending a photo or having a conversation did not volunteer to be monitored. From the user’s side, there is nothing voluntary about it.

This exception existed since 2021 and expired on 3rd of April 2026. In March, Parliament rejected an extension, with 228 voting for the extension, 311 against it and 92 abstaining.

Then there is Chat Control 2.0, officially the permanent Child Sexual Abuse Regulation. It would create permanent rules for online services, including risk assessments, removal and blocking orders, and a new EU Centre on Child Sexual Abuse. The Council and Parliament are still negotiating the final text. It has not passed yet, and I hope it does not pass in a form which permits general scanning of private communication.

The two versions are legally different, but they move in the same direction. Chat Control 1.0 makes private scanning seem normal now. Chat Control 2.0 risks making the system permanent later. I oppose both for the same reason: people who are not suspected of a crime should not have their private communication inspected.

They brought it back after Parliament rejected it

After the March rejection, the extension should have been finished. Instead, on 2nd of July, the Council adopted the Commission’s original proposal as its position and sent it back to Parliament for a second reading. The Council wants the exception restored until 3rd of April 2028.

This second reading had different voting rules. Rejecting or amending the Council position required an absolute majority of all MEPs, not only a majority of those who voted. The threshold was 360.

On 9th of July, 314 MEPs voted to reject the Council position. 276 voted against rejection and 17 abstained. More MEPs voted to reject Chat Control than to keep it, but the rejection still failed because 314 was below the special threshold.

Maybe this follows the official procedure, but I find it very difficult to call the outcome democratic. Parliament rejected the extension in March. A clear majority of votes cast rejected it again in July. Still, the proposal survived. Bringing it back just before the summer break, under rules which made rejection much harder, looks like finding a procedural way around an answer the Council did not like.

This is also why people lose trust in the EU. You cannot tell citizens their representatives voted against a proposal, then say it passed anyway, and expect nobody to be angry about it.

The encryption amendment does not make it good

Parliament did add one important amendment. The exception should not apply to communications which use, used, or will use end-to-end encryption. If that protection remains in the final text, encrypted Signal conversations and encrypted Matrix rooms should be outside its scope.

I am glad this amendment exists. I am still against the proposal.

Unencrypted private messages also deserve privacy. Email does not become public communication because its protection is weaker. And a legal exception encouraging companies to inspect private messages is still wrong even if some encrypted services are excluded.

The official Parliament announcement also makes clear that this is not the final step. The amended text now goes to the Council. It has three months to accept all Parliament’s amendments. If it refuses, Parliament and the Council enter a conciliation procedure to negotiate a common text.

So, as of 13th of July 2026:

Parliament failed to reject Chat Control 1.0, even though more MEPs voted for rejection than against it.
Parliament added an exclusion for end-to-end encrypted communication.
The Council still has to accept that exclusion for the text to become law in this form.
Chat Control 2.0, the permanent and more far-reaching proposal, has not passed.

It would be inaccurate to say that the EU can now scan every encrypted message. Chat Control 1.0 allows providers to scan “voluntarily” and the Parliament text excludes end-to-end encryption. But correcting exaggerated headlines should not become an excuse to defend the proposal. The real version is already bad enough.

Protecting children does not require scanning everybody

Child sexual abuse is real and horrific. Material showing it should be removed, offenders should be investigated, and victims deserve serious support. I don’t question any of that.

What I reject is the idea that opposing mass scanning means opposing child protection. It does not. Police can investigate suspects. Courts can authorise targeted searches. Platforms can act on reports and remove confirmed illegal material. Governments can give investigators and victim-support organisations enough staff and money to do their work properly.

These are actions aimed at abuse and abusers. Scanning the conversations of people who are not suspected of anything is surveillance first and investigation second.

Automated detection is not harmless either. Matching a known illegal image is one thing. Trying to detect unknown material or grooming from ordinary conversations is much less certain. False reports can expose innocent people and deeply private messages to companies, reviewers and authorities. “An algorithm will check it” is not a meaningful privacy protection.

End-to-end encryption cannot magically stay private while a system checks the content. If software inspects a message on the device before it is encrypted, the encryption may still work during transport, but the conversation was already inspected. Moving the scanner to the phone does not solve the privacy problem. It only moves the place where privacy is broken.

Why Chat Control 2.0 worries me even more

Chat Control 1.0 is described as temporary, although temporary EU measures have a strange habit of returning. Chat Control 2.0 is meant to create the permanent framework. The Council’s position on the permanent law includes making the current “voluntary” scanning exception permanent.

Once scanning infrastructure exists, there will always be pressure to use it for more. Today the reason is child sexual abuse. Later somebody will propose terrorism, organised crime, copyright infringement, or another serious subject which makes opposing surveillance politically difficult. The technical system does not know that it was promised for only one purpose.

This is a boundary we should not cross. Private communication should not become a space where everybody is monitored just in case somebody commits a crime.

What it means for small services

I run a Matrix homeserver, so this is not only a theoretical discussion for me. Small independent services don’t have entire legal and compliance departments. If European rules create pressure to scan communication, a small provider may have to build surveillance infrastructure, remove features, stop accepting users, or shut down.

Big companies can pay for scanning systems and lawyers. Smaller privacy-friendly alternatives often cannot. Regulation like this can end up strengthening Meta, Google and Microsoft while making independent services disappear. That would leave people with fewer private choices, not more safety.

For encrypted Matrix rooms, Parliament’s amendment would offer some protection if it survives. But I don’t want protection to depend on one amendment surviving every later negotiation. And I don’t believe unencrypted rooms should be treated as fair targets for general scanning either.

I oppose both versions

Chat Control 1.0 passed an important stage through a process where 314 votes for rejection were not enough. It is not final in its amended form, and the Council may still fight the encryption exclusion. Chat Control 2.0 is still being negotiated and will decide the permanent direction.

I oppose Chat Control 1.0 because it normalises companies scanning private communication without suspicion. I oppose Chat Control 2.0 because it risks making that principle permanent and building the infrastructure for wider surveillance.

If you care about this, contact your MEPs and your national government. National governments form the Council, so they have direct influence over what happens next. Ask them to keep end-to-end encryption outside the temporary law and to reject general scanning in the permanent one. European Parliament has a tool to find your MEPs.

You can also follow Fight Chat Control to stay up to date. It keeps track of the changing proposals, upcoming decisions and positions of EU countries, and also helps you find the right representatives to contact.

For a much more detailed explanation, I also recommend Patrick Breyer’s Chat Control overview. He has followed this proposal for years and keeps a timeline, comparisons of the different texts, background documents and arguments against both versions in one place.

Protecting children and protecting private communication are not opposite goals. We can target criminals, support victims and remove illegal material without treating every person in Europe as a possible suspect.

My private messages are not the government’s messages. They are not Meta’s messages either. They should not be scanned just in case.

Private Messengers Compared

Wed, 08 Jul 2026 00:00:00 +0200

People ask me sometimes why I bother with Matrix when Signal exists. Fair question. There’s a lot of “private” messengers out there and honestly they are all trying to solve slightly different problems. So here’s my take on the ones I actually have opinions about.

Quick disclaimer: I run a Matrix server, so of course I’m biased. I’ll try to be fair anyway.

Signal

Signal is the default answer, and for good reason. The encryption is basically the gold standard, the apps are polished, and it’s easy enough that you can get your parents on it. If someone asks me “what should I use instead of WhatsApp” and they don’t want a lecture, I say Signal.

But it has two problems that bother me. First, it wants your phone number. They added usernames a while ago, so you can hide it from other people, but Signal itself still knows who you are. Second, it’s one centralized service run by one foundation in one country. If Signal goes down, or gets blocked, or makes a decision you don’t like, there is no plan B. You can’t take your account somewhere else. That’s the exact thing I wrote about in my first post.

And this is not theoretical anymore. Signal has been fighting laws in the UK for years, and just recently they threatened to pull out of Canada over a proposed law there. They also said they need something like 50 million dollars a year to keep running. I trust them to fight the good fight, but the point stands: when everything depends on one organization, their problems become your problems.

Matrix

You knew this was coming. Matrix is not an app, it’s a network. Nobody owns it, anyone can run a server (hi), and servers talk to each other like email does. End-to-end encryption is on by default in private chats.

It’s also been a good year for Matrix, honestly. Matrix 2.0 and the new Element X client fixed a lot of the old sluggishness, governments in Europe keep adopting it for their internal comms (France and Germany run huge deployments), and when Discord announced their age verification thing in February, a nice wave of people came looking for alternatives and found Matrix. And that makes sense, because for communities, public rooms, spaces, that whole Discord-shaped use case, Matrix is currently simply the best option on this list. Nothing else here even really tries: Signal groups are private only, and you’ll see later what I think about big groups on SimpleX.

The honest downsides: the experience depends a lot on which client and server you use, encryption in huge public rooms can still be a bit clunky, and metadata (who talks to who, room names, that kind of stuff) is more visible to servers than on Signal. Also the Matrix Foundation itself is chronically underfunded, they say reaching break-even is the goal for this year. The protocol won’t disappear if they struggle, it’s open and the code is everywhere, but it’s a reminder that open infrastructure runs on too little money.

And since I’m being honest, there’s one thing that bothers me as a server admin: how much of Matrix is effectively one company, Element. They employ most of the core developers, they make the flagship clients, and they make Synapse, the server implementation almost everyone runs (including me). In 2023 they relicensed Synapse from Apache to AGPL, with a contributor agreement that lets Element alone sell commercial licenses on top of everyone’s contributions. AGPL is a fine license, but the move made it clear who holds the steering wheel. It’s an open network on paper, and it really is, I can leave any time with the protocol intact. But in practice the health of the ecosystem depends a lot on one company’s business surviving, and I’d sleep better if the server side was more diverse.

Anyway, Matrix still trades some tightness for something I think matters more long term: you’re not renting your identity from a single company. Worst case your server dies, you make an account elsewhere and keep going.

So: Signal is a better product, Matrix is a better network. Pick what you’re optimizing for.

Threema

Threema is interesting because it’s the “pay once, no phone number” option. It’s Swiss, it’s been around forever, and you get a random ID instead of giving your number. The apps are decent and the company had a reasonable track record.

Had, past tense, because I have to be honest here: the original founders left the company back in 2024, and this January a German private equity firm announced they’re acquiring Threema. Maybe nothing changes. But “privacy company gets bought by private equity” is not a sentence that usually ends well, and it’s exactly the risk of trusting one company with your messenger. I’d be careful recommending it right now.

The other catch is that it costs a few euros, which sounds like nothing but is actually a real barrier when you try to move a group chat there. “Just install this app” already loses half the people, “just install this app and pay for it” loses the rest. And it’s still centralized, same story as Signal, just with a different flag on it.

Session

Session took the Signal protocol idea and removed the phone number and the central server. Your messages get routed through a decentralized node network, so in theory nobody can see who is talking to who. No identifier needed at all, you just get a key.

I want to like Session more than I do. The anonymity story is genuinely strong. But they changed the encryption in ways cryptographers were not happy about (they dropped forward secrecy, which means one leaked key can expose your past messages), and the whole thing is tied to a crypto token ecosystem which always makes me a bit nervous.

The project also had a rough time lately. It started in Australia, and after Australian police literally showed up at an employee’s home, the foundation moved to Switzerland in 2024. Then earlier this year they announced they were 90 days from shutting down completely because the money ran out. Donations saved it at the last minute (a big chunk came from Vitalik Buterin, of all people), but it’s running on a skeleton crew now. Funny enough, the day this post goes up was supposed to be the shutdown date. I’m glad it survived, but it shows the risk of these smaller centralized-ish projects: your messenger can just… end. Between the weakened encryption, the token stuff and the funding drama, I honestly can’t recommend Session anymore. If you need that level of anonymity, look at SimpleX instead.

Briar

Briar is the extreme one, and I respect it a lot. No servers at all. Messages go peer to peer over Tor, and if the internet is down it can literally sync over Bluetooth or WiFi between phones that are near each other. This is the messenger you want during a protest or an internet blackout.

The cost of that design is convenience. Both people basically need to be online for messages to go through, there’s no real multi-device story, battery usage is rough, and iOS support is still not there (the team says iOS is too locked down for the background stuff P2P needs, which honestly says more about Apple than about Briar). It’s developed by a small non-profit on grant money, still getting steady updates in 2026, just slowly. Briar is not trying to replace WhatsApp, it’s a tool for situations where everything else fails. Good to have installed, not something you daily drive.

What I secretly wish existed is something in between Briar and Matrix: a federated protocol with real servers, but where the servers talk to each other over Tor or i2p. You’d keep the convenience of servers (offline delivery, multi-device, your phone not running a Tor node all day), but the network layer wouldn’t leak who federates with who. And if the entire stack ran over Tor, clients included, a lot of the metadata problems I complained about in the Matrix section would stop being such big issues: the server still sees which accounts talk to each other, but it couldn’t tie any of it to an IP address or a real identity anymore, because you’d be connecting over Tor and staying anonymous. Same between servers, so federation wouldn’t reveal anything either. As a bonus, a network like that would be very hard to block: no fixed IPs or domains to blacklist, just onion services. Remember what happened to WhatsApp in Russia, that kind of country-wide block basically stops working. Matrix over onion services sort of half-works if you force it, but nothing is built for that from the ground up. If someone knows a project like this, message me, seriously.

Okay, the elephant. WhatsApp actually uses the Signal protocol for encryption, so the message content itself is protected. Credit where it’s due, that’s billions of people with end-to-end encryption who never asked for it.

The problem is everything around the messages. WhatsApp belongs to Meta, and Meta’s whole business is knowing things about you. They can’t read your texts, but they know who you talk to, when, how often, from where, and they connect all of it to the biggest advertising profile on earth. Encryption of content is not the same as privacy. WhatsApp is proof of that.

And it’s getting worse, not better. This year WhatsApp got ads, and Meta AI is now baked into the app. Anything you say to the AI is processed on Meta’s servers, outside the end-to-end encryption, and their new policy says those AI conversations feed into ad targeting, with no opt-out. So the encrypted messenger now ships with a built-in unencrypted channel straight to the ad machine. They also finally added usernames so you can hide your phone number from strangers, which is nice I guess. Oh, and Russia blocked WhatsApp entirely this year, which is a good reminder that centralized apps can vanish from a whole country overnight.

If your family is on it and won’t move, fine, at least the messages between humans are still encrypted. Just don’t talk to the AI, and don’t call it a private messenger.

SimpleX

SimpleX is the newest project on this list, and its core idea is genuinely different: there are no user identifiers at all. Not a phone number, not a username, not even a random key that ties your chats together. Every conversation runs through its own pair of one-way message queues on relay servers, and the two directions of a chat don’t even have to use the same server. From the network’s point of view, “your account” simply doesn’t exist, so there’s nothing to correlate. On paper it’s the most private design of all of these.

The relays are worth explaining because it’s a nice middle ground: SimpleX runs default servers, but they’re basically dumb mailboxes that hold encrypted queues, and you can switch to other people’s relays or self-host your own without losing anything, since your identity was never on a server to begin with. That also means contact discovery works differently: you connect by sharing a link or QR code out of band, there’s no “find friends by number” and never will be, which is a feature or a dealbreaker depending on who you ask.

It’s also picking up momentum: Trail of Bits reviewed the cryptographic design, another security assessment is planned for this summer, and the funding situation looks healthier than most (Jack Dorsey invested, and Vitalik Buterin donated to them too, apparently he’s just going around funding private messengers now). A Russian court fined them for refusing to hand over user data, and their transparency report says they had nothing to hand over anyway, which is kind of the best advertisement a private messenger can get.

The downsides are the flip side of the design. It’s young, and the UX shows it. No identifiers means moving to a new phone or adding a device is more fiddly than elsewhere. And larger groups or communities are honestly where it falls apart: a “group” is really just a pile of pairwise connections, every message gets fanned out to every member separately, so anything beyond a small friend group gets slow and unreliable. If you want Matrix-style public rooms and communities, SimpleX is simply the wrong tool.

One more thing that bugs me about the design. By default, when you talk to someone, the traffic to their queue gets proxied through your own relay servers. That’s meant to hide your IP from unknown servers, which is fair, but it means your relay is in the loop for both directions: it knows when you send a message and when you check for or receive one. That’s exactly the kind of timing metadata this whole design is supposed to avoid, just concentrated at your own relay instead. I’d much rather they shipped an in-app Tor proxy (or something like it) so you talk to every queue directly and anonymously, instead of routing your activity pattern through one server that gets to watch it all. You can run the app over Tor yourself, but defaults are what actually matter.

And the funding is venture money, which I’d keep half an eye on; investors eventually want something back. Still, of everything on this list it’s the project I’m most curious about, and it’s the one I now point people to when they ask for real anonymity, at least for one-on-one chats.

The short version

If you skipped everything above, here’s the table. Scores are out of 5, and yes it’s my personal judgement, not science:

	Encryption	Anonymity	Metadata	No lock-in	Communities	Ease of use	Future
Signal	5/5	2/5	4/5	1/5	3/5	5/5	4/5
Matrix	4/5	3/5	2/5	5/5	5/5	4/5	5/5
Threema	4/5	4/5	4/5	1/5	3/5	4/5	3/5
Session	2/5	5/5	4/5	3/5	3/5	4/5	2/5
Briar	4/5	5/5	5/5	5/5	1/5	2/5	4/5
WhatsApp	4/5	1/5	1/5	1/5	4/5	5/5	5/5
SimpleX	5/5	5/5	4/5	4/5	1/5	2/5	3/5

Some of these need a footnote: Signal’s anonymity is a 2 because of the phone number, Session’s encryption a 2 for the missing forward secrecy, WhatsApp’s encryption only covers the message content, and WhatsApp’s 5/5 future is not a compliment. The reasons for everything else are up in the text.

So what should you use?

Boring answer: it depends on your threat model.

You want easy and solid: Signal
You want to own your identity and be part of an open network: Matrix (I know a nice server)
You want communities and public rooms, the Discord-shaped stuff: also Matrix, nothing else comes close
You don’t want to give any phone number and don’t mind paying: Threema, but watch how the acquisition plays out
You need real anonymity: SimpleX (not Session, sorry)
The internet is on fire: Briar
Your family refuses to move: WhatsApp, I guess. I’m not mad, just disappointed.

The real point is that all of these are better than the default of doing everything through one giant ad company. Pick one, drag some friends over, and the network effect problem gets a little bit smaller for everyone.

As always, if you want to try Matrix, you know where to find me.

Chat Control Is Still Not Dead (Unfortunately)

Tue, 07 Jul 2026 00:00:00 +0000

Okay, different topic today. If you’re in the EU and you care about privacy even a little bit, you’ve probably heard of Chat Control at some point. It’s the EU proposal to make messaging apps scan private messages for child abuse material. Sounds reasonable when you say it like that, which is exactly the problem, because what it actually means is scanning everyone’s messages, all the time, without any suspicion. And you can’t do that with end-to-end encrypted messages without breaking the encryption. There is no magic version of this where your chats stay private but also get scanned. Every cryptographer who looked at it said the same thing.

This law has been “almost passing” for years now, and I noticed most people I talk to have completely lost track of where it stands. Honestly I lose track sometimes too. So here’s the current state, as of when I’m writing this.

The good news

There was actually a real win this spring. On March 26 the European Parliament voted against extending “Chat Control 1.0”, the temporary rule that let providers like Meta scan everyone’s messages “voluntarily”. The vote was 307 to 306.

One vote. Let that sink in for a moment.

Anyway, that temporary regulation then expired on April 3. So right now, for the first time in years, there is no legal basis for mass scanning of private messages in the EU at all. That happened because a lot of normal people made noise about it. It worked.

The bad news

Here’s the thing, and this is the part that’s actually urgent right now: they’re trying to bring Chat Control 1.0 back. The Parliament voted to let it die, it expired, and now EU ambassadors have pushed to just extend it anyway, and MEPs are being asked to vote on reversing the decision they made in March. Read that again. The Parliament said no, by however thin a margin, and the answer to that is apparently “vote again until you say yes”. That’s the vote to watch right now, and it’s why the pressure matters again right now and not at some vague point in the future.

And in the background, the permanent version, Chat Control 2.0 (officially the CSA Regulation), is still being negotiated between the Parliament, the Council and the Commission. That fight is the same one as always. The Parliament’s position is actually fine: only scan specific suspects, and only with a court order. Normal police work, basically. The Council wants scanning of everyone without suspicion. Their newest trick is calling it “own-initiative” scanning by the providers, so on paper nobody is forced to scan, wink wink. Even the Council’s own legal service looked at that in June and said no, this is still generalised scanning of private communication. Which is the thing the EU courts keep saying is not compatible with fundamental rights.

There was supposed to be a final negotiation round on 2.0 on June 29, and it fell apart, exactly over this suspicionless scanning question. So no deal yet there either. Talks continue under the Irish presidency now, and Ireland is unfortunately one of the countries pushing for scanning.

This is the pattern with Chat Control. It gets rejected, it comes back with a new name. It gets blocked, it comes back under the next presidency. It expires, they try to extend it after the fact. The people pushing it only need to win once. We have to win every single time. That asymmetry is what worries me the most, more than any specific version of the text.

Why I care

Well, I run a Matrix server. If a scanning obligation like this passes, what am I supposed to do exactly? Break encryption for my users, or shut down? The big companies can hire compliance people and build scanning infrastructure. Signal at least has the weight to say “we’ll leave the market” and make headlines with it. A small homeserver like mine just quietly dies, or I’d be forced to move my server elsewhere with better privacy regulations.

And even if you don’t run anything: once the infrastructure to scan everything exists, “it’s only for CSAM” is just a promise. Promises like that have a history. First it’s this, then it’s terrorism, then it’s copyright, then it’s whatever the government of the day doesn’t like. Surveillance powers never shrink on their own.

What you can actually do

The March vote was 307 to 306. Margins like that don’t happen without ordinary people bothering their representatives, so this is not one of those “nothing you do matters” situations. Concretely:

Contact your MEPs. The easiest way is fightchatcontrol.eu, they have a tool that finds your representatives and helps you contact them, plus they track the current status of everything. Takes five minutes. A short personal message is better than a copy-paste one, but a copy-paste one is a lot better than nothing.
If your government is on the pro-scanning side (Denmark, Ireland, Spain, France, Italy and a bunch of others), write to them too. The worst versions of this keep coming from the Council, and the Council is just national governments, and those care about national voters.
Follow the people who actually track this stuff. Patrick Breyer has documented every twist of this saga for years, and EDRi does a lot of the real policy work.
Use encrypted messengers, and get others on them. Not because it fixes the law, but because the more normal encryption is, the harder it gets politically to ban it. I’m working on a whole post comparing the options, should be up tomorrow, conveniently.

I know “write to your politician” sounds like the most useless advice in the world. But this specific fight has been won multiple times now by exactly that. One vote in March. That was people making noise.

They will try again, they always do. So stay loud.

And as always, if you want to talk about this, you know where to find me.

Why I'm Starting salix.host

Fri, 10 Apr 2026 00:00:00 +0000

So, first post. I figured I should explain what this whole thing is and why I bothered setting it up.

salix.host is a Matrix homeserver. If you don’t know Matrix, the short version: it’s a chat network that nobody owns, kind of like email but for messaging. You pick a server, make an account there, and you can talk to anyone on any other server. No single company in the middle deciding the rules or reading your messages.

Why though?

Honestly, I got tired. Tired of every messaging app being owned by some company that treats your conversations as a product. You don’t really own your account on those platforms, you just borrow it until they decide otherwise. One policy change, one ban with no explanation, and years of contacts and history are gone.

The usual answer is “just run your own server”. And sure, that works, I do it myself. But let’s be real, most people are not going to rent a VPS and maintain a Synapse install just to chat with their friends. That’s a pretty big ask.

That’s the gap salix.host tries to fill. A simple, generic gateway into the Matrix network. You get an account here, and you’re in. No need to run anything yourself, no need to understand what federation means under the hood. It just works, and your privacy comes with it.

What this server is (and isn’t)

It’s small, and I like it that way. I’m not trying to build the next big platform.
It’s run by one person (me) who actually cares about keeping it up and keeping it clean.
It’s not a business. There’s no growth target, no ads, no selling data. There is no data to sell anyway, most of what goes through here is end-to-end encrypted.

I won’t pretend it’s perfect. A one-person server means when something breaks at 3am, it stays broken until I wake up. But I think there’s value in small servers run by real people, instead of everyone piling onto the same two or three giant ones. Federation only works if the network is actually spread out.

What’s next

I want to write more here. Not just server announcements, but posts about self-hosting, privacy, and honestly some social stuff too, because I don’t think you can talk about privacy without talking about why it matters for people.

If you want an account, or you just want to say hi, come find me on Matrix. That’s kind of the whole point.