Skip to main content
Corvus Connection

Corvus Connection on Linux

A Linux streamer should get the same local-first companion a Windows streamer does: the bot, your accounts, and your overlays running on your own machine, with your data encrypted at rest and the cloud optional. The Linux build shares one codebase with the Windows app and re-authors only the screens on Avalonia. It is in active development and not yet released; this page tracks what is built and what is next.

At a glance

Local-first, encrypted at rest, and cloud optional. The bot and your data stay on your machine. Linking an account still uses the same secure broker the Windows app does, so you never paste a platform secret into the app.
  • Built
    implemented and tested
  • In progress
    being built now
  • Planned
    designed, not yet started

Status

Runtime and data

  • Local-first bot runtime

    Built
    The bot runs inside the app itself. There is no bundled server and no separate database process.

  • Encrypted local database

    Built
    Your data, linked-account tokens, and stream history live in a single AES-256 encrypted file. The key is held by your system keyring, so nothing readable sits on disk.

  • Chat commands and message rules

    Built
    The engine that answers commands and applies message rules runs today; the screens to edit them are in progress.

  • Scripting engines (JavaScript, Python, V)

    Built
    The app supervises each script engine as a child process, gated on whether the toolchain is installed and enabled, and cleans them up when it exits.

Screens

  • Dashboard

    Built
    The home view: runtime status, connection health, and quick links.

  • Live Feed

    Built
    Chat and stream events as they arrive.

  • Connections and account linking

    Built
    Link Twitch, Spotify, and more, and see each link stay healthy.

  • Chat Commands editor

    In progress
    Add, edit, and organize the commands your bot answers.

  • Message Templates and Rules editors

    In progress
    Author the templates and rules that shape what the bot says.

  • Settings

    In progress
    The essential preferences for the local-first build.

Platform integration

  • System-keyring secret storage

    Built
    Secrets go into the desktop keyring (Secret Service). Where no keyring is present, an app-encrypted file takes over.

  • Account linking through your browser

    In progress
    Sign-in opens in your default browser; the local hand-back that completes the link is in progress.

  • Tray icon and background running

    Planned
    Keep the bot running with the window closed, with a tray icon where the desktop supports one.

  • Desktop notifications

    Planned
    Native notifications for the events you care about.

Packaging and release

  • AppImage

    Planned
    A single self-contained download that runs without a system-wide .NET install.

  • Automatic updates

    Planned
    In-app update checks and one-click upgrades.

  • Cross-distro verification

    Planned
    The release gate: a full pass on GNOME and KDE Plasma, across X11 and Wayland, before the first build ships.

Security by design

Your access tokens are the keys to your channel, so the Linux build treats them that way. The whole local database is encrypted with AES-256, and the encryption key is kept in your system keyring rather than beside the data. If no keyring is available, a labeled fallback keeps the app working while making its weaker posture clear. This is a deliberate edge, and a foundation for the audit-readiness work we are building toward.

How it is built

  • One codebase, two heads. The view-models and services are shared with the Windows app; only the screens are re-authored in Avalonia. Fixing a behavior fixes it on both.
  • No server, no separate database. The bot runtime, the script engines, and SQLite all run inside the one app process. There is nothing extra to install or supervise.
  • Encryption at rest. SQLite3MC provides whole-file AES-256 encryption; the key lives in the desktop keyring (Secret Service), with an encrypted-file fallback where none exists.
  • Native file locations. Settings, data, and runtime files follow the XDG base directories, and every secret and database file is created for your account only.
  • Clean process supervision. Script engines start under the kernel's parent-death signal and are torn down as a group, so quitting the app never leaves an orphan behind.

Distributions and desktops

The goal is broad, distribution-agnostic support: any modern X11 or Wayland session. GNOME (which needs an extension for a legacy tray) and KDE Plasma are the primary tested desktops. Where the desktop has no tray, the app runs in a normal window instead, and the bot keeps running either way.

Follow along or help

Running Linux and want to try it early, or have a distribution you would like tested? Email support@theomenden.com. You can also read how we approach security and accessibility across the app.