# tripley-native-hostd
Standalone Tripley Native xRPC host daemon.
Use hostd when a browser, Vite dev server, Electron renderer, or another process
needs to call Tripley Native APIs over WebSocket or framed TCP.
## Browser Development
```powershell
cargo run -p tripley-native-hostd -- --addr 127.0.0.1:39010 --dev-permissive
```
Frontend clients can connect to `ws://127.0.0.1:39010`.
## XFS and Simulator Control
Real Windows CEN/XFS access usually requires a 32-bit hostd process:
```powershell
cargo run -p tripley-native-hostd --target i686-pc-windows-msvc --no-default-features --features transport-websocket,service-xfs,service-xfs-control -- --addr 127.0.0.1:39010 --services runtime,xfs,xfs-control --xfs-command-leases required --xfs-dll-directory "C:\Program Files\Tripley.XFS\sp32" --xfs-control-simulator-ws-url ws://127.0.0.1:39001
```
Use `--xfs-dev-mock` when you want hostd to expose the XFS RPC surface without a
real XFS manager. Real XFS integrations should pass `--xfs-dll-directory`
explicitly; do not rely on the bare `msxfs.dll` search path.
## Useful Options
- `--transport websocket|tcp`
- `--addr host:port`
- `--services all|runtime,fs,archive,tcp,websocket,sqlite,system,xfs,xfs-control`
- `--policy-file path` or `--policy-json json`
- `--dev-permissive`
- `--auth-token token`
- `--remote-allowed`
- `--xfs-dll-directory path`
- `--xfs-command-leases disabled|optional|required`
- `--xfs-control-simulator-ws-url ws://host:port`
`optional` preserves compatibility for development: a protected command is fenced once a lease
exists for its logical service. Use `required` for kiosk deployments so every side-effecting XFS
command requires a connection-bound lease. Host restart changes the host epoch; clients must
reconcile any unresolved operation and acquire a new fencing token instead of replaying a command.
This is a `0.x` preview binary crate. Prefer local-only binding and explicit
policy configuration outside development.