This page was moved from the old wiki and is in the process of being revised.
The remoteStorage protocol is a creative combination of existing protocols and standards (mainly HTTP, CORS, Webfinger, OAuth 2). It aims to re-use existing technologies as much as possible, adding just a small layer of standardization on top to facilitate its usage for per-user storage with simple permissions and offline-capable data sync. See this quick explainer for some more info, and the spec itself for details.
Contents
[hide]
History
The first draft of the remoteStorage protocol was originally developed by Michiel B. de Jong as part of the Unhosted project in 2011 and has been published at a W3C Community Group, which has since been deprecated. Since December 2012, the protocol specification drafts are published as Internet Drafts at the IETF.
Process
Every 6 months (max. 185 days) a new draft version is published, incorporating feedback and contributions from developers, providers and users. All discussion and spec development is done in open collaboration on the public GitHub repository. Everyone is invited to open new GitHub issues and/or pull requests with their questions, feedback, and changes.
Versioning
Authors of remoteStorage-enabled apps are encouraged to use a recent version of remotestorage.js, which aims to support each new spec version on the day it is released, at the latest.
Implementers of remoteStorage servers and clients are encouraged to always offer support for the latest three versions of the spec.
Storage providers should aim to expose the previous version of this spec, so that app authors have six months to update their apps before they become potentially incompatible.
The latest three versions can be thought of as new, live, and old. When for instance version 03 was published, version 02 moved from new to live, and version 01 moved from live to old. So during the six months after version k is published, apps should add support for the new version k, while still supporting live version k-1 and old version k-2. Storage providers should aim to switch from old version k-2 to live version k-1 as soon as possible after version k is released.
You can find various formats of all draft content in the IETF version tracker.
Current versions
Deprecated versions
Please visit the IETF data tracker to access previous versions of the spec.
Useful resources
- MDN offers a great collection of articles on all aspects of HTTP, including caching and CORS.