I completely understand what you mean, and I’m very aware that injecting JavaScript into the main code path can also be abused by malicious actors.
Flexibility and customisability are arguably SilverBullet’s strongest features. If that flexibility is heavily restricted, you also tie people’s hands when it comes to building tools that are genuinely useful to themselves or to the wider community. There will always be some surface area to circumvent security, and people will find ways to do so, whether they are acting in good or bad faith. Adding hard limitations may reduce risk, but it will also significantly clip the wings of people who are pushing the platform forward.
We already touched earlier on the idea that the library manager itself could help here, for example by introducing warnings and trust levels. This could be applied to developer repository or per individual library. A simple “Low Risk / Medium Risk / High Risk” badge based on static analysis or heuristics might already go a long way. I don’t know how feasible this would be to implement, but perhaps something like @malys’s Risk Audit library could be used as a building block or automation layer.
From my perspective, there are a few broad approaches:
-
Maximum security. Strictly limit what code can execute. This reduces risk, but also drastically reduces user flexibility. Given that flexibility is one of SilverBullet’s core strengths, this could easily turn people away.
-
Maximum freedom. Let people do whatever they want. This is risky, but it keeps flexibility essentially unlimited, and allows features to exist far beyond what the core code alone can realistically support.
-
Move advanced features into the core. Build commonly requested functionality directly into SilverBullet so people don’t need to rely on “escape hatches”. The Filter & Sorting library is a good example: if this were part of the core, people wouldn’t spend time implementing it themselves. That said, this approach is extremely resource-intensive, and it’s impossible to satisfy everyone. There will always be someone who needs a slightly different feature.
-
A hybrid model. Keep the escape hatches, but make their risk explicit. Combine documentation, tooling, and trust signals so users can make informed decisions about what they install and run, rather than trying to eliminate risk entirely.
In the end, I don’t think there’s a perfect solution. It’s a trade-off between safety, flexibility, and maintainability, and SilverBullet’s current design clearly leans toward empowering users who know what they’re doing.