The lack of any kind of in-game persistence results in all kinds of inefficient and unreliable workaround. Any script that wants to reliably persist data has to have an outside web site associated with it and do the storage and retrieval via HTTP. I propose the following: llObjectStoreData(string tag, string value) string llObjectFetchData(string tag) llUserStoreData(string tag, string value) string llUserFetchData(string tag) llAuthorStoreData(string tag, string value) string llAuthorFetchData(string tag) Both store calls would work the same way, as a map a la Java. They would persist a string value associated with a string tag. In the case of llObjectStoreData, the data would be specific to the UUID of the containing prim. So in effect, the prim UUID and the tag would form a compound primary key. In the case of llUserStorageData, the data would be specific to the UUID of the prim owner. Thus, prim-specific storage, as well as user-common storage, would be available. The user-based calls would all for semaphore-like operations (one writer, many readers) among multiple unlinked objects. The Author calls would work the same as the User calls, but would key on the UUID of the script author, allowing a purchased object to report back to the author, or receive status updates easily (new version available, for example) This also would allow for broadcast-like capabilities, which one object could serve as a data collector via, for example, an HTTP request, and then the client objects could query the author-common data to get their updates, rather than all making HTTP requests. The storage could be limited, for example 1K per object and 10K per user/author.