(Apologies in advance for the long message, but I do believe I’m addressing many points without much repetition:)
in practice developers will likely continue to provide all binaries. With GitHub actions it’s not that hard, see Automatically build, compile and release SuperCollider plugins using Github Actions | Mads Kjeldgaard. (Personally, I’m using the CI system of my ex-university.)
IMO developer-provided binaries brings us from a good security model to the problems of Windows shareware decades ago. Github Actions could be a step in the right direction (more on that below).
The key point, to me, is that you can’t both have:
- Binary distribution
- An “open world” with no (or minimal) core UGens
Of course you can! Pd is living proof of it.
Pd is living proof of what? Can you provide more information here about how Pd handles security? All I’ve heard so far is that:
- Anyone in the world can upload multiple binaries,
- which cannot reasonably be inspected,
- are different for every OS and CPU architecture,
- which are downloaded and run on a user’s computer unsandboxed,
- with full user privileges,
- which have so far not been caught doing anything malicious,
- that you’ve personally heard about
Which of these points are wrong?
(I’m assuming the binary distribution is at least immutable, i.e. everyone requesting a plugin for an OS+arch pair gets the same binary, but is this actually true?)
What you can’t have is perfect security. Most users just don’t care.
What I’m proposing is not perfect security: there’s plenty of surface area for a motivated attacker.
What I’m proposing instead is basic security: can we at all say what the binaries we’re running are doing?
I don’t agree that most users don’t care, and further I think most of the ones who don’t care would care if they had the decision explained to them.
Most users exist in a tranquil multi-decade tradition of chain of custody that you’re proposing breaking.
“Install this plugin” on a random github page: it’s the problems of shareware all over again.
But that’s already the status quo!
The status quo is “here’s my C++, feel free to inspect it and compile it”
What you’re proposing is “click this button to run my binary on your computer”
You did not provide any solution for the issue of distribution and discoverability.
My vision would be that, similar to today:
- SC (the inner core) is for everyone and proud of it
- The “outer core,” be it
sc3-plugins or something new, is for power users who are willing to live with some rough edges
- The open internet it for the avant-garde, people who want to try bleeding-edge stuff and can either read the code, know the developer, or want to live dangerously
A person who just wants to try SC should be using #1, and if they outgrow it maybe experiment with #2. It would be a huge misfeature to make unsophisticated users wade through possibly incomplete, buggy or worse plugins.
Where do you expect to find this group of maintainers? We barely have enough maintainers to maintain SC itself. IMO it makes more sense for each author to take care of their own plugins.
For any of the work we’re discussing, your solution or mine, motivated people would need to step up.
Without peoples’ labor, we’re stuck with the status quo.
I think we’re discussing what direction motivated people might want to move in.
(Also, writing a multi-platform binary package manager with decentralized discoverability seems like a lot more work to me, personally)
There’s a process for a plugin author to (try to) get their plugin added to this outer core
There is a limit on how big such a monorepo can grow before it becomes completely unmaintainable.
Is that true? And if it is, like Scott, I’d be glad to have that problem. If so many people start developing high-quality plugins that it becomes too much to handle, we could certainly split from one repo to different repos for instruments, reverbs, etc.
But it’s true that the “outer core” doesn’t need to be a monorepo. It could even consist of git submodules so plugin developers can work in their own repos (assuming they use git). The point is that it’s audited by trusted members of the developer team.
sc3plugins is already frozen. There have been quite a few new UGen plugins in the last few years but none of them have been added to sc3plugins.
Right, we both agree the status quo is stagnant. My proposal is to allow the “outer core” to be revitalized, including ripping out any old stuff that’s too much of a maintenance burden.
I think the authors (including myself) have not even tried because the development model just isn’t attractive. I want to work on my plugins on my own pace and not coordinate releases with dozens of other plugin authors.
This is an important point: development needs to be easy for authors. I don’t think my proposal prevents that, though.
That being said, a set of trusted community-vetted plugins would still be a good idea, but this can be provided as some sort of “meta-quark”. The individual plugins could be built with SC’s CI pipeline and hosted on the SC website (just as they currently are).
Building with a trusted open-source CI pipeline, with all files coming from VCS, with automatic uploads to a central trusted host, would be a big improvement to your proposal as long as chain of custody remained unbroken. That to me sounds a lot like sc3-plugins today, though. I don’t know how it would work without what I’m calling an “outer core,” some kind of vetting.