Skip to content

JamRelay v1.2.0

Latest
Latest

Choose a tag to compare

View all tags
@makkiattooo makkiattooo released this 14 Sep 20:57
· 4 commits to main since this release
v1.2.0
525d22d

JamRelay v1.2.0

Multi-provider music automation, without making one provider the center of the system.

JamRelay v1.2.0 is the largest architectural release so far.
The project moves from a Spotify-first MCP server to a provider-neutral music automation platform with explicit provider connections, capability-aware operations, cross-provider playlist workflows, stronger authorization boundaries, and safer persistence.

✦ What changed

Area v1.2.0
Providers Spotify, SoundCloud, Apple Music, YouTube
Architecture Provider Registry + capability model
Connections Multiple provider connections with explicit targeting
Transfers Cross-provider playlist planning and execution
Identity Canonical tracks + provider-specific mappings
Security Owner sessions, CSRF, MCP grants, encrypted provider credentials
Persistence Provider-aware state, snapshots, rate limits, errors, history
Playlists Import/export, chapters, safer automation
Startup Zero-provider boot is supported
Health Provider-neutral server health semantics

Multi-provider foundation

JamRelay is no longer architecturally tied to Spotify.

The new provider layer introduces:

  • Provider Registry
  • explicit provider connections
  • stable connection IDs
  • capability discovery
  • multiple connections per provider
  • provider-aware reads and writes
  • canonical track identities
  • provider-specific mappings

Write operations now fail closed when the destination is missing or ambiguous instead of silently selecting another provider.

A JamRelay instance can also boot and remain healthy with zero configured music providers.

Provider support

Spotify

Spotify remains fully supported, but it now lives behind the same provider abstraction as the rest of the platform.

Supported areas include:

  • catalog access
  • playlists
  • library operations
  • playback
  • history-related workflows
  • playlist writes
  • provider-aware connection targeting

The canonical Spotify callback route is now:

/auth/providers/spotify/callback

Compatibility handling may still exist for the previous Spotify callback route where supported.

SoundCloud

Initial SoundCloud integration adds:

  • OAuth authentication
  • identity access
  • catalog operations
  • playlist operations

Capabilities are modeled explicitly, so JamRelay no longer assumes that every provider behaves like Spotify.

Apple Music

Apple Music uses a deliberately separate authentication model:

  • Developer Token
  • Media Services .p8 private key
  • Music User Token

JamRelay keeps server-side developer credentials separate from user authorization.

This avoids pretending Apple Music is just another Spotify-style OAuth provider.

YouTube

YouTube support uses the official YouTube Data API.

JamRelay treats YouTube playlists as collections of videos and does not present the integration as an unofficial YouTube Music API.

TIDAL

TIDAL remains feasibility-only.

There is currently no runtime TIDAL provider.

Cross-provider playlist transfers

JamRelay can now plan and execute playlist transfers across supported providers.

The transfer system includes:

  • source and destination connection selection
  • canonical track matching
  • provider-specific identity mapping
  • unresolved-track reporting
  • capability validation
  • execution planning
  • snapshots
  • rollback-aware safety

A playlist transfer is no longer treated as “copy these Spotify IDs somewhere else”.

Instead, JamRelay resolves a provider-neutral identity and maps it to the destination service.

Canonical resolution

v1.2.0 introduces a provider-neutral canonical resolver.

The same logical track can now be represented by:

  • one canonical identity
  • multiple provider-specific identities
  • persistent provider mappings

This architecture powers:

  • cross-provider transfers
  • provider-neutral import/export
  • safer playlist automation
  • connection-aware persistence
  • future provider integrations

Playlist import & export

Import/export is now provider-neutral.

JamRelay can preserve portable playlist metadata while retaining provider-specific identifiers where useful.

This makes playlists easier to:

  • move between services
  • inspect
  • archive
  • restore
  • reuse in automation workflows

Playlist chapters

Playlist chapters are now persisted as first-class state.

They allow large playlists to be divided into meaningful logical sections while keeping ordering and chapter metadata available across supported operations.

Playlist automation

Automation received a major safety pass.

Improvements include:

  • stronger integrity verification
  • provider-aware targeting
  • snapshots before mutation
  • rollback attempts
  • durable job integration
  • duration-based playlist extension
  • safer handling of destructive operations

The core rule remains simple:

JamRelay should know how to recover before it changes something important.

Connection Hub

JamRelay now includes an owner-facing control surface for provider and MCP access management.

It supports:

  • provider connections
  • connection status
  • preferred connection roles
  • authorized MCP clients
  • connection-scoped grants
  • system diagnostics
  • provider onboarding

The Connection Hub is operational tooling, not a replacement for the MCP interface.

Authentication boundaries

v1.2.0 separates three different trust boundaries that previously risked being conflated:

1. MCP authentication

Controls which MCP clients can access JamRelay.

2. Owner authentication

Controls administrative access to JamRelay itself.

3. Provider authentication

Controls access to Spotify, SoundCloud, Apple Music, YouTube, and future providers.

These are now intentionally independent.

MCP authorization

MCP clients can now be restricted to specific provider connections and permissions.

This introduces:

  • connection ACLs
  • explicit grants
  • read/write separation
  • provider-scoped access
  • safer destructive operations

Clients no longer implicitly gain access to every configured provider connection.

Provider-aware persistence

The database layer now understands providers and connections directly.

v1.2.0 adds migrations for:

  • provider-aware application state
  • provider-aware playlist snapshots
  • generic resolver attempts
  • connection-scoped rate limits
  • connection-scoped provider API errors
  • canonical listening history
  • playlist chapters

Historical migrations remain immutable.

Encrypted credential storage

The old Spotify-only token storage model has been replaced by a shared encrypted provider credential store.

The primary runtime path is now:

PROVIDER_CREDENTIAL_STORE_PATH

Provider credentials are stored per connection and encrypted at rest using the existing JamRelay credential protection model.

Security improvements

This release strengthens the trust model across the project.

Highlights include:

  • owner sessions
  • CSRF protection
  • MCP OAuth grants
  • connection-scoped permissions
  • encrypted provider credentials
  • fail-closed write targeting
  • stronger secret/token redaction
  • explicit provider authentication boundaries

Health & deployment

Provider connectivity is no longer treated as application health.

JamRelay may be fully healthy even when:

  • Spotify is disconnected
  • another provider is disconnected
  • no provider is configured

Health now reflects the state of the JamRelay server and its database instead of requiring one specific music service.

Breaking / behavioral changes

Please review these before upgrading:

  • Spotify is no longer required at startup.
  • Writes must resolve to an explicit or unique capable connection.
  • Spotify IDs are no longer treated as universal music identifiers.
  • Provider credentials now use the multi-provider credential store.
  • Provider auth routes are organized under /auth/providers/....
  • Provider capabilities are not assumed to be identical.
  • Zero-provider startup is a valid supported state.

Upgrade notes

Before upgrading:

  1. Back up the JamRelay database.
  2. Back up provider credentials.
  3. Back up MCP OAuth state.
  4. Keep your encryption and owner secrets safe.
  5. Update provider callback URLs where required.
  6. Run the full validation suite before deployment.

Startup applies new forward-only migrations automatically.

There is no automatic down migration.

For Spotify, the production callback should use:

https://mcp.jamrelay.com/auth/providers/spotify/callback

Known limitations

Some functionality still depends on live third-party provider behavior and credentials.

Notable limitations:

  • provider API quotas still apply
  • provider capability parity is not guaranteed
  • Apple Music requires its separate token model
  • third-party MCP client behavior may vary
  • TIDAL is not implemented

Release summary

JamRelay v1.2.0 turns the project into a real multi-provider foundation.

Spotify remains important, but it is no longer the architecture itself.

The new model gives JamRelay a cleaner path toward additional services, safer automation, cross-provider interoperability, and finer-grained client permissions without sacrificing self-hosting or explicit control.

Full Changelog:
v1.1.0...v1.2.0

Assets 2
Loading