Tor
tor-core is an in-process Arti session on native builds: directory bootstrap, a localhost SOCKS5 proxy, one duplex v3 hidden service per device, and length-prefixed framed links to a peer .onion.
api-core never links Arti. Native whatsup starts the session through glitr-client after login. The browser never links tor-core. WASM cannot open circuits.
This page is that native path as a threat surface. Wiring: Network. Platform rows: Platforms.
What Tor is for here
| Use | What it changes | What it does not |
|---|---|---|
SOCKS for git HTTPS (socks5h://127.0.0.1:…) | The git host sees a Tor exit, not your home IP | The host still sees the repo, collaborators, and activity |
Onion pairing (on1:) | Live frames without ICE or a public STUN | It is not a git mailbox. If the circuit is down, delivery waits |
| Web via native proxy | A browser tab can send onion or git-over-Tor frames through a linked desktop | The web build still does not run Arti |
Live WebRTC itself does not ride Tor. If a contact can use more than one live hop, WebRTC is tried first, then onion.
Onion pairing
Contacts + → Onion exchanges a QR or paste bundle (on1:) with your hidden-service address. The contact is stored as onion://…, or onion://pairing while the invite is unfinished.
Like Pair now:
- The bundle is plaintext out of band. Anyone who sees it learns the
.onionand can try to connect as the invitee. - There is no git mailbox fallback.
- After the link is up, chat frames use the same recipient cascade as other live bodies.
- Hello + safety number is the identity check. The math lives in
api-coreas well as tor-core, so a browser can verify a pairing without linking Arti.
devices/ stores this device’s published onion as ordinary JSON. A clone of the repo can read it. A peer poll does not fetch that folder; peers see a cached copy on the contact (peerDevices).
Where Arti state lives
Arti’s cache and keys live under a private data directory (positive-intentions/api), not inside the mailbox repo. Losing the mailbox password does not by itself wipe Tor state. Compromising the data directory is a Tor-state problem, not a cascade problem.
Web does not run Tor
Web Glitr hides the Onion chip. A web tab can only touch onion or git-over-Tor by proxying through a linked native device on an already-open data channel (glitrProxy).
That proxy is not an open forwarder. Git HTTP is restricted to allowed hosts; onion send is restricted to onions this session already knows. A remote peer who can inject frames still should not be able to make your desktop fetch an arbitrary URL. That allowlist is a Partial control — documented in the client, not an audit of every frame kind.
Mobile
Mobile Cargo can enable the Tor feature. It is not a claimed product path. Do not treat an Android nightly with Arti compiled in as a Tor messenger.
What Tor does not claim
| Claim | Status |
|---|---|
| Anonymity of the Glitr user | Open — listed as a roadmap requirement and currently disclaimed |
| WebRTC over Tor | Open — not how the live path works |
| Hidden-service identity equals Glitr identity | Partial — TOFU + safety number, same as other live paths |
| Directory / guard / exit operators see nothing | Documented — they see Tor traffic, not cascaded bodies |
A Tor path observer still sees that a hidden service is busy. Cascade on the frames is the content control, same as WebRTC.
Next: Devices and storage — keys, passwords, and the other device.