Original librespot author here.

Trying to pretend to be an official client was a game I never wanted to play. There's so many tiny differences in the way I've implemented the protocol it would be trivial for Spotify to notice this if they wanted to. It then becomes an whack a mole game between them and us.

Spotify is fully aware of librespot and has tolerated it so far. If they change their minds are try to block it it would be the end of the road for librespot. This is why, despite repeated requests from users, librespot has never supported free accounts nor downloading files in order to avoid pissing Spotify off. I always knew it would be trivial for anyone to implement this using the librespot source code, but it makes me a bit sad someone actually did it.

(That being said, I personally don't contribute or use librespot anymore, so really I don't care)

I wonder if this is somewhere it would make sense to use a non-free license which restricts how people use the code or what modifications they are allowed to redistribute. It wouldn’t stop anyone motivated from breaking the rules by themselves but it makes things like Oggify less likely to be distributed and so would mean librespot might be more likely to survive long-term.

This is the curse of open source - once you put the code out there, there's nothing you can do about it.

Currently dealing with this with a project of mine, it's hard to see people take and "abuse it", but there's nothing you can do really - licenses don't stop anyone.

wait, I don't think this allows free downloading. AFAIK, it only works with premium accounts. That was the whole intent for me at least.

Sorry these were meant as two separate points. People have asked repeatedly to use librespot on free accounts, and (other) people have asked to have librespot download files. I've pushed back on both, and Oggify does the later only.

(I work on Verona, originally as an intern at MSR, now as a PhD)

> It's interesting that building a self-hosting environment is a stated non-goal. Sounds like they are really focused on research and not building a production toolchain, but who knows?

The point isn't that the language will never be "production-ready" enough for it. It's that the language is intentionally limited in what kind of low-level hacks and concurrent mutation you can do, in order to remain safe. Writing this kind of code correctly is hard, and designing a language that exposes the full expressiveness in a sound and practical way is near impossible (at least given today's state of the art research).

The Verona runtime is therefore implemented in C++, which does have these capabilities. In some future it would nicer to formally verify the runtime for correctness, but that's a lot of work.

Reading through the GitHub repo, I see Rust, Cyclone, and Pony as idea sources, but I was surprised to not see Ada (https://en.wikipedia.org/wiki/Ada_(programming_language)) or SPARK (https://en.wikipedia.org/wiki/SPARK_(programming_language)). Both Ada and SPARK are mature, production-ready languages that have strong safety guarantees and concurrency built-in.

SPARK in particular might be worth looking at for another idea source depending on Project Verona's goals and needs.

Wow! Thanks for replying. That's a really good point. I'm looking forward to trying it. Cheers.

So it doesn't have any kind of `unsafe` escape hatch like Rust?

You may want to look at snmalloc, another allocator we did at Microsoft Research. It specifically targets these producer / consumer scenarios.

https://github.com/microsoft/snmalloc

And the paper, which I’ll be presenting tomorrow at ISMM: https://github.com/microsoft/snmalloc/blob/master/snmalloc.p...

I did this once, by writing a small C program which sets up the seccomp context before exec'ing the Go binary. Unfortunately Go's runtime makes a huge number of system calls in the background, and the whitelist kept growing.

Switched to Rust and there was only had one hidden system call left, getrandom used to initialize the hashmap