Architecture direction

Keep authority explicit and content at the endpoints.

The architecture is being built in independently reviewed layers. Some control-plane and Windows authority foundations are real; the production transport and customer applications are not implemented yet.

Concept plus verified foundations

Layered by responsibility

One remote session, distinct trust boundaries.

Endpoint / Host

Local identity and consent

A privileged Windows service coordinates device identity while a user-session component owns the local attended-consent experience. Process and session binding are verified in the development foundation.

Verified foundation

Control plane

Accounts, policy, authority, and audit

The control plane is intended to manage tenant-scoped business state, short-lived authority, signaling coordination, policy, and bounded audit—not plaintext session content.

Foundation in progress

Transport

Direct first, blind relay fallback

Authenticated direct connectivity and a relay that cannot decrypt customer content are commercial-GA requirements. A production network or relay data plane does not exist today.

Planned

Endpoint / Viewer

Operator experience and endpoint keys

The Viewer is intended to hold its own session key material and expose role-scoped, understandable support workflows. Windows and mobile Viewer applications are not implemented yet.

Planned

Control path

Authority before connectivity

A tenant-scoped support request targets an enrolled device.
The intended local user sees and decides an attended-consent prompt.
Consent produces only a bounded, revocable authority lease.
The exact local process/session and future Viewer must still satisfy current authorization.
Only then may an authenticated transport attempt be eligible.

Language boundary

Preparation is not connection.

Today’s work can prove enrollment, consent, process binding, transition integrity, and no-network transport preparation. It cannot honestly say “connecting,” “connected,” “relayed,” “streaming,” or “remote control started.”

Deployment model

The same rules, different operators.

Hosted and private choices change who runs the service; they are not intended to change endpoint authority or content boundaries.

NoBS-hosted

NoBS is intended to operate the production control plane, database, relay fleet, updates, observability, backups, and response program.

Planned

Dedicated private

NoBS is intended to operate a separately defined environment under engagement-specific isolation and responsibility terms.

Conditional

Independent self-hosted

The customer is intended to operate a Linux Docker/PostgreSQL control plane without mandatory NoBS session authorization.

Planned

Need the operational view?

Compare deployment responsibilities.

See who is intended to control authority, operations, backup, updates, and recovery in each mode.

Deployment choices Security model