Vision statement + KPIs

Vision statement + KPIs

Status

Draft v1 — 2026-07-30

Vision statement

Rymflux is an audio platform that treats every listening experience as a unique space. Instead of forcing all audio into one generic interface — the same queue, the same metadata layout, the same player — Rymflux provides specialized rooms, each optimized for how people actually consume that type of audio.

A music listener browses albums and builds queues. A podcast listener subscribes to shows and resumes episodes. An audiobook listener tracks chapter progress and takes notes. Live radio has no chapters at all. Rymflux does not ask these experiences to share a UI. It asks them to share a platform.

Underneath the rooms, a language-agnostic plugin system decouples content sources from the experience layer. Spotify, local files, podcasts, and future services each live in their own plugin. They speak JSON over a standard protocol to the core. The core does not know or care what language the plugin was written in. It only knows what capabilities the plugin advertises.

The result is a platform where new content sources and new listening experiences can be added independently — without changing the core application and without forcing users into a one-size-fits-all interface.

What Rymflux is

Rymflux is not a media player. It is a platform for audio experiences.

• It is a plugin host for content sources.
• It is a room framework for experience designers.
• It is a playback engine that does not know or care where the audio came from.
• It is a library system that treats all content uniformly regardless of source.

Rymflux does not ship with Spotify support, or podcast support, or audiobook support. It ships with a plugin system and a room system. Content sources and experience designs are both installed separately.

Platform philosophy

These principles guide every design decision in the platform. Every feature, every API, every contract is evaluated against them.

Principle 1: Content is independent of source

A user saves “Song X”, not “Song X from Plugin A.” The library, queue, and history record what was played — not which plugin the user used to find it. Plugin attribution is stored as a resolution detail, not as content identity. Two saves of the same track from different plugins share one content UUID.

Principle 2: Rooms own experiences

The core platform does not decide how audiobooks look. The Audiobook Room does. Each room defines its own navigation, search behavior, metadata layout, player expansion, context menus, sorting, and filtering. The core provides services; rooms compose them.

Principle 3: Plugins provide capabilities, not UI

A plugin advertises “I can search,” “I can stream,” “I can provide lyrics.” It does not render search results, design the player, or decide how metadata is displayed. The room framework owns presentation. Plugins own data and operations.

Principle 4: The playback engine is source-agnostic

The engine receives audio — a stream URL, a file path, a byte stream — and plays it. It does not know whether the audio came from Spotify, a local file, a podcast RSS feed, or a university lecture plugin. It has no concept of plugins, rooms, or content types.

Principle 5: Everything communicates through contracts

Whether it is the core talking to plugins, rooms talking to the playback engine, or the library reacting to events, interactions happen through well-defined interfaces rather than direct dependencies. Any component can be replaced or extended as long as it respects the contract.

Architecture vision

                ┌──────────────────────┐
                │   Navigation & Shell │
                ├──────────────────────┤
                │  Room Framework      │
                │  (Music / Podcast /  │
                │   Audiobook / Radio) │
                ├──────────────────────┤
                │  Platform Services   │
                │  Library | Search    │
                │  | Playback Engine   │
                ├──────────────────────┤
                │  Event Bus / Cache   │
                │  / Identity          │
                ├──────────────────────┤
                │  Plugin Runtime      │
                ├──────────────────────┤
                │  Spotify | Podcasts  │
                │  | Local Files | …   │
                └──────────────────────┘

This diagram shows the full platform vision. v1 delivers only the Music Room and Home (Lobby) — see scope.md. Additional rooms and the event bus are v2 targets.

The plugin system is at the bottom, providing content and capabilities. The room system is near the top, deciding how users experience that content. Platform services in the middle are shared by all rooms.

Target audience

Success criteria & KPIs

Platform health

Developer ecosystem

User experience