- Review to check that the plugin is reasonable quality/isn't malicious.
- hosting (e.g. the plugin is retrieved from a repo. you control) or "known good" checksums so pi will only download the plugin with a version that you've reviewed.
From a security/supply chain aspect, ironically what you're looking to do is deliberately add some friction to the publishing process, which sounds bad, but can be quite effective at mitigating attacks. Most of the recent supply chain attacks get found by automated scanners in < 24 hours, so having a review process for new releases that takes a while will reduce the number that affect users.
I think having this is handy as it'll give security conscious users more confidence in using pi, without the anxiety of pulling a load of additional code from effectively random sources.
That said, sometimes it is really easy to leverage existing extensions. You run the risk of supply chain attack though. I installed one extension that was useful, modified it to my needs and pinned it.
How many people genuinely know what they're doing when the value prop of Pi is basically to vibe code it to your taste? The entire point of vibe coding being that you don't actually have to know what you're doing?
It took time to learn all of these before I managed to do something similarly useful as OpenCode, and now I am ready to use some sane defaults for things that I really know I need in Pi.
You don't _need_ to use someone else's plugin if you don't want to, and for simple functionality, you can get pretty good resulting rolling your own.