I'm not suggesting this "because of Scratch". Users who have an OC can backpack it so that they don't have to draw it a lot of times.
Now, before you say "WdYm By bAcKpAcK", a backpack in Scratch is a location where you can put media and you will be able to easily add it to other projects.
I bet someome could male an indexedDB-powered library to store scripts and costumes. (That way, the cloud servers wouldn't get even more filled)
I know that this is a bit more challenging than just using a backpack, but here are the current workarounds (require saving to the computer):
Costumes:
Maybe the backpack could save in the browser (a feature Snap! used to have before cloud saving).
That's what I was saying about IndexedDB. :~)
Browser storage, I believe, is limited. We could save your most recent project in the browser, but not all your projects, for example. So a browser-hosted backpack would be limited in size. Also, if you log into Snap! on a different computer or browser, you wouldn't have access to your backpack.
We need a much better solution to the server storage problem, i.e., we need a much better solution to the money problem. This is a difficult time to be looking for funding, since the US government has decided to stop funding scientific research and so everyone is seeking private funding for things more important than Snap!. But we're trying.
Yes, it is indeed limited, however IndexedDB has a much higher limit than localstorage. Localstorage is limited to 10 MB, whereas indexedDB is a little more dependant ln the browser and total disk space. For firefox, it's either 10% of the total disk space or 8 TIB (whichever is smaller) (at least in persistant mode, aka, the user accepted it). Chrome is 60% of the total disk space. Safari allows 20% of the total disk space, but if you install the PWA, it's increased to 60%. You can read all about it here Storage quotas and eviction criteria - Web APIs | MDN
I think it's safe to say that indexedDB is limited, but it's limit is many GB, so it's not as limited as you're thinking.
Ah. I learn something every day.
It's still not a great solution for backpacks, because it doesn't follow you around. But I wonder if it wouldn't solve the Undo problem, by letting us save lots of snapshots while you're working. (Might still be too slow, but maybe we could invent incremental dumps.)
I think we really don't want to user browser storage for anything that's expected to be permanent. But an undo state is useful.
The backpack thing is not just cost - but the problems that potentially occur with storing more random data in the cloud, and the associated permissions and potential moderation needs.
Though, fwiw, this is only 5MB worth of "text" since LocalStorage uses UTF-16, it's really the equivalent of 5MB of text. And because base64 encoding of media has about 33% overhead, you really only get about 3.5MB of images or sounds.... this was why we needed to move away from it!
To be clear, for other larger data uses: IndexedDB is an option -- though when we started with browser storage it wasn't as robust as it is now. Still, aside from not following the user, it can get cleared automatically in some cases, like by school systems that "reset" account periodically for "safety" reasons (believing everything important is in the cloud...)
A lot of school districts wipe computers right after trying to restart nowadays when something goes wrong.
But if we used it for undo, that wouldn't matter so much; undo memory is really needed mostly during the same session in which you did the thing you want to undo.
(As Jens always reminds us, it's not 100% clear how undo should work in a natively parallel programing system such as Snap!. Since you did the user action you want to undo, lots of sprites other than the one you're editing have been whizzing around, dropping images on the stage, etc. Is all that undone too?)
But at least saving the information in the browser would eliminate the horrendous potential slowdown from constant cloud requests from every active user if we did undo in the cloud.
I used indexedDB for the file system on my web OS, but getting it working was so much work and pain. It is a lot more complicated to use than cookies or local storage
