@Christoph-Hart well true, that's why encoding everything would be a good idea. You can also sanitize it for dangerous functions like that.
I tested it, you can dynamically add components in on init.
So you could theoretically keep the entire plugin online and have it rebuild itself on init for a true "live service" audio experience, though that is an incredibly niche idea for an industry where the ability to reproduce consistency is key.
But if you're working on an open source plugin, you can have it pull your scripts one by one from github, so it's always fresh.
Then you can choose to be on the master branch or choose any of the commits. For important projects, you could lock it to a certain version so that it always inits to that version. Github has 5000 requests per file per IP rate limit according to online sources. So it's more or less enough. Closed source becomes problematic and you'll have to rely on your server.
Imagine a software that evolves daily or biweekly. And if you have 3-4 plugins like that. AI related or whatever, something that moves at breakneck speeds. How annoying would it be to have to download 5 installers every other day without being able to keep track of versions between projects.
I definitely don't think this is something 99% of projects need but it opens a door to something truly next gen.
Plus, it lets you offload the authentication functionality to the server for those who need copy protection. Then you can only crack it by debugging in the memory or whatever, I'm not sure who the hell would still bother with that in this day and age. I'm suspecting most plugins are cracked by scripts because they use the same JUCE copy protection methods.
But this is a bit questionable right now because as I wrote in my example, eval currently does not work inside of a server callback.
