I think there’s been some frustration on both sides, and some arguing at cross purposes. I apologise for my part in it, and will try to make my position clearer.
The feeling I got from your posts is that you are frustrated that an API hasn’t been implement yet, and I felt you were somewhat dismissive of the security concerns I (perhaps ineloquently) raised.
This in turn frustrated me, as I think security is important in the context of shared decks, due to user expectations. You’ve implied exposing these APIs would not be a significant change in security, but I think that’s incorrect. The majority of Anki’s private web APIs are blocked to the reviewer, to prevent this kind of abuse. That’s a fairly recent development, after demonstrated exploits were revealed. There have been some more since then, which have also been fixed. I want to see us tightening up this area further, not loosening it, as shared decks have always been intended to be safe to download.
We’re able to block the majority of APIs currently, because the reviewer itself doesn’t use them. I fear that with a public API, and a JS add-on running in the reviewer context, we won’t be able to keep them separate without something like an iframe, or moving the add-on into its own context.
A security-conscious solution is of course going to be more work than just exposing the methods without any protection, but I’m afraid I think it’s important in this case. I don’t think we’re going to make any progress debating that point further, but discussions on how exactly we could implement this securely would be welcome, and would be a step forward. If you or another developer is interested, a GitHub issue is probably the best place.