[Spotify] Followed playlists unplayable for users with post-Nov-2024 Spotify Developer apps — adopt the ncspot/spotify-player fallback `client_id` pattern?

[abguymon]

Summary

If you create a fresh Spotify Developer app today and plug it into [spotify] client_id = ..., you can't list or play tracks for any followed playlist. PR #94 papered over this by filtering followed playlists out, but the real cause is a Spotify policy change, not anything cliamp can fix at the per-playlist level.

This isn't really a bug report — more of a request for direction, since I'm happy to do the implementation. ncspot and spotify-player both sidestep this by shipping a fallback client_id baked into the binary, and I wanted to check if you'd be open to that pattern in cliamp before writing any code.

Root cause

Spotify's Nov 27, 2024 Web API changes clamped down on newly-created developer apps that don't have "extended quota mode." The blog post calls out algorithmic and Spotify-owned editorial playlists, but in practice the lockdown hits most followed playlists for any dev-mode app. The playlist-read-private and playlist-read-collaborative scopes don't help — this is enforced at the app-quota layer, not OAuth.

Apps that already had extended quota mode before the cutoff are fine. Getting it now means a written business-case submission, which isn't realistic for end users.

How other Spotify TUIs handle it

I checked the other terminal Spotify clients:

Tool	Status	Web API client_id strategy	Affected by Nov 2024 restrictions?
spotify-tui	Dormant since 2021	User-supplied	Yes (same as cliamp)
ncspot	Active	Hardcoded NCSPOT_CLIENT_ID = "d420a117a32841c2b3474932e49fb54b" (ncspot's own registered app)	No
spotify-player	Active (~6.6k⭐)	Borrows the same NCSPOT_CLIENT_ID as default (spotify_player/src/auth.rs:7, config/mod.rs:297)	No
spogo	Active	None — imported browser cookies + Spotify's internal Pathfinder GraphQL	No (totally different architecture)

ncspot and spotify-player ship the same hardcoded client_id, registered to the ncspot project — predates the Nov 2024 cutoff and/or has extended quota. Users get full access with no developer-app setup at all. spotify-player makes it overridable: if you set your own client_id, yours wins; otherwise it falls back to the ncspot ID.

spogo is in a different category (cookie-based, internal GraphQL). Mentioning it for completeness, but I noticed cliamp dropped the equivalent spclient fallback in v1.43.0, so I'm guessing that route is already off the table.

Proposed direction

If the ncspot/spotify-player pattern is something you'd accept:

1. Bake a fallback client_id into external/spotify/. Two flavors:
   • Use the ncspot/spotify-player ID (d420a117…). Quick to land but means cliamp shares another project's rate-limit pool.
   • Register a new app for cliamp specifically and apply for extended quota. Cleaner long-term but it's on you (or whoever owns the project handle) to register and maintain it.
2. Prefer the user's [spotify] client_id if set; otherwise use the fallback.
3. Drop the playlistAccessible() filter in provider.go — the "Followed playlists" section is already wired up in Playlists(), it just has nothing to show today.
4. Update the docs so client_id is genuinely optional.

If you'd rather not go this route (don't want to ride on someone else's app, don't want to register a new one, etc.), that's totally fair — happy to close this with a note pointing people at ncspot/spotify-player/spogo, and leave the filter where it is.

Question

Would you accept a PR that adds a fallback client_id (either borrowed or cliamp-registered) and drops the followed-playlist filter? Or do you have a different direction in mind? Happy to do the implementation once you let me know.

[bjarneo]

Hey, I think you are on to something here. I am redoing Spotify, so I think I will add the code myself, but this was a really great issue!

[bjarneo]

The drawback is that this client ID is often rate-limited. Especially towards the /v1/me endpoint.

[bjarneo]

I need to give this some thought. I have an older client ID, though. Maybe I can use that client ID instead 🤔