Skip to content
TraceMote
About

A fork with a narrow purpose

RustDesk solved the hard part — capture, codecs, NAT traversal, a peer-to-peer transport that works. It just never had a concept of who you are. That is the part we built.

Why this exists

Self-hosted RustDesk is the most practical remote-access stack you can stand up in an afternoon, and for a great many teams the story ends there. It ends differently the first time somebody has to answer a question like “who reached that machine on Tuesday”, or has to remove access from a person who left this morning, or has to show an auditor how access is granted rather than how it is shared.

The usual answers are a commercial licence, a hosted product that puts somebody else in the middle of your sessions, or a spreadsheet. We wanted a fourth: the same software, on the same infrastructure, with a real identity layer in front of it — built in the open, and published under the same licence we received it under.

How it is built

Two forks and two new applications. The client and the rendezvous/relay server are forks of upstream, each tracking a pristine mirror branch so that the complete diff of what we changed is one command away. The auth backend and the admin console are ours from scratch, and they are separate because the backend answers to a contract upstream fixed — the client derives its address and calls specific paths — while the console answers to nobody but a browser.

Most of what looks like new protocol is not. The client already knew how to log in, carry a token on every connection, push connection and file-transfer logs, and close a session when a heartbeat response tells it to. All of that was written to talk to a commercial server and is simply ignored by the open-source one. We implemented the other side of it rather than inventing anything, which is why so little of the client had to change at all.

Who is behind it

TraceMote is built by TraceMote, a small team. The forks are public, every change we made to them is one command away, and the architectural decisions behind the identity layer are written down where anyone evaluating it can read them.

How we work

Four rules that show up in the code

Measure, do not assume

Several of the things in this system exist because a test disagreed with a careful reading of the source. The relay path was one; an eighteen-second stall that nobody had hit yet was another. Documents get corrected in the same commit as the code that disproved them.

Be minimally invasive

Every client change sits behind a flag, and with the flag off upstream's original path runs unchanged. Not out of politeness — it is what keeps the next upstream merge survivable, and it is upstream's own rule.

Say the uncomfortable half

The security page lists what this system does not fix. The download page says which platform we verify end to end. A limitation you discover after deploying is not a limitation, it is a surprise.

One enforcement point

The relay stays unmodified so there is exactly one place that decides whether a connection happens. Two half-enforced paths are worse than one enforced one.

Get started

Come and disagree with us

The interesting bug reports are the ones that contradict a document. Those get fixed in both places.