Feature Request: Port to Tauri for Native Performance, Local File Access & Multi-Model Support

[GQAdonis]

Summary

OpenGravity is a great concept, but the browser-based WebContainer approach introduces
unnecessary constraints — sandboxed file access, performance overhead, and tight coupling
to Gemini's API. Porting to Tauri 2 would address all of these at once.

Proposed Benefits

Native Local File System Access

Tauri's tauri-plugin-fs provides direct, permission-scoped access to the local file
system — no WebContainer, no sync workarounds, no browser sandbox limitations.

Performance

The Tauri shell (Rust + WebView2/WKWebView) is dramatically lighter than an Electron
or browser-tab runtime. The frontend can remain in vanilla JS/HTML or migrate to a
lightweight React/Vite setup.

Multi-Model Support via a Unified LLM Router

Rather than hardcoding Gemini, a Tauri backend could integrate a Rust-native LLM
routing layer (e.g. liter-llm — the kreuzberg-dev/liter-llm crate — which supports
142 providers with Tower middleware). This would make true BYOK a first-class feature
and allow routing to Anthropic, OpenAI, local Ollama/llama.cpp instances, etc.

Enhanced Agentic Functionality

A Rust backend process opens the door to a proper Universal Agent Runtime (UAR) —
persistent agent state, subagent spawning, tool execution, and MCP server integration —
without being constrained by what a browser tab can do.

Suggested Architecture

• Frontend: existing vanilla JS/HTML UI (or Vite + lightweight framework),
  unchanged visually
• Backend (Rust/Tauri):
  • File system operations via tauri-plugin-fs
  • Terminal via tauri-plugin-shell or embedded PTY (e.g. portable-pty)
  • LLM routing via liter-llm crate (BYOK, multi-provider)
  • Optional: MCP tool support for extended agent capabilities

References

• Tauri v2 docs
• kreuzberg-dev/liter-llm
• Model Context Protocol

Happy to contribute or collaborate on this if there's interest.