Persona: Priya — the plugin developer

Secondary persona. Priya maintains an open-source wrapper for a music service API and wants to integrate it with Rymflux.

Persona: Priya — the plugin developer

Secondary persona for v1. Drives the plugin protocol specification, manifest format, and developer documentation.

Demographics

Goals

1. Write a Rymflux plugin in their language of choice (Go) in under an hour.
2. Publish the plugin so users can install it by dropping a directory into the plugins folder.
3. Only implement the capabilities their source supports (e.g., search and stream, but not lyrics).
4. Debug plugin issues without needing a Rymflux developer’s help.

Pain points

1. Language lock-in: Many platforms force a specific language or runtime. Priya does not want to learn Rust or JavaScript to write a music plugin.
2. Underspecified protocols: Vague API docs lead to trial-and-error implementation. Priya wants exact JSON schemas and a conformance checker.
3. Opaque failures: When the plugin fails, unclear error messages or silent failures make debugging painful.
4. No test harness: Priya has to run the full app to test the plugin. A standalone validator would save iterations.
5. Authentication complexity: If the content source requires OAuth or API keys, the plugin must handle it — but Priya wants clear guidance on where and how to store credentials.

Behaviours

• Reads API docs before writing any code. Abandons integrations if docs are unclear or incomplete.
• Prefers a minimal “hello world” example in their language as a starting point.
• Writes a working plugin first, adds error handling and edge cases second.
• Expects the plugin protocol to be versioned with a clear changelog for breaking changes.
• Publishes their plugin as an open-source repository on GitHub.

Scenarios

Primary scenario: First plugin

Context: Priya maintains a Go library for the Jamendo music API. She wants to expose it as a Rymflux plugin.

Goal: Write, test, and install a working Jamendo plugin in under one hour.

Success criteria:

• Reads the plugin protocol spec and understands the request/response format in 10 minutes.
• Creates plugins/jamendo/plugin.toml and plugins/jamendo/jamendo (compiled Go binary).
• Implements search and stream capabilities.
• Runs a conformance validator against the binary and passes all tests.
• Drops the plugin directory into ~/.rymflux/plugins/ and sees Jamendo content appear in the Music Room.

Secondary scenario: Debugging a plugin

Context: Priya’s plugin works locally but a user reports that search for non-ASCII queries returns an error.

Goal: Reproduce and fix the bug without rebuilding the entire Rymflux app.

Success criteria:

• Priya enables verbose logging for her plugin.
• She sends a test request via a standalone CLI tool (or captured logs).
• She identifies the encoding issue in her Go code, fixes it, and rebuilds the binary.
• The fix is confirmed by re-running the conformance validator.

Quotes

“If I can write the plugin in Go and you give me a working example, I’ll have it done in an afternoon. If you force me into a language I don’t use, I won’t bother.”

Validation

Related

• Journey map: Plugin developer journey
• User stories: Register a content-source plugin, Stream audio from a plugin
• Other personas: Listener, Room author