31

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.

Improve this question
11
  • 1
    Or, just in case the storage is an issue (which I doubt it is, but maybe some legal issues?): some Stack Apps proxy towards popular third party services/APIs? Such as SpiderOak, Google Drive, SugarSync, Live Mesh, ...
    – Arjan
    Jun 23, 2012 at 13:07
  • How about introducing the system as invitation-based for the most popular 3rd party scripts?
    – Ambo100
    Jun 23, 2012 at 13:56
  • 2
    I've withdrawn my answer while I contemplate making a prototype to see how practical this actually might be.
    – Tim Stone
    Jun 23, 2012 at 17:18
  • 1
    @Discount, thanks for the hat-tip. FYI, I did discuss this with someone from the team (can't remember who, nor whether it was by mail, chat, or here somewhere on meta), who said (at that point) that it wasn't likely to happen any time soon... I did actually manage to put together a proof of concept of 'global storage' using local storage on a frame with stackauth.com, but that forced the user to install a second user script, and I got stuck trying to handle the asynchronicity...
    – Benjol
    Jul 2, 2012 at 6:44
  • @Benjol thanks for the info! Yeah, I guess this would be a big thing to implement. Maybe when SE hits the 300 employee mark :) That proof of concept looks very interesting.
    – Pekka
    Jul 2, 2012 at 6:50
  • 1
    Hey Pekka, up until recently, cross-domain localStorage would have been a cool option. I was going to setup a server on a free hosting provider and just use it to serve some JavaScript in an iframe that I could postMessage to in order to save data client-side, but across various sites. It appears SE recently locked down the site so no iframes can be embedded, so using localStorage via an iframe is no longer an option. This was known as xauth. Too bad SE disabled iframes, but if they could somehow embed one to stackauth.com on every SE site, you'd have synced localstorage for all SE sites.
    – jmort253
    Oct 28, 2012 at 8:08
  • @Benjol, have you tested your proof of concept recently? SE recently set a header that blocks all iframes on SE sites, which means one cannot embed something like stackauth.com anymore. I was going to use postMessage to store data common to all SE sites in localStorage, but it looks like that is no longer an option.
    – jmort253
    Oct 28, 2012 at 8:15
  • @jmort253, I must admit that I haven't, I figured there wasn't much point as it didn't look likely I was going to get any help from SE (as indicated by the absence of any response to this question). I've now implemented using a pseudo-external data source anyway, so while it's not ideal, it does provide a sort-of fallback solution.
    – Benjol
    Oct 30, 2012 at 7:07
  • @Benjol - That's what I'm doing too. I was going to use 1freehosting.com, but they embed this analytics code in content generated by PHP. I don't mind if the content-type is text/html, but when you're trying to use text/javascript so your data can be consumed by cross-domain JavaScript, well... embedded analytics HTML code sort of trashes any hopes of doing that. Since I'm not going to pay for hosting, I'll probably just build an extension instead so I can store the data locally.
    – jmort253
    Oct 30, 2012 at 7:09
  • 2
    Okay, I'm back to being serious about making this happen, though obviously not as officially as you might have wanted. Give me 6-8 weeks (or at least a week or two).
    – Tim Stone
    Jun 25, 2013 at 16:12
  • 2
    @TimStone: You've had just over a year now. Any progress or anti-progress?
    – Jeffrey Bosboom
    Jun 28, 2014 at 1:10

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .