Octanium Roadmap

Vision

Octanium is a portable, offline-first personal operating environment that runs on top of Windows and Linux. It is launched from an external SSD without installation and without taking ownership of the host system.

The product is not a kernel-level operating system. It is a portable workspace for creative and autonomous work: files, tools, plugins, indexes, local apps, caches, settings, and project metadata live on the drive and travel with the user.

Network access, sync, AI, and remote services are optional layers. The baseline product must remain useful when offline.

Product Pillars

• Portable-first: the primary data root is <drive>/.octanium/, resolved relative to the executable or mounted bundle.
• Offline-first: local data is always readable without network access.
• Artifact-centric: files, folders, saved pages, notes, media, projects, and links are treated as first-class artifacts.
• Creative-native: image, audio, video, 3D, font, texture, preset, and document workflows are core use cases.
• Extensible: built-in apps and user plugins share a capability-based platform surface.

Phase 0: Current MVP

Implemented

• Tauri + React shell foundation.
• Taskbar, launcher, built-in app panels, settings, and wallpaper support.
• Static built-in app registry.
• Basic File Explorer constrained by a configured workspace root.
• Terminal command runner that executes host commands and captures stdout/stderr.
• Developer Center for inspecting registered apps and basic runtime availability.
• Frontend tests and Rust backend unit tests.

Partially Implemented Or In Flux

• Window management exists as shell UI work, but full draggable/resizable multi-window behavior must be verified against the current implementation before being treated as complete.
• Plugin registry concepts exist, but portable dynamic plugin loading is not yet a stable shipped capability.

Explicit Non-goals For MVP

• Kernel-level filesystem hooks.
• Custom browser engine.
• VM-grade plugin sandboxing.
• Full interactive PTY terminal.
• Dynamic native/WASM plugin ABI.

Phase 1: Portable Core

Goal: Octanium runs from an external SSD on a compatible Windows or Linux machine without installation, administrator rights, registry writes, or required network access.

Must Ship

• Portable root resolver based on the executable/bundle location.
• Self-contained data directory at <drive>/.octanium/.
• Strict portable mode that blocks writes outside the portable root, except user-selected files explicitly imported or linked.
• Cross-platform path abstraction for Windows drive letters and Linux mount points.
• Volume identity tracking so drive letter changes do not break the workspace.
• Portable config profile with clear fallback behavior for non-strict mode.
• Packaging research and first distributable target for Windows portable .exe.
• Linux-ready path and packaging assumptions for AppImage or tarball distribution.

Done When

• A clean Windows host can launch Octanium from an external drive without installation or admin rights.
• Strict portable mode leaves no intentional writes outside <drive>/.octanium/.
• Moving the drive from one drive letter to another preserves settings and workspace identity.
• The app starts and basic navigation works without internet access.
• Portable root behavior is covered by backend tests.

Risks

• Windows SmartScreen or antivirus may block unsigned portable binaries.
• Host runtime availability can vary widely; bundled runtimes should remain optional at this stage.

Phase 2: File Intelligence Core

Goal: Build the durable local artifact index: fast file search, tags, projects, file identity, Inbox, collection, and ghost recovery.

Must Ship

• SQLite index.db under <drive>/.octanium/.
• Versioned migrations for items, tags, item_tags, projects, project_items, links, items_history, and FTS tables.
• Rust file walker for initial indexing.
• Filesystem watcher for incremental updates using platform-native events where possible.
• FTS5 name/path search with a target response time below 50ms for common queries.
• Stable identity using platform file IDs where available plus partial content hash.
• Inbox import flow with Copy, Move, and Link only modes.
• Artifact Collection Mode for deliberate project-oriented importing.
• Ghost file status and recovery actions: Locate, Try to find, Remove from index.
• Smart File Explorer v1 with tags, project indicators, saved views, and batch tag operations.

Done When

• A user can index the portable workspace and search by name/path quickly.
• Dragging a file into Octanium creates an artifact record with starter tags.
• Moving or deleting a tracked file outside Octanium produces a recoverable ghost record.
• File Intelligence has integration tests for import, search, retagging, and ghost recovery.

Non-goals

• Full semantic search.
• Complete media metadata extraction.
• AI tagging.
• Cross-device sync.

Phase 3: Creative Asset Engine

Goal: Make creative files first-class citizens through previews, metadata, creative categories, and asset-focused views.

Must Ship

• Creative file classes: image, audio, video, 3d, font, document, project, archive, material, brush, and preset.
• Preview queue with status tracking and thumbnail cache.
• Quick Look support for images, text, markdown, PDF, audio, video posters, fonts, and basic 3D metadata.
• Metadata extraction for:
  • images: dimensions, EXIF where available, dominant colors;
  • audio: duration, bitrate, sample rate, embedded cover where available;
  • video: codec, resolution, fps, duration, poster frame;
  • fonts: family, style, weight, glyph/specimen preview;
  • 3D: format-level metadata and scene metadata where practical.
• Saved views for Image Library, Sound Library, Video Library, Font Library, 3D Library, and mixed project boards.
• Batch collect, batch retag, and batch move workflows for creative assets.

Done When

• A creative folder can be indexed and browsed by media type without manually arranging files into separate folders.
• Quick Look opens common creative formats quickly and does not block the shell.
• Failed preview generation is visible and recoverable.

Non-goals

• Professional editing tools.
• Full DCC replacement.
• Heavy AI analysis.

Phase 4: PTY Terminal And Runtime Detection

Goal: Replace the command runner with a real terminal and make portable/local runtimes visible to users and plugins.

Must Ship

• xterm.js frontend integrated into the Terminal app.
• Rust PTY backend using portable-pty or an equivalent cross-platform approach.
• Multi-tab terminal sessions.
• Support for interactive programs such as Python REPL, Node REPL, Git prompts, Vim, and shell tools.
• Runtime detection for Python, Node.js, Git, PowerShell, bash/zsh, ffmpeg, yt-dlp, ImageMagick, and Cargo where relevant.
• Developer Center view for available host and bundled tools.
• Optional bundled runtimes directory under <drive>/.octanium/runtimes/ or a sibling portable tools directory.

Done When

• Interactive terminal programs behave correctly on Windows.
• Runtime detection clearly distinguishes host-provided and portable-bundled tools.
• Plugins and automation can request a runtime through a stable API instead of hardcoding paths.

Phase 5: Plugin SDK And Capability Model

Goal: Turn Octanium into a safe portable app host for built-in apps and user plugins.

Must Ship

• Plugin manifest v2 with runtime, entrypoint, icon, permissions, and compatibility metadata.
• Web App Plugin runtime for HTML/JS/CSS inside a constrained Tauri webview.
• Python Plugin runtime using stdio JSON-RPC or a local socket.
• Node.js Plugin runtime using stdio JSON-RPC or a local socket.
• Capability prompts for filesystem, process execution, network, notifications, event bus, and background workers.
• TypeScript package octanium-sdk with typed APIs:
  • os.fs
  • os.window
  • os.notifications
  • os.state
  • os.search
  • os.tags
  • os.assets
  • os.network
• Plugin data directory isolation under <drive>/.octanium/plugin-data/<plugin-id>/.

Done When

• A simple web plugin and a simple Python plugin can be installed from the portable plugins directory.
• Plugin permissions are visible before activation.
• Denied capabilities fail clearly and do not silently fall back to host-wide access.

Non-goals

• Stable native binary ABI.
• Marketplace distribution.
• VM-level sandboxing.

Phase 6: Internal Event Bus And App Composition

Goal: Let built-in apps and plugins cooperate through explicit events and shared state.

Must Ship

• Rust-backed event bus with publish/subscribe APIs.
• Cross-app flows:
  • File Explorer opens artifacts in registered viewer/editor plugins.
  • Terminal accepts dropped paths.
  • Offline apps can save artifacts to Inbox.
  • Creative views can send assets to project boards.
• Shared state slots with access controlled by capability declarations.
• Sub-window API for plugin-owned child windows.

Done When

• App-to-app workflows work without hardcoded direct dependencies between app implementations.
• Event subscriptions are scoped and auditable.

Phase 7: Offline Apps

Goal: Ship local-first applications that prove Octanium is useful without internet access.

Must Ship

• RSS Reader with local feed/article storage and background refresh.
• Offline Browser with reader snapshots and full-page archive mode.
• Knowledge Base or markdown wiki.
• Media Library and Font Library built on the Creative Asset Engine.
• Local cache model shared by offline apps.

Candidate Apps

• Telegram Reader with encrypted session storage.
• 3D Asset Viewer.
• Map app for local map and geodata caches.

Done When

• At least one offline app provides high value with no network connection after data has been cached.
• Saved web/feed content is searchable through File Intelligence.

Phase 8: Local Services, Automation, And On-device AI

Goal: Add optional local workers, automation scripts, and AI services without making them required for baseline use.

Must Ship

• Local services runner for converters, sync workers, embedding workers, and automation tasks.
• Scheduler for recurring local jobs.
• Python automation SDK octanium-py.
• Script editor in Developer Center with sandboxed execution profile.
• Optional integration with local model providers such as Ollama, llama.cpp, or ONNX Runtime.
• Embeddings and semantic search for notes, documents, and indexed descriptions.
• Optional OCR, captioning, and image tagging workers.

Done When

• Users can disable all AI and automation features without affecting the core shell, index, or offline apps.
• Automation permissions are explicit and auditable.

Phase 9: Secure Mesh Networking

Goal: Let trusted Octanium instances communicate and sync without depending on a public cloud as the source of truth.

Must Ship

• Local-only mode as the default baseline.
• Node identity and trusted peer model.
• Tailscale integration as the practical first transport.
• Yggdrasil research track as an advanced decentralized option.
• Connection dashboard with peer status, last sync, and trust level.
• Remote sync over mesh for selected indexes, knowledge base data, vault metadata, and project folders.

Done When

• Mesh networking can be disabled completely.
• Sync scopes are selected by the user and do not implicitly expose the whole drive.

Phase 10: Vault, Backup, And Disaster Recovery

Goal: Protect sensitive data and make the portable environment recoverable.

Must Ship

• Encrypted vault for secrets, sessions, private notes, and credentials.
• Early support for protecting Telegram sessions and plugin secrets.
• Snapshot system for index, settings, plugin data, knowledge base, and selected app databases.
• Backups under <drive>/.octanium/backups/.
• Multi-disk export/import and merge strategy using content hashes and item history.
• Disaster recovery workflow for rebuilding an Octanium SSD from a snapshot or encrypted export.

Done When

• Sensitive app sessions can be stored outside plaintext settings.
• A fresh drive can restore the core environment from backup without cloud dependency.

Parallel Track: Web Presence And Documentation

Goal: Maintain a public-facing site, documentation, and development log without distracting from core product work.

Must Ship

• Documentation site generated from docs/.
• Architecture, plugin SDK, security, and roadmap pages.
• Dev blog or release notes.
• Deployment target such as Vercel, Netlify, or Cloudflare Pages.

Next Five Implementation Milestones

1. Implement portable root resolver and strict portable write policy.
2. Add SQLite migrations for File Intelligence core tables.
3. Build the first file indexer and name/path FTS search command.
4. Implement Inbox import with starter tags and artifact records.
5. Add ghost detection and recovery flow for moved/deleted files.

Strategic Focus

• Portable Core.
• File Intelligence.
• Creative Asset Engine.
• Plugin SDK with capability security.
• Offline Apps.
• Vault and recovery.

Research Tracks

• Linux AppImage packaging and mount-point path handling.
• Preview generation libraries for media, fonts, documents, and 3D.
• Local model serving through Ollama, llama.cpp, and ONNX Runtime.
• Mesh sync over Tailscale and Yggdrasil.
• Code signing and portable binary trust on Windows.