You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
hi! i've recently done some work reversing spotify app workflows, and i think 've done a pretty good job with api-partner.spotify.com/pathfinder.
you can see code at my proj (https://github.com/pyrorhythm/libspot/tree/main/pathfinder), we could possibly integrate core logic into golibrespot, with some enhancements like fetching actual gql query hashes from web player and such
I'd happily do so! But the question is - how to integrate these APIs into existing codebase? Subset of them are already in this codebase, but in gRPC format. Should we introduce them as a separate lowest level package, or subpackage existing ones? If you'd look at my existing codebase and what Ive already implemented, we can come up with a solution that suits your vision of librespot
Oh sorry I've thought that this is a more global PR. But we still can take more reversed solutions from my libspot :) Will start working on a PR for pathfinder this week
My general stance is to reduce hand written code as much as possible: use Protobuf or OpenAPI where possible.
Unfortunately all of pathfinder was reversed by hand via MITM proxy bcs there is no Protobuf and/or OpenAPI handling the contract.
I've tried to reverse .asar coming with application, but no concrete schemas were found
My general stance is to reduce hand written code as much as possible: use Protobuf or OpenAPI where possible.
Unfortunately all of pathfinder was reversed by hand via MITM proxy bcs there is no Protobuf and/or OpenAPI handling the contract.
I've tried to reverse .asar coming with application, but no concrete schemas were found
You can still write an OpenAPI spec and then codegen from it. That way the source of truth is a YAML file instead of the code, and people can reuse it to codegen in their own language.
Activity
pyrorhythm commentedon May 25, 2026
also, i've reversed some restapi requests from spclient here too - https://github.com/pyrorhythm/libspot/tree/main/spc; could also use that as more stable option
devgianlu commentedon May 29, 2026
What is it used for?
pyrorhythm commentedon May 29, 2026
it's a gateway to graphQL service, exposing bulk search endpoints (search suggestions, top search and such)
pyrorhythm commentedon May 29, 2026
also it is used to return complete "Home" page structure
pyrorhythm commentedon Jun 3, 2026
so what do you think? if you want to, i can provide some examples and i would be happy to take this issue as a pull request :)
devgianlu commentedon Aug 2, 2026
Feel free to make a PR :)
pyrorhythm commentedon Aug 3, 2026
I'd happily do so! But the question is - how to integrate these APIs into existing codebase? Subset of them are already in this codebase, but in gRPC format. Should we introduce them as a separate lowest level package, or subpackage existing ones? If you'd look at my existing codebase and what Ive already implemented, we can come up with a solution that suits your vision of librespot
pyrorhythm commentedon Aug 3, 2026
Oh sorry I've thought that this is a more global PR. But we still can take more reversed solutions from my libspot :) Will start working on a PR for pathfinder this week
devgianlu commentedon Aug 3, 2026
My general stance is to reduce hand written code as much as possible: use Protobuf or OpenAPI where possible.
pyrorhythm commentedon Aug 3, 2026
Unfortunately all of pathfinder was reversed by hand via MITM proxy bcs there is no Protobuf and/or OpenAPI handling the contract.
I've tried to reverse .asar coming with application, but no concrete schemas were found
devgianlu commentedon Aug 3, 2026
You can still write an OpenAPI spec and then codegen from it. That way the source of truth is a YAML file instead of the code, and people can reuse it to codegen in their own language.