taikutaiku
User GuidePluginsAPI Reference

Workspaces

Shared workspaces, tile types, ownership, adoption, and the layouts that make taiku collaborative.

A workspace in taiku is your personal arrangement of terminals, tunnels, plugins, and other tiles within a shared session. While everyone in a session shares the same underlying terminal state, each participant can organize their view independently.

Workspace layout with shell, tunnel, and plugin tiles

Tile types

A workspace page is a tiled layout where each tile is one of:

  • Shell tiles: a terminal connected to a shell process on the host machine.
  • Tunnel tiles: a live preview of a tunneled port (e.g., a running web app).
  • Peek tiles: a read-only view of another participant's terminal.
  • Browser tiles: an embedded web page (documentation, dashboards, etc.).

Tiles are arranged in a binary split tree (the same model as i3). You split tiles horizontally or vertically to create new panes.

Workspace with four tile types in a 2x2 grid

Multiple workspaces

Each participant can maintain multiple workspaces. Workspaces are independent layouts, and switching between them is instant because terminal connections persist regardless of which workspace you are viewing.

Separate workspaces by intent: one for coding, one for logs, one for previews, one for monitoring teammates. All workspaces share the same session. The terminals on your "Logs" workspace are the same terminals visible to other participants.

Ownership

When you create a shell, you own it. Ownership is stored in your browser's local storage, keyed to the session ID. This means:

  • You can always type into and resize your own shells, even when others are in the session.
  • Other participants see your shells labeled with your name in the peek panel.
  • Closing your tab and reopening restores ownership from local storage.
  • Opening from a different browser starts fresh, so you'd need to adopt your shells back.

For how ownership interacts with multi-user collaboration, see Collaboration.

Adoption

Adoption is how ownership transfers between participants:

  1. Request. You find the terminal you want and trigger an adoption request.
  2. Prompt. The current owner sees a toast: "Nathan is requesting control of shell 3. Allow or deny?"
  3. Resolution. If approved, ownership transfers. Your workspace gains the terminal, theirs loses it. If denied, nothing changes.

The same flow applies to tunnel ports. Adoption keeps control explicit, which matters in sessions where multiple people are working on different things. See Collaboration for detailed scenarios and best practices.

On this page