hugo/RuDS
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

Implement the headless RuDS server and SSH transport #26

New Issue
Closed
opened 2026-07-18 20:48:54 +00:00 by hugo · 1 comment
hugo commented 2026-07-18 20:48:54 +00:00
Owner
Copy Link

Goal

Run the shared RuDS application engines without desktop UI and expose authenticated remote sessions for desktop and TUI clients.

Current state

  • specs/server.allium defines boot modes, key material, SSH transport, GUI remote connection, and TUI sessions.
  • There is no server runtime, SSH host, remote project connection, or boot-mode selection.
  • This issue depends on shared application services and domain events; CLI provides the headless entry pattern.

Required behavior

  • Resolve desktop, server, and TUI boot modes without initializing unused UI/runtime components.
  • Start a headless engine host over the same database, projects, settings, tasks, and engines as desktop.
  • Generate/store private host-key material with restrictive permissions and manage authorized public keys.
  • Accept only authenticated SSH clients; reject unknown/revoked keys and unsafe key files with clear errors.
  • Host remote TUI sessions and the desktop remote-project protocol specified by server.allium.
  • Carry domain events, task progress, and server-selected locale across client sessions.
  • Support clean shutdown, client disconnect, reconnect, concurrent clients, and engine errors without corrupting ongoing work.
  • Add the desktop connection flow for selecting and opening remote projects.

Implementation notes

  • Read docs/UI_STYLE_GUIDE.md before desktop connection UI work.
  • Reuse the event bus and application service layer; do not expose the SQLite file or build a second remote domain API.
  • Bind conservatively by default and make external listening explicit.
  • Follow red/green TDD, including filesystem permission and authentication tests.

Acceptance criteria

  • Boot mode tests prove desktop/server/TUI initialize only required components.
  • Host-key creation, permissions, authorized-key updates, accept/reject/revoke, reconnect, and shutdown are tested.
  • Two clients observe mutations through ordered domain events without duplicate writes.
  • Remote desktop project selection and failure states are localized and working.
  • Server operation never starts the desktop UI.
  • cargo fmt --all -- --check, cargo build --workspace, and cargo test --workspace pass.
## Goal Run the shared RuDS application engines without desktop UI and expose authenticated remote sessions for desktop and TUI clients. ## Current state - specs/server.allium defines boot modes, key material, SSH transport, GUI remote connection, and TUI sessions. - There is no server runtime, SSH host, remote project connection, or boot-mode selection. - This issue depends on shared application services and domain events; CLI provides the headless entry pattern. ## Required behavior - Resolve desktop, server, and TUI boot modes without initializing unused UI/runtime components. - Start a headless engine host over the same database, projects, settings, tasks, and engines as desktop. - Generate/store private host-key material with restrictive permissions and manage authorized public keys. - Accept only authenticated SSH clients; reject unknown/revoked keys and unsafe key files with clear errors. - Host remote TUI sessions and the desktop remote-project protocol specified by server.allium. - Carry domain events, task progress, and server-selected locale across client sessions. - Support clean shutdown, client disconnect, reconnect, concurrent clients, and engine errors without corrupting ongoing work. - Add the desktop connection flow for selecting and opening remote projects. ## Implementation notes - Read docs/UI_STYLE_GUIDE.md before desktop connection UI work. - Reuse the event bus and application service layer; do not expose the SQLite file or build a second remote domain API. - Bind conservatively by default and make external listening explicit. - Follow red/green TDD, including filesystem permission and authentication tests. ## Acceptance criteria - Boot mode tests prove desktop/server/TUI initialize only required components. - Host-key creation, permissions, authorized-key updates, accept/reject/revoke, reconnect, and shutdown are tested. - Two clients observe mutations through ordered domain events without duplicate writes. - Remote desktop project selection and failure states are localized and working. - Server operation never starts the desktop UI. - cargo fmt --all -- --check, cargo build --workspace, and cargo test --workspace pass.
hugo added the enhancement label 2026-07-18 20:48:54 +00:00
hugo commented 2026-07-19 18:35:49 +00:00
Author
Owner
Copy Link

Implemented in 45cb0cd. Added the standalone bds-server crate and pre-Iced desktop/server/TUI boot selection; a loopback-by-default Russh host with restrictive generated host/client identities, live authorized_keys reload, public-key-only authentication, TOFU known_hosts verification, restricted forwarding, clean disconnect/reconnect/shutdown, and packaged server binary; a versioned CoreHost remote protocol with project selection, shared task manager, ordered project events, server locale, exactly-once request replay, concurrent clients, and the persisted CLI-notification watcher; and the localized native File-menu connection/project picker with server-locale switching and nonfatal/fatal error handling. The Allium server contract was updated for the native Iced remote protocol and validates cleanly. Neutral review compared the result with issue #26, bDS2 server/remote behavior, and specs/server.allium and found no remaining acceptance gap; the full TUI renderer remains issue #27 while #26 supplies its local/SSH session transport over the same host. Verification: cargo fmt --all -- --check; cargo clippy --workspace --all-targets with warnings denied; cargo build --workspace; cargo test --workspace; Allium check/analyse; real SSH tests for unknown/authorized/revoked keys, permissions, reconnect, two-client ordered events with one write, locale, watcher propagation, and shutdown; and a rebuilt macOS app/DMG with Computer Use verification of the localized native connect and failure states.

Implemented in 45cb0cd. Added the standalone bds-server crate and pre-Iced desktop/server/TUI boot selection; a loopback-by-default Russh host with restrictive generated host/client identities, live authorized_keys reload, public-key-only authentication, TOFU known_hosts verification, restricted forwarding, clean disconnect/reconnect/shutdown, and packaged server binary; a versioned CoreHost remote protocol with project selection, shared task manager, ordered project events, server locale, exactly-once request replay, concurrent clients, and the persisted CLI-notification watcher; and the localized native File-menu connection/project picker with server-locale switching and nonfatal/fatal error handling. The Allium server contract was updated for the native Iced remote protocol and validates cleanly. Neutral review compared the result with issue #26, bDS2 server/remote behavior, and specs/server.allium and found no remaining acceptance gap; the full TUI renderer remains issue #27 while #26 supplies its local/SSH session transport over the same host. Verification: cargo fmt --all -- --check; cargo clippy --workspace --all-targets with warnings denied; cargo build --workspace; cargo test --workspace; Allium check/analyse; real SSH tests for unknown/authorized/revoked keys, permissions, reconnect, two-client ordered events with one write, locale, watcher propagation, and shutdown; and a rebuilt macOS app/DMG with Computer Use verification of the localized native connect and failure states.
hugo closed this issue 2026-07-19 18:36:12 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something is not working
 duplicate
This issue or pull request already exists
 enhancement
New feature
 help wanted
Need some help
 invalid
Something is wrong
 question
More information is needed
 wontfix
This won't be fixed
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
hugo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: hugo/RuDS#26
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?