bases/fjord
Watch
0
0
Fork
You've already forked fjord
 0
Code Issues 3 Pull requests Projects Releases Packages Wiki Activity

Attach a desktop session from another machine #5

New issue
Open
opened 2026-10-11 13:42:45 +02:00 by arne · 0 comments
arne commented 2026-10-11 13:42:45 +02:00
Owner
Copy link

This was generated by AI during triage.

Triage: enhancement, needs-triage. Depends on: #4 (Rex, which isn't released for Linux yet). Related: #3.

Want

A fjordxy desktop is a session that lives on the machine it was made on, and another machine can attach it. Open fjordxy on the laptop, attach fox's build session, and get its terminals and apps on a laptop desktop.

This settles the terminology question in #4. A desktop is a session, one to one: it can be opened from elsewhere, not just looked at on the machine it lives on. Everything on it, terminal or GUI app, is a block.

Terminal blocks: attached live through Rex

This is what Rex is built for (from its docs; not yet verified, as there's no Linux release):

  • A server/client split. Other machines are declared in the config with rex.host{ label = "fox", endpoints = {...} } and reached with rex -S fox ... or rex.server("fox") in Lua.
  • fjordxy already provides the network: M19 sets up Tailscale (programs.fjordxy.remote.tailscale), and Rex has a tailscale_status_changed event.
  • The docs say Rex servers already run on Linux and that a Linux client exists. Neither is in public testing yet.

GUI blocks: the hard part

A Wayland app window belongs to the compositor it's connected to. A Firefox window open on fox can't move to the laptop's niri. The options:

Approach What you get Cost
Stream the whole screen (VNC, RDP, Sunshine) fox's whole screen, shown as a picture on the laptop Not a session joining the laptop's desktop, just a remote screen. Which of these work with niri hasn't been checked.
Forward single apps (waypipe) The app runs on fox and draws on the laptop Only for apps started through waypipe. It can't take over a window already open on fox, and a browser over it is heavy.
Recreate instead of attach The laptop opens its own copies of the same things: the same tabs, files and app Not the same live process. It fits how Wayland works, and it still works while fox is asleep.

Leaning towards: attach terminal blocks live, and rebuild GUI blocks from a description of what they were showing. That makes #3's data collection (the tabs in each browser window, each window's app) the input for rebuilding a session, not only something to display.

Biggest open question (for Superlogical)

Rex blocks have a kind, called a "creator". Today the only kind is com.superlogical.terminal, but the API is built around block kinds: the creator_changed event fires when "the kinds of block the session can create have changed".

Can third parties register their own block kinds? If so, fjordxy could register a GUI-app block, and a whole desktop, apps included, would live in one Rex session that any client can list, attach and rebuild. If not, fjordxy needs its own record of each session's GUI blocks, kept next to Rex's.

Other open questions

  1. What a GUI block's description is, per app: Firefox (tab URLs; the session file or an extension, see #3), editors (file paths, which assumes the files are reachable from the laptop), and everything else (just the app_id: launch it again, empty).
  2. What survives a reboot. The Rex docs don't say whether a session's layout, labels and working directories come back after the server restarts. The running programs can't. Recreatable GUI blocks would survive by design.
  3. Two machines with the same session open. Is it shared live, like Rex terminals, or does attaching on the laptop take it away from fox?
  4. What "a desktop" means on the laptop's side. Attaching creates a niri workspace on the laptop. Does it get named after the session? What happens to it on detach?
  5. Security. Attaching gives terminals on fox to whoever can reach Rex on fox. That relies on Tailscale and Rex's own authentication (its clients have a principal), and both need understanding before this is turned on.
> *This was generated by AI during triage.* **Triage:** enhancement, needs-triage. **Depends on:** #4 (Rex, which isn't released for Linux yet). **Related:** #3. ## Want A fjordxy desktop is a **session** that lives on the machine it was made on, and another machine can attach it. Open fjordxy on the laptop, attach fox's `build` session, and get its terminals and apps on a laptop desktop. This settles the terminology question in #4. A desktop *is* a session, one to one: it can be opened from elsewhere, not just looked at on the machine it lives on. Everything on it, terminal or GUI app, is a **block**. ## Terminal blocks: attached live through Rex This is what Rex is built for (from its docs; not yet verified, as there's no Linux release): - A server/client split. Other machines are declared in the config with `rex.host{ label = "fox", endpoints = {...} }` and reached with `rex -S fox ...` or `rex.server("fox")` in Lua. - fjordxy already provides the network: M19 sets up Tailscale (`programs.fjordxy.remote.tailscale`), and Rex has a `tailscale_status_changed` event. - The docs say Rex servers already run on Linux and that a Linux client exists. Neither is in public testing yet. ## GUI blocks: the hard part A Wayland app window belongs to the compositor it's connected to. A Firefox window open on fox can't move to the laptop's niri. The options: | Approach | What you get | Cost | | --- | --- | --- | | **Stream the whole screen** (VNC, RDP, Sunshine) | fox's whole screen, shown as a picture on the laptop | Not a session joining the laptop's desktop, just a remote screen. Which of these work with niri hasn't been checked. | | **Forward single apps** (waypipe) | The app runs on fox and draws on the laptop | Only for apps *started* through waypipe. It can't take over a window already open on fox, and a browser over it is heavy. | | **Recreate instead of attach** | The laptop opens its own copies of the same things: the same tabs, files and app | Not the same live process. It fits how Wayland works, and it still works while fox is asleep. | **Leaning towards:** attach terminal blocks live, and rebuild GUI blocks from a description of what they were showing. That makes #3's data collection (the tabs in each browser window, each window's app) the input for rebuilding a session, not only something to display. ## Biggest open question (for Superlogical) Rex blocks have a kind, called a "creator". Today the only kind is `com.superlogical.terminal`, but the API is built around block kinds: the `creator_changed` event fires when "the kinds of block the session can create have changed". **Can third parties register their own block kinds?** If so, fjordxy could register a GUI-app block, and a whole desktop, apps included, would live in one Rex session that any client can list, attach and rebuild. If not, fjordxy needs its own record of each session's GUI blocks, kept next to Rex's. ## Other open questions 1. **What a GUI block's description is**, per app: Firefox (tab URLs; the session file or an extension, see #3), editors (file paths, which assumes the files are reachable from the laptop), and everything else (just the app_id: launch it again, empty). 2. **What survives a reboot.** The Rex docs don't say whether a session's layout, labels and working directories come back after the server restarts. The running programs can't. Recreatable GUI blocks would survive by design. 3. **Two machines with the same session open.** Is it shared live, like Rex terminals, or does attaching on the laptop take it away from fox? 4. **What "a desktop" means on the laptop's side.** Attaching creates a niri workspace on the laptop. Does it get named after the session? What happens to it on detach? 5. **Security.** Attaching gives terminals on fox to whoever can reach Rex on fox. That relies on Tailscale and Rex's own authentication (its clients have a `principal`), and both need understanding before this is turned on.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
screen-recording
niri-wallpaper-in-overview
niri-kdl-escape-hatch
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
bases/fjord#5
No description provided.