---
title: "How Privatta Works"
description: "A one-time key or LAN discovery, a WebRTC/DTLS handshake, authentication, then a direct encrypted transfer — on your network, the internet or air-gapped."
url: "https://royalsoftworks.com/products/privatta/how-it-works/"
source: "https://royalsoftworks.com"
format: "markdown"
note: "Markdown rendering of the HTML page at `url`. Same content, same canonical URL."
---

How it works

# Same short trip, wherever you are.

At the office, across the internet, or with no internet at all — Privatta works out the route by itself. The result is always the same: a direct, locked line between two machines.

01 Anywhere

## One app. Three ways to reach someone.

On your office network 01

Across the internet 02

Completely offline 03

### On your office network

On a shared network, Privatta spots the other computers running it automatically. Transfers are instant and never touch the internet. On mobile, scan a QR code shown on the desktop app to pair instantly — no typing an address, no account.

mDNS discovery plus an active network scan. No router config, no port forwarding. QR pairing works from the Android companion app; iOS is in development.

Under the hood

## From dragging it in to it landing there.

What actually happens in the seconds between you adding a file and them opening it.

1. 01

   ### Add the file

   Drop a file into Privatta and choose who can see it: public on the LAN, a named user, or a group. Bundle related files into a virtual folder to share one policy.
2. 02

   ### Discover the other machine

   On a shared network, mDNS and an active scan find other Privatta installs automatically. Over the internet, the host presses Generate Key and gets two things: a one-time connection key and a 6-character security code, meant to be sent by two different routes. There's no directory to search.
3. 03

   ### Open an encrypted channel

   A lightweight signaling server introduces the two machines and relays just enough to set up a WebRTC connection, then gets out of the way. The channel itself is secured by WebRTC's own DTLS encryption, negotiated directly between the two machines.
4. 04

   ### Pass the checks

   Over the internet, the connecting peer presents the one-time key and then the security code, which the host checks before anything else — before credentials, and before a single file is listed. From there they either sign in with a username and password, or continue as a guest and see only the files marked for everyone. On the LAN, it's a whitelisted MAC address plus username and password. Five wrong codes or passwords lock the connection until the host issues a fresh key and code.
5. 05

   ### Only the recipient can pull

   Passing the checks gets you a file list, not a file. The host's process has no command that pushes bytes to a peer — the recipient always has to request a specific file before a single byte moves. Nothing arrives that wasn't asked for.
6. 06

   ### Transfer directly

   Once requested, the file streams straight from sender to recipient over the encrypted channel, with live progress. No intermediate server holds a copy at any point.
7. 07

   ### Log it (Enterprise)

   The attempt — allowed or denied, by whom, from where, over which transport, for which file — is written to a local access log, with internet sessions recorded as fully as local ones since 1.1. On the Enterprise tier that log is immutable: there is no delete or edit capability in the code, by anyone, and entries are hash-chained so an edit from outside the app is detectable. Passwords are never recorded.

## See exactly what's checked at the door.

Encryption, the signaling server, and the audit trail — the full security model in one place.

[Security](https://royalsoftworks.com/products/privatta/security/) [Read the whitepaper](https://royalsoftworks.com/products/privatta/whitepaper/)