Web/PWA client direction and integration with remote-host PR #188

[Xehos34]

Web/PWA client direction and integration with remote-host PR #188

Hi Traycer team,

Before starting a contribution, I reviewed the public client architecture and
the remote-host work in #188. The goal is a phone-friendly browser/PWA
companion that reuses gui-app rather than copying the desktop UI. The useful
end state would begin with read-only access to tasks, chats, agents, artifacts,
files, and diffs, followed later by carefully authorized actions and
privacy-preserving notifications.

The public code appears to provide a strong shell boundary:

• gui-app is browser-safe and receives an explicit IRunnerHost.
• Native behavior is concentrated in clients/desktop.
• Browser history is already supported.
• Remote discovery on main is still a stub.
• Browser/mobile device flow is currently a no-op, while desktop owns the
  CORS-safe auth flow.
• feat(remote-host): E2E remote-host transport, mux codec, and client UI #188 adds the encrypted relay transport and remote-host UI, paired with
  non-public control-plane, relay, and host-daemon work.

I want to avoid creating a parallel gateway or protocol fork, so I would
appreciate guidance on these points:

1. Is gui-app intended to support an official browser/PWA client?
2. Does the mobile terminology in IRunnerHost mean Capacitor/native, PWA, or
   both?
3. Should new client work target feat(remote-host): E2E remote-host transport, mux codec, and client UI #188, and which relay/auth interfaces are
   expected to become public and supported?
4. What browser login and secure token-storage model should a web shell use?
5. How should a remote client handle host discovery, pairing, revocation, and
   capability authorization?
6. Should Web Push derive from durable notification-room events, and what data
   may be included in a push payload?
7. Would a focused first PR containing only a mock-backed clients/web shell
   be useful while remote transport is under review?

The proposed first contribution would be intentionally narrow:

• A thin Vite/PWA shell that renders the existing TraycerApp.
• A browser IRunnerHost backed only by mocks.
• Responsive browser/mobile rendering and tests.
• No production credentials, remote relay, local Host exposure, or privileged
  actions.

Production integration would wait for the supported browser-auth and
remote-host contracts. Is that direction useful to Traycer, or would you prefer
a different client boundary?

[hdkshingala]

Thanks for putting together such a detailed proposal, @Xehos34.

We’re already actively working on mobile support for Traycer, alongside the remote host functionality. The mobile client will be able to connect to a Traycer host running on another machine, such as a local VM, cloud VM, or VPS, so users can access and manage their Traycer workflows from other devices.

Because this work is already underway and some of the underlying authentication, pairing, and remote-host interfaces are still evolving, we’d prefer to finalize those foundations before introducing a separate web/PWA client.

We really appreciate your interest in contributing. Once the remote-host and mobile architecture is more stable, we’ll be able to share clearer guidance around the supported interfaces and potential areas for contribution.