Yes, the MD is probably a good starting point. This definitely is mutable data, but it is also sacrificial data to some extent; a situation where you need a lot of capacity and performance and a lot of overwrites, but not for very long. The concept of a “_tmp folder” that I mentioned was from a user interface perspective. Anything uploaded or saved to the “/tmp” folder could be created as an MD with code you describe automatically, although this is probably an app level implementation. I’m not very clear on MD deletion though, I’ve read through the following but wasn’t sure if deleting an MD really frees up the storage resource in the network for someone else to use, or just removes one’s ability to reconstitute the data.
- (RFC 47 – MutableData - #3 by Qi_Ma - RFCs - Safe Dev Forum)
- (Mutable Data Caching - #3 by Traktion)
- (Public / Private Mutable Data)
- (Cost of Mutable Data)
It seems to me that for some use cases, MD might be too valuable or overkill. Selfishly (since my resources are small) I was also dreaming about some way to store large quantities of temporary data in vault RAM only (with maybe just a little bit of redundancy for stability requirements) via the caching mechanism at a much reduced cost, so more like a “safe ram”. It also seems like the extra complexity for a lower cost demi-PUT for temporary/sacrificial data might have “symbiotic” benefits for both the users and the network (lower put cost because it will entice the user to accumulate less junk). This line of reasoning mostly applies to future developments in a computation module that might focus more on speed rather than safety. Anyhow, this was just a brainstorm to throw a few daydreams out there. Sorry for hijacking the thread.