# QNE Cloud Laptop And Remote Assist Doctrine V1

Date: 2026-06-08
Status: current operational doctrine
Layer: Layer B support doctrine under QNE Main Node Shadow System Doctrine V1
Workspace anchor: qne-node-v00509 and future cloud trial/remote-assist work

## 1. Purpose

This doctrine defines how QNE may use a cloud instance as a temporary device
that feels like a laptop or desktop, while keeping the final QNE architecture
focused on Home Nodes, browser/mobile shadows, `QNESceneData`, and
`QNENodeSkill` execution on nodes.

It also defines the future direction for QNE remote assistance, including
face-to-face video, screen sharing, optional remote control, helper approval,
payment, and audit.

## 2. Core Distinction

There are two different user experiences:

1. Cloud Laptop Temporary Mode
   - A Hetzner or similar cloud instance behaves like a remote laptop.
   - It may run a lightweight Linux desktop and VNC/noVNC for testing,
     demonstration, and operator work.
   - This is a bootstrap bridge, not the final QNE invitee model.

2. QNE Browser Trial Mode
   - The invitee opens a normal browser on their own device.
   - The browser connects to the Home Node browser adapter over HTTPS/WSS.
   - The browser receives `QNESceneData` and sends user actions.
   - QNE logic and `QNENodeSkill` execution remain on the Home Node.

The cloud laptop may be used to give a realistic "laptop" feel before real
remote invitees convert to their own nodes. It must not replace the browser
shadow doctrine.

## 3. Cloud Laptop Temporary Mode

A cloud laptop is a temporary QNE working device hosted on a cloud instance.
It can run:

- QNE Home Node under `~/QNE`
- hosted trial users under `~/QNE/users/<user_uuid>`
- browser invite adapter bound to loopback
- lightweight Linux desktop such as XFCE
- browser inside the cloud desktop
- VNC/noVNC for operator or carefully controlled trial access

Recommended Hetzner shape:

- Ubuntu or Debian cloud server
- static IPv4/IPv6
- Caddy or equivalent reverse proxy for TLS
- QNE browser adapter bound to `127.0.0.1`
- VNC bound only to `127.0.0.1` unless protected by HTTPS, strong auth, and
  firewall rules

The public-facing invite path should still prefer:

```text
https://trial.qne.info/invite/<invite_id>
```

Raw VNC must not be exposed publicly.

## 4. VNC/noVNC Use

VNC/noVNC is permitted as an interim operational bridge:

- to test a cloud instance as if it were a real laptop
- to inspect and capture the cloud desktop screen
- to operate a browser running on the cloud instance
- to prototype the feeling of a remote QNE laptop

VNC/noVNC is not the final QNE user-interface doctrine.

For QNE-native experience, prefer:

```text
Browser renderer shell
  HTTPS/WSS
Home Node browser adapter
  QNESceneData
  browser-shadow session
```

VNC/noVNC may be used for legacy or non-QNE desktop applications only when
`QNESceneData` is insufficient.

## 5. Browser Transport Rule

Normal browsers cannot use raw qne-p2p UDP/Noise sockets directly.

The browser leg uses:

- HTTPS for page delivery and request/response testing
- WSS for future scene/action streams
- TLS as the browser-to-Home-Node encryption layer
- browser-shadow session authorization on top of TLS

The Home Node remains the qne-p2p participant. It may speak qne-p2p to other
nodes on behalf of the browser shadow.

## 6. QNE Desktop Feel

The user should feel they are using a laptop or desktop, but the QNE-native
surface should be rendered from scene data, not from arbitrary hand-authored
HTML pages.

Required first-feel elements:

- full browser workspace
- calm pastel workspace background
- logical outer QNE window, initially 1920x1080
- outer window can move and resize within the browser workspace
- one or more internal scene windows
- PA window available early
- resume state later from hosted user/browser-shadow persist
- low cognitive load: no VNC/protocol vocabulary for normal invitees

The current browser adapter may use local HTTP for testing, but the external
trial design is HTTPS/WSS.

## 7. Real Desktop Copying

QNE should not normally clone a user's full OS desktop into the cloud.

Safe "familiar desktop" capture may include:

- wallpaper
- colors/theme
- scale/font preferences
- selected shortcuts
- selected folders
- exported bookmarks
- accessibility preferences

Future tool direction:

```text
qne-desktop-profile-capture
qne-node cloud-laptop-import-profile
```

This creates a familiar QNE cloud laptop profile without copying the entire OS
image or uncontrolled private data.

## 8. Remote Assist Doctrine

Remote assistance is a future `QNENodeSkill`, not a base-node feature.

Recommended skill name:

```text
qne-remote-assist
```

Remote assistance must be destination-approved. A helper cannot silently take
over a user's screen.

The safe staged flow is:

1. Face-to-face video/audio
2. Helper identity confirmation
3. Optional view-only screen share
4. Optional pointer/highlight overlay
5. Optional remote control
6. Session summary, payment record, and audit log

Each stage requires explicit user approval. Remote control requires a separate
grant from screen view.

## 9. Video-First Trust

Remote assistance starts with face-to-face video/audio.

Before screen sharing:

- the helped user sees the helper
- the helper identity is shown by verified QNE identity/qnename
- the PA explains that no screen access exists yet
- the user can end the session at any time
- paid terms or free grace period are clear

This is especially important for aged users and users needing handholding.

## 10. Paid Helper Service

QNE may offer approved helpers for a fee.

Required service properties:

- helper identity verification
- helper capability record
- availability status
- rate card or payment terms
- user approval before paid session starts
- optional free introduction period
- session receipts
- dispute/audit policy
- helper reputation later

Payment may start manually, then evolve toward QNE payment proofs or escrow.

## 11. Media And Screen Capture Direction

Remote desktop and remote assistance should extend QNE media work.

Generalized media source direction:

```text
qne-media-source
  camera
  microphone
  screen
  window
  QNE workspace framebuffer
```

For QNE-native windows, use `QNESceneData`.

For real screen/legacy desktop capture, use media frames:

- low FPS image frames first
- tiled dirty regions or WebP/JPEG initially
- video codecs later when needed
- audio later with explicit permission

Input control must be a separate, consented return channel.

## 12. Rust VNC Direction

Rust VNC libraries may be used for prototypes or compatibility.

Acceptable prototype uses:

- QNE framebuffer served through a VNC/RFB server
- noVNC as a browser client for a QNE-controlled framebuffer
- exploration of RFB rectangle encodings

But QNE's final remote assistance should not depend on generic VNC semantics.
It must preserve QNE identity, consent, payment, audit, and PA-mediated user
understanding.

## 13. Migration To Real User Node

The cloud laptop is temporary.

A trial user should be able to convert to a real node:

1. User installs QNE on their own device.
2. New node creates its own node UUID and static key.
3. Hosted user data is exported from the cloud/founder node.
4. New Home Node imports hosted user data.
5. Browser/mobile shadows reconnect to the user's own Home Node.
6. Trial node marks invite/user as migrated.

All trial activity must be stored under the hosted user layout so migration is
clean.

## 14. Non-Goals

This doctrine does not authorize:

- exposing raw VNC directly to the public internet
- silent remote control
- unattended helper access by default
- hidden screen sharing
- running `QNENodeSkill` code in a browser
- cloning a user's entire OS desktop as the normal QNE migration path
- putting remote-assist capture/input code into the base node

## 15. Immediate Bootstrap Plan

For the first cloud instance:

1. Create a Hetzner Cloud Ubuntu/Debian instance.
2. Install QNE into `~/QNE`.
3. Install Caddy for HTTPS.
4. Bind QNE browser adapter to `127.0.0.1`.
5. Optionally install XFCE plus VNC/noVNC for operator cloud-laptop testing.
6. Keep VNC private or protected.
7. Use QNE browser invite flow for actual invitee testing.
8. Capture observations and screenshots as operational evidence.
9. Do not treat VNC as final QNE UI architecture.
