Request for Maintainers

[sashahilton00]

A thread for tracking requests to become a maintainer.

[awiouy]

I would agree to maintain librespot. Do not expect miracles, though.

[lufinkey]

I was planning on using this for a project of mine, so I will probably be open to contributing in the near future

[CodeCutterUK]

Although a little off topic, it might be good to share a vision of the librespot-org organisation, specially now there are three separate implementations of essentially the same functionality.

Personally I'm a fan of building amazing things once, rather than diverging on the basis of language. Thus, is it worth continuing to maintain the semi-abandon Rust implementation, when efforts might be better focused around the Java variant?

[lufinkey]

A C++ version would be most ideal, since almost all languages can bind to that. Although I think you can generate C++ headers from rust

[SafariMonkey]

@CodeCutterUK The Rust version and the Java version seem to have similar levels of code contribution, though the Java one seems to be basically maintained by one person. Is there any particular reason to pick the Java one over the Rust one? Rust doesn't need a VM/runtime, so I assume it could be used as a library from Java more easily than Java could be used from Rust.

I admit that I'm a little biased (I use ncspot which uses librespot) so I might be missing something.

[CodeCutterUK]

@SafariMonkey I guess recently the Rust version has lacked real contribution from a feature perspective, perhaps there is nothing more to add, but there are certainly bugs to work through.

Personally I'm with you that Rust seems to make a bunch more sense for a service like this compared to Java and the runtime bloat......that said, and as I've said before, better to do things once and well, than twice just because of language choices.

To be super clear, I really would like to see the Rust implementation live on :)

[devgianlu]

@SafariMonkey I am the main maintainer of the Java version and yes, I am the only one actively working on it, but the Rust version doesn't seem to have any contributor at all ATM. The Rust version also uses an old protocol which might be dropped one day (master on librespot-java uses the same protocol) and therefore I've done quite a lot of reverse engineering (@sashahilton00 and @ashthespy helped a lot in this) to get up-to-date with the newer clients. This new version (librespot-org/librespot-java#105) still has a quite a lot of bugs, but the protocol is pretty much done. It took me a few months and surely it would take less to migrate this into Rust, but I don't know anything about it and I'll keep on developing with Java.

I wouldn't have been able to start my project without help from the librespot guys, but I'm surely able to keep on going and fixing bugs. It's also unlikely that I'll leave this project as I am a student with plenty of free time as I won't go to university until the end of next year (having another developer would certainly help).

While I'm at it... Does anyone have a Spotify Connect enabled device and can capture some packets for me?

[HEnquist]

I didn't see the new branch of librespot-java (could have saved me some time) but I found a lot of json a few weeks ago when I looked at the data the desktop client receives. I have started updating the rust version:
https://github.com/HEnquist/librespot/tree/jsonmeta
It's far from complete but so far I have the new metadata api working for albums, artists, tracks a a few more things.

[willstott101]

I don't see any particular issue with the Java and Rust versions. The Rust version is much more versatile in terms of when, where, and within other programs that it's appropriate to be used. For that reason I'm very interested in trying to keep the Rust version alive and actively developed.

I think there's space and enough contributors for both versions to be actively maintained. Hopefully PRs to this Rust version will increase in frequency once we're able to work through the backlog.

I have neither the time nor expertise to be any kind of leading light on this project, but I'm very happy to keep trying to contribute with what I can, and support any maintainer who is willing to step in.

[kingosticks]

I'm in the same boat as @willstott101 here. I still have an interest in a Python wrapper and creating a Gstreamer element built on librespot, for which Java is not suitable.

[ashthespy]

I can also chip in - but my days are getting shorter these days, so don't know how much time I can commit to implementing new features.

[mainrs]

I am actively maintaining spotifyd right now. I can chip in with some PRs too from time to time. It would be really nice though if there would be some section in the readme or a wiki entry where you guys describe in detail on how you reverse engineer the protocol exactly. Which tools/programs you use. What needs extra attention or if some patches/hacks are needed to get it properly working.
I am blind, sorry.

I don't see an issue on why the two versions shouldn't co-exist. They run under two completely different environments. An argument can be made for only developing the Rust version as, in theory, you could just use the dll generated in Java. I wouldn't do it though 😄

[HEnquist]

I'm also interested in contributing with a PR once in a while. I don't actually have a project that uses librespot, I'm just playing with it as a fun exercise in rust.
I'm quite new here so I might be mistaken, but my feeling is that things are moving a bit too carefully forward. It's of course good to be really sure that a PR isn't causing troubles, but it shouldn't be taken to the point where it stalls the entire project.

[kingosticks]

When the project has no release branch, nor any tests, and Spotify roles out their changes incrementally on a per-user basis, and you are reverse engineering those changes, you can't do much else but move slowly and carefully. Personally I don't think merging code that "works for me" is a good idea here. But maybe this is a bit off-topic in terms of finding a maintainer.

[willstott101]

I think momentum (even if we step on our toes a few times) helps keep developers interested. Maybe having a development branch is the best way to achieve that - specifically for protocol changes and additions. Definitely something for another thread.

However I'm in favour of @awiouy who seems to be the only person willing to take on commit permissions! Otherwise I've seen this recently https://users.rust-lang.org/t/twir-call-for-participation/4821/21 which might be a good place to reach out.

[HEnquist]

My thinking was that there are two main problems with the way it works now.

• Every merge has to be perfect since it goes straight to master. That means the maintainer has a big responsibility in making sure that every PR really is perfect before clicking the merge button. This takes time and energy. Loosening this up a bit could make it easier to find (and keep) a maintainer. The discussion on how to do that definitely belongs elsewhere.
• What willstott101 wrote. Other contributor's may lose interest if PRs take too long.

[lufinkey]

Could someone set up GitHub Sponsor on the repo? I would definitely be willing to contribute money to help this project stay alive.

[mainrs]

We would probably need a maintainer first :) But I generally am a supporter of IssueHunt, Gitcoin and co. Adding smaller bounties to issues would probably get the attention of a lof more people :) And the great hacktoberfest is on it's way IIRC, meaning that IssueHunt themselves fund issues :)

I am currently maintaining spotifyd, a daemon for spotify. I will, on the long run, start contributing to the project. But I have some problems setting up the "protocol investigation suite" ;)

[sashahilton00]

Apologies, have been busy the past couple of weeks.

There are a few good points raised in previous comments, here's my thoughts on them.

there are three separate implementations of essentially the same functionality.

This is something that I have been thinking about, and I'm not sure what the answer is. Whilst rust in theory is a good language choice for this, I think that part of the reason for lack of maintenance/updates to the project is that rust is a relatively new language, and thus there aren't so many people familiar with it (myself included) to the extent that regular contributions are forthcoming. Case in point, the handling of re-connections rewrite, which has been pending for a long time.
The Java repo is probably the most up to date/stable of the bunch, though as mentioned, Java has all of the runtime baggage associated with it, and is thus not a good choice for creating wrappers.
That leaves us with the Go repo. Whilst it is probably the least maintained, it may be that go is the right trade-off between performance and barriers to entry (ie. easier to contribute to than rust). I haven't looked into it too much, but I believe if one was set on it, it would be possible to create a wrapper using cgo, which could then be used in whatever language. However, that leads us on to the next point.

it might be good to share a vision of the librespot-org organisation.

Based on the past x years of maintaining librespot, a chunk of the issues have been at the audio output level, ie. pulseaudio et al(sa), which have required multiple patches which added nothing to the core functionality of the program. The plan was to split librespot and librespotd, with the latter being a daemon that ran at system boot or similar, and dealt with the audio output bloat, along with the bells and whistles features, eg. zeroconf, websockets api for control, etc. librespot would then be the core library, with the aim of being as stable as possible, whose job it was to handle interaction with spotify servers and return data and pcm. If this were to be done, the benefits of a wrapper for various languages are negligible, as it would be simpler to just control via something like a unix sockets or websocket api, whilst also avoiding detracting from development time to maintain wrappers.
Work on this has been done to a certain extent, as the functionality has been split out into crate like folders, which are pretty much ready to push to crates.io, paving the way for work to begin on librespotd. On a sidenote, librespotd would basically be spotifyd, so there may be potential for merging those two projects there if the spotifyd maintainer (@sirwindfield ?) is up for it, though that's something for the next maintainer to think about.

I'm quite new here so I might be mistaken, but my feeling is that things are moving a bit too carefully forward. It's of course good to be really sure that a PR isn't causing troubles, but it shouldn't be taken to the point where it stalls the entire project.

Spotify roles out their changes incrementally on a per-user basis, and you are reverse engineering those changes, you can't do much else but move slowly and carefully.

Every merge has to be perfect since it goes straight to master. That means the maintainer has a big responsibility in making sure that every PR really is perfect before clicking the merge button.

Other contributor's may lose interest if PRs take too long.

These quotes highlight one of the shortcomings in this project, especially in the past 6 months or so whilst I've been inattentive. The issue of balancing up the desire for quick merges whilst also maintaining code quality is somewhat challenging, and to be honest I should have spent a bit of time to finally set up versioning, get the packages pushed to crates.io, and split development into master for stable and development for day to day merging and testing. For whoever takes this over, I suggest that they prioritise this to some extent. I set up a crates.io account some time back, and have reserved the librespot package names, so once maintainer rights are handed over to whoever, they can get in contact with me and I'll transfer access to the account so they can manage versions and such. Hopefully with an ctive maintainer and the changes above, code quality can be mintained, and merge time can be dropped drastically from the couple of months it currently is to significantly less.

Could someone set up GitHub Sponsor on the repo?

I never thought of this tbh. It's always been a hobby for me, so I'll leave it up to the next maintainer to decide whether they wish to implement this.

It sounds like @awiouy is the only one who wants to maintain this currently, so if there are no objections I'd suggest he become the next maintainer. I'm sure if anyone else wants to assist him with it he'll welcome any efforts. Any objections?

[mainrs]

On a sidenote, librespotd would basically be spotifyd, so there may be potential for merging those two projects there if the spotifyd maintainer (@sirwindfield ?) is up for it, though that's something for the next maintainer to think about.

I generally like the idea of having the library and the liberspotd audio output separated. spotifyd is basically just a daemon wrapper using daemonize around the library. It offers some quality of life improvements such as config files and cli options as well as authentication over the system's keyring (password manager). Media button control support is available as well (although a little bit buggy right now). It looks like the only "thing missing" to be the librespotd daemon would be a websocket api server 😛
We do, however, only support Unix at the time. Windows should be possible with Windows services but I didn't dive much into it.

I am not the only maintainer of spotifyd and joined fairly recently. @simonpersson is the original author. But, in context of the vision that you described, a merge, in the long run, might be appropiate.

No objections at all against the new maintainer. I am pro development branch. It makes contributing way easier. We have the same problem over at spotifyd. Everything gets merged into master, versioning is kind of existing, but there is no real scheme to it. I started making some drastic changes to move towards those goals.

Edit: I would like to offer some help for now though. I started sorting and grouping the issues over at spotifyd using labels and creating projects for common issues. If the new/current maintainer is OK with it, I would love to do the same over here :)

[sashahilton00]

Ok guys, @awiouy is the new maintainer. Have added him as the maintainer of the librespot. @awiouy I'll message you via Gitter with some more info, best of luck :) I'll leave this issue open in case he wants to address anything said in this issue before closing it. I'll also keep an eye on the project and contribute if/when I get time to do so again.