There was a request recently about the immensely useful third-party comment script to be integrated into the SO core. The main reason for the request was that at the moment, the script's data can only be stored in local storage, as opposed to a centralized server-side location. If it were incorporated into SO proper, the engine could easily deal with that job.
The team won't incorporate the userscript, for reasons that I can totally accept. It makes sense having it as a third party tool that you need to actively install. However, this will likely mean that the script has no chance of evolving to the next level because there is no way to store data on server side.
Properly storing stuff on server side is not trivial, and too much to ask from a userscript author. You need proper hosting (which isn't free), secure authentication, secure storage, fallback solutions, scaling, a reasonable level of uptime and speed.... where third-party storage has been used by some Stack Apps, it has often been unreliable, leading to scripts and apps that eventually cease working. That is bad for the entire Stackapps ecosystem.
So how about Stack Exchange provide limited, user-based data storage for selected third party tools through its API?
- On a per-user basis; using the storage could be a privilege, say starting at 100 or 500 rep
- Very limited amounts of data, say in the kilobytes
- Heavily rate limited of course
- Apps and userscripts have to be manually approved by the team and get an app token (where applicable - you can't do that for client-side scripts of course)
I realize this not be completely trivial to implement, and would create a lot of questions on the engineering end as well as for community development. But it's worth at least thinking through: it would open a new dimension of awesomeness to the API, a whole new range of possibilities for scripts and apps working with it. They would finally have a "fire and forget" way to properly store user data.
The biggest possibility for abuse that I can see is that apps/scripts unrelated to SE/SO could use this to store their own state. But seeing as the storage is always bound to a SE/SO account with significant rep, and is heavily data and rate limited, I can't see how one could make large-scale misuse work in practice.
If you have other cases of concrete scripts or apps that would benefit from this, feel free to post them as an answer.