204 lines
7.2 KiB
Markdown
204 lines
7.2 KiB
Markdown
# XWorkspace Architecture
|
||
|
||
XWorkspace is an AI Workspace Shell built on top of standard Linux, systemd, Chrome / Chromium, and local runtime services.
|
||
|
||
The core idea is simple:
|
||
|
||
Do not expose a traditional Linux desktop to the user.
|
||
Use Chrome / Chromium as the Desktop Shell, and use a local AI Workspace Portal as the main entry point.
|
||
|
||
XWorkspace is not trying to build a full operating system from scratch. It keeps the Linux base stable and standard, while replacing the user-facing desktop experience with an AI-native workspace.
|
||
|
||
⸻
|
||
|
||
## 1. Design Goals
|
||
|
||
XWorkspace is designed around the following principles:
|
||
|
||
### 1. Chrome / Chromium as Desktop Shell
|
||
The user enters the workspace through Chrome / Chromium instead of XFCE, GNOME, or a traditional desktop environment.
|
||
|
||
### 2. Portal-first user experience
|
||
The main workspace UI is a local web portal, usually exposed at: http://localhost:17000
|
||
|
||
3. Minimal traditional desktop exposure
|
||
XWorkspace avoids exposing panels, desktop icons, file manager desktops, or traditional application menus.
|
||
4. Local-first runtime services
|
||
Core services run locally through user-level systemd services.
|
||
5. AI Agent oriented workflow
|
||
The workspace is optimized for Agent, Terminal, Browser Use, Computer Use, Model Gateway, Vault, Workflow, Skill, and Plugin scenarios.
|
||
6. Composable service architecture
|
||
Each runtime capability is an independent service that can be started, stopped, upgraded, or replaced separately.
|
||
|
||
⸻
|
||
|
||
## 2. High-level Architecture
|
||
|
||
```i11·
|
||
┌──────────────────────────────────────────────┐
|
||
│ Layer 1:Chrome / Chromium Desktop Shell │
|
||
│ │
|
||
│ - App mode / kiosk mode │
|
||
│ - Fullscreen workspace entry │
|
||
│ - Replaces traditional Linux desktop entry │
|
||
│ - Opens http://localhost:17000 │
|
||
└──────────────────────┬───────────────────────┘
|
||
↓
|
||
┌──────────────────────────────────────────────┐
|
||
│ Layer 2:AI Workspace Portal │
|
||
│ │
|
||
│ - Dashboard │
|
||
│ - App launcher │
|
||
│ - Runtime status │
|
||
│ - Agent sessions │
|
||
│ - Terminal / VSCode / Files │
|
||
│ - Model / Vault / Workflow entry │
|
||
└──────────────────────┬───────────────────────┘
|
||
↓
|
||
┌──────────────────────────────────────────────┐
|
||
│ Layer 3:Core Services │
|
||
│ │
|
||
│ - Bridge │
|
||
│ - Agent Runtime / Gateway │
|
||
│ - LiteLLM Proxy │
|
||
│ - Vault / Vault Proxy │
|
||
│ - ttyd │
|
||
│ - Status Generator │
|
||
│ - Local API / SSE / WebSocket │
|
||
└──────────────────────┬───────────────────────┘
|
||
↓
|
||
┌──────────────────────────────────────────────┐
|
||
│ Layer 4:App / Extra Services │
|
||
│ │
|
||
│ - Agent │
|
||
│ - Skill │
|
||
│ - Workflow │
|
||
│ - Plugin │
|
||
│ - Computer Use │
|
||
│ - Browser Use │
|
||
│ - Code Server │
|
||
│ - File Browser │
|
||
└──────────────────────────────────────────────┘
|
||
|
||
## 3. Runtime Flow
|
||
|
||
Linux boot
|
||
↓
|
||
User-level systemd session
|
||
↓
|
||
Core services start
|
||
↓
|
||
xworkspace-portal.service starts local portal
|
||
↓
|
||
xworkspace-shell.service starts Chrome / Chromium
|
||
↓
|
||
Chrome / Chromium opens http://localhost:17000
|
||
↓
|
||
User enters AI Workspace Portal
|
||
↓
|
||
Portal talks to Bridge, Agent, LiteLLM, Vault, ttyd, and extra services
|
||
|
||
## 4. Core Concept
|
||
|
||
Traditional Linux desktop:
|
||
Desktop Environment
|
||
├─ Panel
|
||
├─ File Manager
|
||
├─ Terminal
|
||
├─ Browser
|
||
├─ App Menu
|
||
└─ Settings
|
||
|
||
XWorkspace desktop
|
||
|
||
Chrome / Chromium Desktop Shell
|
||
└─ AI Workspace Portal
|
||
├─ Agent Console
|
||
├─ Terminal
|
||
├─ VSCode / Code Server
|
||
├─ Files
|
||
├─ Model Gateway
|
||
├─ Vault Secrets
|
||
├─ Runtime Status
|
||
├─ Workflow Runner
|
||
├─ Plugin Center
|
||
├─ Browser Use
|
||
└─ Computer Use
|
||
|
||
|
||
## 5. Display Stack Strategy
|
||
|
||
XWorkspace avoids supporting the traditional X11 desktop experience as a product surface.
|
||
However, Chrome / Chromium still needs a display stack.
|
||
Recommended evolution path:
|
||
|
||
Stage 1:
|
||
|
||
Use XFCE or a lightweight desktop session, but hide traditional desktop components and only expose Chrome / Chromium Shell.
|
||
|
||
Stage 2:
|
||
|
||
Replace XFCE with a minimal window manager. Only Chrome / Chromium is launched as the visible workspace shell.
|
||
|
||
Stage 3:
|
||
|
||
Move to Wayland / Weston / Cage mode. Chrome / Chromium becomes the only user-facing shell.
|
||
|
||
|
||
## Access & Exposure Strategy
|
||
|
||
XWorkspace follows a secure-by-default access strategy.
|
||
|
||
By default, XWorkspace does not expose the full AI Workspace Portal, WebRTC Desktop, ttyd, LiteLLM, Vault, or other internal services directly to the public Internet.
|
||
|
||
The default public entry should be limited to: https://xworkmate-bridge.example.com
|
||
|
||
This endpoint is protected by an access token in the early stage and should evolve to JWT-based authentication in future versions.
|
||
|
||
Default Access Model
|
||
|
||
Public Internet
|
||
↓
|
||
https://xworkmate-bridge.example.com
|
||
↓
|
||
Token / Future JWT Auth
|
||
↓
|
||
XWorkmate Bridge
|
||
↓
|
||
Local Core Services
|
||
|
||
The AI Workspace Portal remains local by default:
|
||
|
||
Chrome / Chromium Desktop Shell
|
||
↓
|
||
http://localhost:17000
|
||
↓
|
||
AI Workspace Portal
|
||
|
||
|
||
Not exposed by default:
|
||
|
||
- AI Workspace Portal
|
||
- WebRTC Desktop
|
||
- ttyd
|
||
- LiteLLM
|
||
- Vault
|
||
- OpenClaw Gateway
|
||
- Internal status endpoints
|
||
- Plugin / workflow services
|
||
|
||
Advanced User Mode
|
||
|
||
Advanced users may choose to expose additional services, but they should do so explicitly and with stronger access controls.
|
||
Recommended advanced exposure requirements:
|
||
|
||
- HTTPS
|
||
|
||
- MFA
|
||
- JWT authentication
|
||
- IP allowlist, optional
|
||
- Reverse proxy access policy
|
||
- Audit logs
|
||
- Rate limiting
|
||
- Separate subdomains for sensitive services
|