Documentation

This page describes the NexaDesk repository documentation structure. This is not a published API reference or downloadable manual — it indexes the repository's design, architecture, and decision records.

Repository Overview

README.md

Product overview, objectives, internal-use scope, planned features, supported operating systems, architecture summary, security design, self-hosting strategy, technology decisions, repository structure, development requirements, build instructions, testing strategy, roadmap, and current status.

Current Status

Authenticated, consent-gated Linux CLI sessions with TOFU and ping/pong; 44 tests green on Linux headless; no capture, input, file transfer, relay, or releases yet.

Known Limitations

CLI sessions carry only ping/pong data. Linux headless tests do not validate Windows or Ubuntu graphical behavior. No benchmarks or performance claims. Ubuntu Wayland support deferred. Backup/restore procedures are designs only, not executed.

Architecture and Security

docs/architecture.md

Selected approach (custom NexaDesk engine with permissively licensed capture/codec leaves), control plane separation from media/data plane, UI/agent boundaries, MVP slice definition, and identified risks.

docs/security-model.md

Threat model, normative MVP controls (identity/Ed25519, handshake/mutual auth, encryption/authenticated encryption, authorization/scoped approval, credentials/OS keystore, abuse resistance, audit log), and verification mapping.

docs/licensing.md

License obligations, option triggers, compliance checklist, and legal-review flags. AGPL assessment for RustDesk code, permissive-leaf boundary design, and distribution duties. Eight explicit counsel flags identified.

Operations and Evidence

Operations Runbooks

Hetzner inventory (read-only), backup + verification design, controlled migration sequence (no destructive step authorized), signal/relay/TLS/firewall/monitoring design with capacity assumptions.

Gate Reports

Repository audit and review reports documenting progress evidence — including the current authenticated-session work — are kept in docs/gates/.

How to Interpret Status

Implemented

Features with passing tests and evidence. Current: authenticated, consent-gated CLI ping/pong sessions on Linux headless.

  • Rust core (workspace exists)
  • Authenticated sessions (CLI)
  • Consent-gated connections
  • TOFU trust model
  • Linux CLI host/client

Planned / Not Tested

Features in design or not validated. These are intentions, not capabilities.

  • Self-hosted architecture (design)
  • Graphical screen capture
  • Remote input control
  • File transfer
  • Clipboard sync
  • Windows client
  • Device discovery/relay
  • Releases/downloads
  • Cross-host validation
  • Performance benchmarks

Related Pages

Review the security model to understand implemented controls and planned features, or check the features page for a capability summary.

Security Model View Features