RmDesk

Somebody has to get onto a machine that is behind carrier-grade NAT, at the far end of a satellite hop, or inside a corporate network that inspects everything leaving it — and the alternative is a site visit that can cost a day. The question is not which remote desktop product has the longest feature list. It is whether a session will come up at all on a path like that, and whether it holds while a change is being made.

Why I built it

Because the commercial options answer a different question. They are built for supporting a user on a healthy broadband line, which is a reasonable thing to build for and not the situation I keep meeting. In that design a server the vendor operates carries the session whenever a direct path cannot be made, the assumption is a cooperative network, and when the path stops cooperating the connection ends rather than thins out.

Six years of remote-site work sets the requirement differently. A terminal is commissioned once and then expected to run unattended, the nearest engineer to it can be a day away, and the link you are working over is the link you are working on. So the two things that actually matter are that the data plane belongs to nobody but the two machines, and that the connection degrades instead of dropping. Both are transport decisions, which means they cannot be added afterwards — and that is what made this a piece of software rather than a purchase.

The problem

A relayed data plane puts an operator you cannot audit in the path of your screen, your keystrokes, your clipboard and your file transfers. On somebody else’s estate that is a question you will be asked and should be able to answer properly. It also puts their capacity and their availability in the path of your outage.

The rest is the networks themselves: symmetric NAT, carrier-grade NAT, proxies with deep packet inspection, captive portals, IPv6-only segments, lossy links and high-latency satellite paths. Tools that assume none of those either refuse to connect or die halfway through a configuration change, which on a remote site is worse than never having started. And the conventional answer — install one product on the machine you are helping and a different one on yours, each with its own account — is an obstacle at exactly the moment nobody has patience for one.

What I did

• A strictly peer-to-peer data plane. Screen, audio, input, clipboard and file transfer never traverse an operated server under normal conditions.
• End-to-end encryption with no unencrypted code path, decided at the start rather than added later, because encryption retrofitted onto a transport always leaves a way around it. Each installation holds a long-term key it generated itself.
• Nobody connects without a password or somebody at the far end agreeing. Consent is part of the protocol, not a setting that can be quietly left off.
• Degrade the experience rather than drop the connection. The judgement call that shapes everything else: the transport is written to give up picture quality, not the session.
• Three ways of reaching the far end, tried in sequence rather than all at once. A direct connection first, then a port mapping asked of the router, and only then a relay that routes by identifier and cannot read the session. The order is the point — the most direct and most private path is attempted first, and the relay is a last resort instead of the default.
• One application at both ends. The same program listens and connects, so there is no server to install and no second product to buy for the other side. On a local network it finds other machines by identifier with nothing to configure.
• The same design on Windows, Linux, macOS and Android, because the machine you happen to be holding when a site goes down is not negotiable.

The result

Sessions that come up on paths where the usual tools decline to start, and stay up while the picture gets worse and better again. Nothing at the far end beyond the same application, no port that somebody has to open by hand on the network in front of it, and no operator in the middle who could read the traffic even if asked to — including the relay, which routes by identifier and sees ciphertext.

The practical effect is fewer journeys and fewer half-finished changes. The wider point is the same one the other tools here make: this exists because a diagnosis and a support burden needed an instrument with particular properties, and no product on sale had them. Where a product does have them, I use the product.