Constraints and assumptions
Constraints and assumptions
Status
Draft v1 — 2026-07-30
Technical constraints
| # | Constraint | Rationale | Impact |
|---|---|---|---|
| C1 | Plugins are external executables. The core does not load plugin code into its process space. | Language independence; isolation; crash containment. The core must survive a plugin crash. | Plugin protocol must use IPC (stdin/stdout, socket, or HTTP). Plugin lifecycle management is required. |
| C2 | The plugin protocol must be language-agnostic. | Freedom for plugin authors to use any language. | Protocol must be text-based (JSON) with no language-specific SDK requirement. |
| C3 | The playback engine must not depend on any plugin or room code. | Source-agnosticism is a hard requirement. The engine plays audio; it does not know where it came from. | Engine accepts only generic audio sources (URL, file path, byte stream). No plugin or room metadata leaks into the engine. |
| C4 | Content in the library is identified by opaque, source-independent IDs (UUIDs), not by plugin + foreign ID directly. | Platform philosophy: content is independent of source. | Library schema: content_id (UUID, opaque, source-independent) is the primary identifier. A separate mapping table stores (plugin_id, foreign_id) for resolution at playback time. The two are distinct — nothing in the library encodes which plugin produced a piece of content. |
| C5 | v1 targets desktop platforms (Linux, macOS, Windows). | Scope constraint. Mobile and web are v2 or later. | UI framework choice must be cross-platform desktop. Plugin discovery paths must respect OS conventions. |
| C6 | No cloud services in v1. Everything runs locally. | Scope constraint. No user accounts, no sync, no remote APIs in the core. | Local file system for plugin discovery, library storage, and configuration. No authentication system in v1. |
| C7 | Rooms are UI components, not separate processes. | The room framework lives in the core’s process. Rooms may be dynamic libraries or bundled code. | Room API must be defined in the core’s language (or via FFI). Room authors who want to use a different language must use the plugin system instead. |
Business constraints
| # | Constraint | Rationale |
|---|---|---|
| B1 | Rymflux is open source (license TBD). | The platform’s value is in its ecosystem, not its code. Open source enables plugin and room authors to contribute. |
| B2 | Rymflux does not host, license, or provide content. | No music licensing, no streaming infrastructure, no content partnerships. The platform is middleware. |
| B3 | Official plugins and rooms are community-developed or provided as examples only. | The core team builds the platform, not the ecosystem. First-party plugins are reference implementations. |
| B4 | Plugin API stability is a priority beginning in v1. | Breaking changes destroy the ecosystem. Versioning, deprecation notices, and migration paths are required from day one. |
Assumptions
| # | Assumption | Risk if wrong |
|---|---|---|
| A1 | Plugin authors are willing to write JSON protocol implementations for their language of choice. | If the friction of implementing JSON-RPC from scratch outweighs the benefit, plugin adoption will be low. Mitigation: provide reference client implementations in 2-3 popular languages early. |
| A2 | The room framework API complexity can be kept low enough for a single developer to build a room in a weekend. | If the room API is too complex or requires deep understanding of the core, room adoption will suffer. Mitigation: start with a minimal room API surface area and add features only when proven necessary. |
| A3 | Users will install plugins and rooms manually (copy to directory, configure in settings). | If users expect an app store or one-click install, manual installation will be a barrier. Mitigation: design the plugin directory scanning to require zero configuration; make installation a single copy operation. |
| A4 | The core platform can be built by a small team (1-3 people) in a reasonable timeframe. | If the scope is too large, the platform will ship late or not at all. Mitigation: aggressive scope management — v1 is the minimum viable platform. |
| A5 | Desktop audio APIs are sufficient for the target platforms. | If platform-specific audio APIs diverge significantly, playback engine portability will suffer. Mitigation: use a cross-platform audio library or abstract the audio backend. |
| A6 | Content deduplication across plugins is desirable and tractable. | If the same track exists on Spotify and local files, the library should not show duplicates. If deduplication proves unreliable, users will see confusing duplicates. Mitigation: content ID normalization in the search manager; make deduplication a best-effort layer. |