Opportunity: Notification System
MA 2.10 — Synthesized from Marvin/Carl meeting notes, June 5 2026
Problem statement
When MA isn't in focus, it's silent. A great track comes on — no signal. A favourite artist drops an album — MA says nothing. Every major music platform solves this: Apple Music sends now-playing OS notifications when the app isn't in focus; Spotify pushes release alerts for followed artists. MA has no equivalent on either front.
Native desktop and mobile apps are in development, meaning OS-level notification delivery is achievable and not a distant future-state dependency. And with #63 addressing active player state visibility within the app, the scope here is clear: OS notifications for the moments when MA isn't in view; an in-app tray for system messages, feature discovery, and tutorial nudges.
MA's vision commits to conveying emotion — "we suggest what makes your home listening experience more personalized." A release alert for an artist you love is that pillar made concrete. It also supports effortless — "no documentation is needed for day-to-day usage" — by closing the gap between new features shipping and users actually finding them.
Community signals
- MA 2.8 Blog Post — "Background Tasks" section — 2.8 introduced a dedicated Background Tasks section in settings showing what's running. A team-side signal that MA is already building toward greater system transparency — the in-app tray is a natural continuation of this direction.
Note: Direct community demand for this specific feature is thin in GitHub discussions — users haven't explicitly asked for OS notifications or release alerts, likely because they haven't connected MA to a platform that does this. This is an internally-shaped concept, not a community-surfaced request. Before investing, the recommendation is to further shape the notification concept, then engage @feedbacksquad on Discord (MA's opt-in community feedback group) for validation. If the community affirms the value, that de-risks the bet. The Apple Music now-playing notification pattern is strong prior art to reference in the pitch.
Scope & Boundaries
In scope
- Now-playing OS notification: when track changes and the MA desktop app is not in focus, push an OS-level notification with track name, artist, album art. Tap to bring MA into focus. (native desktop apps in development for macOS and Linux)
- Artist release alerts: when a favourited artist releases new content, notify the user — opt-in per artist or globally
- In-app notification tray: post-upgrade "what's new" on first launch after a version bump; system alerts (e.g. provider auth issues); one-off tutorial nudges for newly shipped features
- Notification preferences: per-type toggles — users control what they receive and at what frequency
- OS notification delivery via the native desktop client (in development); mobile delivery to follow when the mobile app ships
Not in scope
- Active player state visibility within the app (covered by #63)
- Push notifications to mobile (no mobile client yet)
- HA automation triggers from MA notifications
- Concert alerts (possible follow-on once release alert infrastructure exists)
Foreseen solution
- Build notification infrastructure with types: now-playing, release-alert, system, info, tutorial
- Desktop client integration: hook into OS notification APIs (macOS/Linux) to deliver now-playing and release-alert types
- In-app notification tray (bell icon in header) for all notification types; dismissable, with a notification log
- Release alert subscription: favouriting an artist opts the user in to release alerts — configurable in notification preferences
- Notification preferences panel: per-type toggles and frequency controls
- Post-upgrade hook: on first launch after a version bump, show a "what's new" in-app notification linking to relevant UI areas
Risks & open questions
- Release alert data source: what API provides new release data? Streaming providers? MusicBrainz? Last.fm? Needs a decision before building.
- Desktop client coverage: notifications require the client to be installed and running. How do we set expectations for users without it?
- Notification fatigue: prolific artists release frequently (singles, remixes). How do we avoid noise? Need controls for release type (album only vs. all releases).
- Mobile delivery timeline: architecture should be designed from day one to support mobile push once clients exist.
- In-app tray vs. OS notification: should users be able to choose per-type which channel they prefer?
Appetite
Medium. The in-app tray is smaller (Small on its own); OS notification integration with the desktop client adds meaningful scope. Can be phased: tray first, OS notifications second.
Execution issues
No response
Decision log
| Date |
Decision |
Outcome |
| 2026-06-05 |
Notifications should be positionable in the UI (not just a drawer) |
Agreed |
| 2026-06-23 |
Published to GitHub |
#206 |
| 2026-06-23 |
Popup signal (#4536) removed — popup is active player state, not notifications |
Marcel's feedback — covered by #63 |
| 2026-06-23 |
#1279 (Announcements) removed — unrelated feature, stale thread |
Marcel's feedback |
| 2026-06-23 |
Scope expanded to include OS now-playing notifications and release alerts |
Carl's direction — native apps in development |
Opportunity: Notification System
MA 2.10 — Synthesized from Marvin/Carl meeting notes, June 5 2026
Problem statement
When MA isn't in focus, it's silent. A great track comes on — no signal. A favourite artist drops an album — MA says nothing. Every major music platform solves this: Apple Music sends now-playing OS notifications when the app isn't in focus; Spotify pushes release alerts for followed artists. MA has no equivalent on either front.
Native desktop and mobile apps are in development, meaning OS-level notification delivery is achievable and not a distant future-state dependency. And with #63 addressing active player state visibility within the app, the scope here is clear: OS notifications for the moments when MA isn't in view; an in-app tray for system messages, feature discovery, and tutorial nudges.
MA's vision commits to conveying emotion — "we suggest what makes your home listening experience more personalized." A release alert for an artist you love is that pillar made concrete. It also supports effortless — "no documentation is needed for day-to-day usage" — by closing the gap between new features shipping and users actually finding them.
Community signals
Note: Direct community demand for this specific feature is thin in GitHub discussions — users haven't explicitly asked for OS notifications or release alerts, likely because they haven't connected MA to a platform that does this. This is an internally-shaped concept, not a community-surfaced request. Before investing, the recommendation is to further shape the notification concept, then engage @feedbacksquad on Discord (MA's opt-in community feedback group) for validation. If the community affirms the value, that de-risks the bet. The Apple Music now-playing notification pattern is strong prior art to reference in the pitch.
Scope & Boundaries
In scope
Not in scope
Foreseen solution
Risks & open questions
Appetite
Medium. The in-app tray is smaller (Small on its own); OS notification integration with the desktop client adds meaningful scope. Can be phased: tray first, OS notifications second.
Execution issues
No response
Decision log