VoxVera/docs/roadmap-platform-parity.md

Platform Parity Roadmap

This roadmap focuses on one question:

How do we expand VoxVera beyond Linux without overstating reliability, while still converging on real cross-platform parity for Tor hidden-service hosting?

Strategic Principle

Parity is not a packaging milestone. It is a runtime-contract milestone.

Every platform must eventually implement the same hosting contract:

1. install VoxVera
2. ensure Tor and OnionShare are available
3. build site assets
4. serve the hidden service
5. preserve .onionshare-session
6. recover hosting after reboot, login, suspend, or offline periods
7. surface logs and status

Package formats should inherit that contract. They should not define independent behavior.

Phase 0: Truth Alignment

Goal: bring repo claims, docs, and release posture into line with current reality.

Deliverables:

• canonical support matrix
• machine-readable support declaration
• installer/package warnings for experimental paths
• README and docs aligned to the actual supported target

Definition of done:

• no docs imply parity that tests do not support
• every platform surface has an explicit support tier
• release artifacts are not treated as proof of hosting reliability

Phase 1: Harden Linux As Reference

Goal: make Linux CLI with systemd --user the clearly defensible model that other platforms copy.

Work items:

1. Add voxvera doctor for runtime validation.

   • Check Tor reachability.
   • Check OnionShare availability.
   • Check start-all surfaces.
   • Check autostart timer installation.
   • Check host directories and session files.

2. Add voxvera autostart status.

   • Show service and timer files.
   • Show whether the timer is enabled.
   • Show next/last run timestamps if available.

3. Normalize Linux log/status guidance.

   • Document host log paths.
   • Document timer/service status commands.
   • Document expected recovery flow after reboot/network loss.

4. Validate restart behavior.

   • fresh install
   • first serve
   • reboot
   • suspend/resume if possible
   • temporary offline period followed by reconnect

Definition of done:

• Linux remains the only supported path until the above evidence exists and is documented.

Phase 2: Platform Adapter Layer

Goal: stop encoding platform logic in ad hoc installer scripts.

Recommended structure:

• voxvera/platforms/base.py
• voxvera/platforms/linux.py
• voxvera/platforms/macos.py
• voxvera/platforms/windows.py
• voxvera/platforms/docker.py

Each adapter should define:

• support tier
• Tor discovery strategy
• OnionShare discovery strategy
• state root
• autostart installation strategy
• autostart status strategy
• log/status surface
• known limitations

CLI surfaces to add:

• voxvera doctor
• voxvera platform-status
• voxvera autostart
• voxvera autostart status
• voxvera autostart uninstall

Definition of done:

• shell installers become thin wrappers over shared Python logic instead of owning runtime policy themselves

Phase 3: Docker Beta Candidate

Goal: make Docker a coherent, testable deployment surface.

Decisions to settle:

• single-container runtime vs compose-based runtime
• host Tor vs container Tor
• log and state persistence model

Recommended direction:

• keep runtime state under one explicit volume root
• document restart policy clearly
• make health and recovery behavior observable

Validation checklist:

• container restart preserves onion identity
• host reboot with restart policy restores hosting
• state remains in mounted volume
• logs remain inspectable

Promotion target:

• experimental -> beta

Phase 4: macOS CLI

Goal: establish one honest CLI-based macOS hosting model before packaging.

Work items:

1. define Tor discovery strategy
2. define OnionShare discovery/install strategy
3. validate manual build + serve
4. implement and validate launchd recovery
5. document known limitations

Promotion target:

• remain experimental until launchd recovery is validated
• move to beta only after login/reboot/offline recovery evidence exists

Phase 5: Windows CLI

Goal: establish one canonical Windows runtime model before claiming package parity.

Work items:

1. unify binary naming across installer, Chocolatey, docs, and release assets
2. define Tor discovery strategy
3. define OnionShare discovery strategy
4. validate manual build + serve
5. implement Task Scheduler recovery path
6. add Windows-specific status/log guidance

Promotion target:

• remain experimental until scheduled recovery and state persistence are proven
• move to beta only after reboot/login/offline recovery evidence exists

Phase 6: Electron GUI Convergence

Goal: make the GUI a frontend to the supported runtime, not a separate runtime.

Work items:

1. route the GUI through shared CLI/runtime surfaces
2. reduce duplicated Tor startup behavior
3. add visibility for:
   • Tor status
   • OnionShare status
   • hosting status
   • onion URL
   • logs
4. make window-close behavior explicit and safe

Promotion target:

• GUI remains experimental until it stops diverging from the CLI runtime contract

Phase 7: Package Surface Promotion

Goal: package formats should become trustworthy wrappers around validated runtimes.

Work items:

1. Debian package

   • declare actual runtime dependencies
   • validate install + host + recovery path

2. AppImage

   • decide whether it is distribution-only or a real hosting target

3. Homebrew

   • fix artifact URL/sha/version policy
   • clarify whether it installs a hosting target or just a CLI

4. Chocolatey

   • align artifact naming and installer semantics

5. Flatpak

   • decide whether Tor/OnionShare can be supported sanely in-sandbox

Rule:

• no package surface should be promoted above the support tier of its underlying runtime

Testing Program

1. Unit tests

• config/state logic
• autostart file generation
• platform adapter selection

2. Mocked integration tests

• serve
• autostart
• doctor
• platform-status

3. Platform smoke tests

• fresh install
• build
• serve
• persist identity
• restart
• recover

Current smoke target names:

• linux-cli
• macos-cli
• windows-cli
• docker-cli

These target names are contract-level validation entry points. Only linux-cli currently represents a supported hosting path; the others should be used to validate experimental posture and dependency discovery on their native platforms until their recovery behavior is proven.

4. Release checks

• support matrix is current
• docs match support tiers
• artifact names match scripts and package manifests

Immediate Next Tasks

1. Add voxvera doctor.
2. Add voxvera autostart status.
3. Add the platform adapter scaffold.
4. Capture Linux reboot/offline recovery validation steps in docs and CI notes.
5. Pick Docker's canonical runtime model.
6. Normalize Windows binary naming before further Windows work.

Non-Goals

• claiming parity before recovery behavior is validated
• treating package availability as support proof
• maintaining separate runtime semantics in GUI vs CLI