Once 0.10.0 has been released i’ll upstream some fixes which i already applied in export.5apps.com and import.5apps.com, and we can make sure all three backends (remoteStorage, GoogleDrive, Dropbox) work correctly in 0.10.1 or whatever is the next release (something which has been in the making since Adding Dropbox and GoogleDrive support to remotestorage.js in July 2013). Then we can make this public in our documentation and marketing material.
I think this is a good moment to rethink our project presentation from scratch. On remotestorage.io we want to present several inter-related products/things:
- Get started with writing unhosted web apps. It’s a big change in how you think about your app; most developer think “my app’s app data” instead of “my user’s user data”. Part of this is also done on unhosted.org, but it doesn’t hurt to spend a lot of attention space on this in the main remotestorage.io main page first text people read, and info graphic.
- Use remotestorage.js as a library that gives your app access to the user’s data (3 backends)
- Remotestorage.js is also pretty good at asynchronous synchronization, indispensible for any serious offline-first app. Who is our competition here, actually? PouchDB and Hoodie mainly? How good is Firebase at offline-first for instance?
- Get started! (starter-kit + screencast)
Redecentralizing the web
- Our remoteStorage spec is the only contender we are aware of to standardize per-user storage on the web.
- Please join the spec discussion on github or at IETF apps-discuss.
- Proprietary interfaces to user data should at least implement CORS headers (GoogleDrive and Dropbox do this and our library supports them; we talked to tahoe-lafs and ownCloud about it; everybody should - link to enable-cors.org maybe).
Set up your remoteStorage
- Providers; get an account.
- Server software and install instructions.
- Build your own server using our nodejs reference implementation.
- Or read the spec and do it yourself entirely.