Shared documents using remoteStorage remoteStorage is great for storing an individuals data, but granting shared access to single files in remoteStorage is complicated. Instead of making extensions to the existing remoteStorage model, I propose a new way to look at shared documents. Instead of seeing a shared document as a single file stored in one place, each author's contributions are stored separately in their own remoteStorage locker. The "shared document" then becomes a composite of these individual contributions, edited and viewed via a "framing" apparatus that draws together the complete document contents from the various storage locations. This approach provides authors with complete control over their own work, as it is not copied or stored anywhere other than their own remoteStorage locker. An author can modify, replace or remove their contributions at-will, with no concessions to contributors or "superuser" administrators. Additionally, if the composite document is unpublished or destroyed, all of it's original content is still available to the authors who created it, and can be re-assembled in its original form or re-published elsewhere. This also raises the possibility of creating composite documents *independent* of the authors themselves; drawing together resources from various locations into a composite frame. This is not unlike how the web can work already, but for the "security provisions" of cross-site-scripting (XSS) constraints enforced by existing web browsers. The primary issue with this approach is figuring out where the frame or template for the document resides, and how access control is managed. I believe that this requires some out-of-the-box thinking about what access control means when referring to a composite document, whose contents are owned and controlled independently by its authors. One possibility is that the "frame" file is stored by a single author in a public directory, and "access control" is performed by this author (let's call them an "editor", which is the closest thing I can think of using the traditional vernacular) by means of defining where the sources of content are. For example one possible implementation of this approach could be an html file which contains a script that loads the pages content from an array of URLs pointing to the source files for the document on the remoteStorage providers of the various authors. As each remote document is loaded, the script composites the contents on the page, like layers in Photoshop, resulting in the final rendered document. When an authenticated author views the composite document, editing controls are presented which convey changes *back to that author's source document only*. As changes are stored, other viewers can reload the array of sources and see the changes (this could be done manually or automatically, as a feature of the script, etc.). Of course there are many details to sort out, such as preserving layout in a meaningful way, indicating additions/subtractions or providing chronological "playback/rewind" controls to display the document over time but there are existing solutions to these problems. I also think the best answers will present themselves through using a primitive form of the system and making changes as experience increases. This approach could also be applied to other collaborative forms of media beyond writing, it's simply a matter of defining a compositing engine and source content format that can be meaningfully rendered from independent sources. Such a system provides the capability of collaborative tools like Google Docs or more traditional shared document systems while preserving the benefits to the individual afforded through remoteStorage and other Unhosted-style application architectures.
Fri May 01 2015