bypass shitify

[s-b-repo]

Is there an existing issue for this? (Please read the description)

• [x] I have searched the existing issues

Current Behavior

#bypass cringe .exe make community hosted apis which fetch from spotify that then servers to spotube so now you dont use there api

just make own custom parsing format so its not directly the same from there api so the fat loser cant cry about there pennies

i can host the code for the apis so these clown will have to sent a cease to men in south africa good luck clowns

xneelo is cheap african hositng

Proposing project modifications

To resolve the legal issue, the user should consider removing Spotify API usage entirely. They could refactor the code to decouple Spotify-specific modules and create a plugin architecture for users to implement external modules. The project could integrate non-Spotify services like YouTube Music, JioSaavn, or MusicBrainz for metadata. Plugins could allow Spotify features at the user’s own risk, but they must remove all Spotify trademarks, logos, and references. The UI should be rebranded and allow manual imports and scanning of files, with code changes to handle plugins and metadata sources.

Thought for 11 seconds

Here’s a roadmap for refactoring Spotube so that it fully removes any official Spotify API integration, avoids trademark infringement, and gives you a clean plugin-based architecture that you can safely distribute:

---

1. Audit & Strip Out All Spotify API Dependencies

1. Cargo.toml & dependencies

   • Remove any crates like rspotify, spotify‐api, or similar.
   • Remove any Spotify‐related feature flags (e.g. features = ["spotify"]).

2. Code

   • Search for every import or call to Spotify endpoints (/v1/tracks, /v1/playlists, /v1/me, etc.) and delete or comment out those modules.
   • Remove all UI entry points for “Login with Spotify” or any Spotify-branded dialogs.

3. Assets & Branding

   • Delete or replace the Spotify™ logo and any mention of Spotify in your README, website, and in-app credits.
   • Update your brand text: e.g. “Music Provider” instead of “Spotify”.

---

2. Introduce a Plugin Interface for Music Providers

Define a minimal trait that any provider plugin must implement. For example, in Rust:

pub struct Track {
    pub id: String,
    pub title: String,
    pub artist: String,
    pub stream_url: String,
    // …any other metadata you need
}

#[async_trait::async_trait]
pub trait MusicProvider: Send + Sync {
    /// Search for tracks/artists by keyword
    async fn search(&self, query: &str) -> eyre::Result<Vec<Track>>;

    /// Given a track ID, return a URL you can stream/download
    async fn get_stream_url(&self, track_id: &str) -> eyre::Result<String>;

    /// Optionally, allow users to authenticate (e.g. OAuth2) if needed
    async fn authenticate(&mut self) -> eyre::Result<()>;
}

• Default Built-ins:

  • YouTubeProvider (using [youtube-dl](https://github.com/ytdl-org/youtube-dl) or [yt-dlp](https://github.com/yt-dlp/yt-dlp))
  • PipedProvider (Piped.video’s public instance)
  • JioSaavnProvider (unofficial Saavn API)

• Plugin loading Use [libloading](https://docs.rs/libloading) or a folder-based discovery (each plugin is a separate binary/crate that implements MusicProvider and registers itself via a manifest file).

---

3. Refactor Your App to Use Only the Plugin API

1. Initialization

   • Scan a /plugins folder for dynamic libraries (or a plugins.toml listing available providers).
   • Load each plugin, call its authenticate() (if needed), and keep a map of "YouTube" → Box<dyn MusicProvider>.

2. UI Changes

   • Replace the “Spotify” tab with a “Providers” dropdown listing each loaded plugin.
   • When the user selects “YouTube” or “Saavn,” bind your search bar and player to that provider’s implementation.

3. Configuration

   • Remove any client_id/client_secret fields for Spotify in your config file.
   • Optionally allow advanced users to drop their own Spotify plugin (at their own risk), but never ship it officially.

---

4. Migrate Your Metadata & Artwork Sources

Since you can no longer pull track metadata (album art, release date, etc.) from Spotify:

• MusicBrainz: open, no-strings API for metadata.
• Discogs: public API for labels, release info.
• Last.fm: scrobble API for album art (requires API key, but doesn’t carry Spotify’s restrictions).
• iTunes Search API: freely available metadata and artwork.

Wrap these in lightweight “metadata providers” that your UI can query in parallel with the streaming provider.

---

5. Update Documentation & Legal Notices

• README / Website:

  • Clearly state “Spotube no longer integrates with Spotify™ APIs.”
  • Explain your plugin model and link to docs on how to write a third-party Spotify plugin (if they’re bold enough to do so at their own legal risk).

• Terms of Service:

  • Emphasize that Spotube itself ships no Spotify API code.
  • Users must not distribute any Spotify plugin in your official binaries.

---

6. Example: Removing Spotify and Adding YouTube

1. Before (pseudocode)

   let client = rspotify::ClientCreds::new(&id, &secret).await?;
   let sp_track = client.track(id).await?;    // 🔥 Forbidden
   

   // Dynamically load the “youtube” plugin let youtube = providers.get("youtube").unwrap(); let results = youtube.search("Nirvana Smells Like Teen Spirit").await?; let stream_url = youtube.get_stream_url(&results[0].id).await?; player.play(&stream_url).await?;

---

Next Steps

1. Prototyping

   • Build one plugin (e.g. YouTube via yt-dlp) to prove out the interface.
   • Migrate one screen in your UI.

2. Complete Removal

   • Wipe out Spotify modules once the plugin path is stable.
   • Test that no rspotify symbols remain in your binary (ldd or nm).

3. Release & Communicate

   • Publish the “Spotube vNext” announcement with clear upgrade instructions.
   • Provide a migration guide: “If you used Spotify, here’s how to get your tracks into Spotube via metadata plugins.”

This approach lets you continue shipping a legally safe, trademark-clean Spotube—powered by community-driven plugins and open metadata—while avoiding any official Spotify API calls or branding in your distributed code.

Expected Behavior

shitify not being so shitty

Steps to reproduce

No response

Logs

Logs

<Replace this line by pasting your logs here>

Operating System

all

Spotube version

all

Installation source

GitHub Releases (Binary)

Additional information

No response

Self grab

• [ ] I'm ready to work on this issue!

[s-b-repo]

https://github.com/s-b-repo/shitify/tree/main here is my api with docs still putting it toghter but should be working in like 2 days maybe less will start hosting

[KRTirtho]

I am actually working on a separate branch removing spotify and making the app more extensible through plugins (code-greedy-green-corp-removal branch) Currently, planning to use JS based plugins through the flutter_js package which uses QucikJS under the hood.

[s-b-repo]

ah ok so we wont be able to sync our song anymore

[colonelpopcorn]

One of the metadata providers talked about in previous threads (MusicBrainz). Could we use the collections feature there to export playlists and liked songs? Then each metadata provider can implement spotify-like behavior with likes and adding to playlists.

[s-b-repo]

could work or we can make users browser download that info not spotify or us

[Bowarc]

We would also need a fixed protocol for all the metadata providers to follow. Or have Spotube do the translation ? that seems bad imo

[bloomresearch]

Random thought as I was perusing this issue thread - Why couldn't a more ghost browser automation approach be taken to the api? Even as a developer, one of the things I loved about Spotube was the ease of setup. No need to download and setup anything extra. It would seem to me that this same functionality could be achieved, by creating a generalized automated scraper that extracts song and artist information for multiple popular music hosting/collection websites. In this way, it wouldn't be specific to spotify and thus would seem to avoid the risk of any sort of legal ramifications. The user could simply add the link to the profile they wanted to track, and it would load their playlists. The only obvious caveat here being that they would have to make any playlists they wanted to track, public. You could then incorporate updates either via a manual button/pulling down the page, or automatically when a playlist or the app is loaded.

From here it would just be a matter of matching the extracted information to a public music database api, storing it, and then finding the track on Youtube or other download sources with the closest length and metadata.

Now, without any login automation, this would obviously miss the functionality of being able to modify the connected/tracked profile, but it would allow for a lot more instantaneous/easy functionality without having to download/incorporate anything extra, making it generalize better for anyone that might find that kind of thing a roadblock (i.e. less technically minded users). And you could still incorporate your plugin framework, letting people add that functionality if they were so inclined.

[GoldenReverie]

I am actually working on a separate branch removing spotify and making the app more extensible through plugins (code-greedy-green-corp-removal branch) Currently, planning to use JS based plugins through the flutter_js package which uses QucikJS under the hood.

This is a great steer, can't complain about using spotifiy api if it's open season with no interventions.

[saisua]

Maybe not now but in the future there could be a simple first-line custom recommendation system.

During compilation it could be created a read-only small db with all tags, embeddings for tags, genres, embeddings for genres, top hits for all time for each genre and the latest released songs (not the audio) for each genre (I'm talking a few mb in total for the db at most). Then the app could, based on the songs the user has been listening, learn to fit an Incremental Non-negative Matrix Factorization that could provide offline recommendations for genres and combinations.

Not sure if the plugins would provide the recommendations, but in case they don't this would be an alternative, and this way it could also be provided recommendations for cached archives when offline.

The incremental fitting of the algorithm could be done in a separate thread based on a queue of the user interactions, and the recommender would sync with the thread every search or other. This would also imply having in memory a few matrices and vectors, but I wouldn't expect the RAM usage to be too great

[KRTirtho]

The original plan was to use JavaScript based plugins but that was extremely buggy and hard to work with. So we went with hetu_script a Dart dialect scripting language. You can find the docs here: https://spotube.krtirtho.dev/docs/developing-plugins/introduction/

I'll be closing this issue as we've bypassed shittify