Matrix

A communications layer I run myself — so that human identities and system identities can stay different things.

Active PrivateSelf-hosted

What it is

A Matrix homeserver I run on my own hardware.

Matrix is an open protocol for real-time communication. I did not write it, and I did not write the software running it — the homeserver is Continuwuity and the client is Element, both third-party open-source projects. What is mine is the decision to host it, and everything that follows from that decision.

Why self-host it

The first reason was ordinary: private conversation that does not live on someone else’s platform.

Choosing the software was less ordinary, because the host had under a gigabyte of memory to spare. The well-known reference homeserver needs more than that on its own, so it was ruled out before anything else was considered. The lightweight implementation I picked first turned out to have been archived by its maintainer — which meant comparing what had actually succeeded it, rather than deploying something no longer maintained. Continuwuity came out of that comparison, and in this deployment it settles at roughly 100–150 MB. That is an observation from one server, not a stated requirement.

Federation is deliberately switched off: this is a closed server, not a node in the public Matrix network. Worth adding that this was confirmed by asking the running server through the protocol itself, not by trusting a ticked configuration box. Those are not the same claim.

Systems are participants too

The more interesting use arrived later. TRON, my security orchestration system, needs to reach a human when something warrants one. It does that through this server.

It has its own identity for the purpose — a service account separate from mine, separately authenticated, confined to rooms created for it. It does not log in as me.

That is the principle worth stating plainly: a system should not have to impersonate a person in order to reach one. On a hosted platform you accept whichever identity model you are given. Running the server myself is what made that boundary mine to draw.

The path now runs in both directions. Messages go out to a dedicated room, and a reaction on one comes back as a decision candidate for TRON to evaluate. It is not a closed loop — reactions do not currently cause anything to happen, because execution is switched off. The approval and execution architecture — where the real engineering on that side lives — belongs to TRON, not here.

Trust boundaries

Two zones exist today, and only two.

System its own service identity Dedicated room created for it, nothing else Human reached, not impersonated separate zone People, their own accounts Their own rooms

The service identity has no presence on the right-hand side. That separation is the point of running the server.

A third zone — public contact arriving from this website — does not exist. It is a design direction, not infrastructure.

Where it stands

Running. Human use is routine. The system path is validated outbound and exercised inbound, with autonomous execution deliberately disabled.

A future experiment may evaluate using this as the private transport behind contact from marcinsakowski.com. None of that is built.

All projects