Most RS apps will automatically sync the data to the remote storage, when it's changed on your desktop. And when you then access it on your laptop, even in a different app than on the desktop maybe, it would sync whatever you changed down from the remote storage.
The main difference is that the app developer/provider doesn't have to see, secure, or pay for storing user data. Users themselves are in full control of their data, and they can permit any app to access segments of it. Check out this comparison on the RS website: https://remotestorage.io/#explainer-unhosted
I use my RS accounts for exactly this, in combination with Huginn for example. It's super simple, because you just PUT or GET, with the bearer token for one segment (called "category" in RS) in the Authorization header. And you can also PUT things in the special /public category, so they're world-readable. Example: when I check in on Swarm, Huginn uploads the entire check-in data to my RS for archiving, as well as updates a public RS document with my current location, which my website then shows publicly: https://sebastian.kip.pe
Actually, this has been pretty much a non-issue for us in production over the last 5 years. As the reference JS client library works offline first, it'll just sync data whenever the remote becomes available again. In fact, that's a nice bonus for offline-first web apps in general, not just with remoteStorage.
Tent's goals sound similar on the frontpage, but are actually very different. It's more of a communication protocol than a a data storage one. This page is slightly more informative, albeit not much: https://tent.io/about
Tent is built around posts. Each Tent server stores a single user’s posts and sends copies to the user’s subscribers.
That's why you can choose a storage provider to do it for you. But as with email, you're not locked in to a single provider, and small ones will probably not scan your personal data using AI/ML algorithms, like e.g. Google does.
Edit: the library in question also supports using Dropbox and Google Drive, so your users don't even have to know about RS in order to sync your PWA's data to their own account with those.
We'd be happy about any and all feedback and ideas about this specific topic. Our community forums are a good place for that: https://community.remotestorage.io
This is roughly how the library works. It will compare the directory listings with the cached items and only download new and updated ones, as well as remove deleted ones.
Yes, it is a key/value store as base technology. The important thing is that you can build anything you want on top, which includes for example indexes and such. The idea is that this can/will be implemented on top of a simple base protocol, which is easy to implement, and to use data modules (and shared utility modules) to add more complex functionality.
However, having used RS apps for years now, I think it's worth mentioning that most people considerably over-estimate the amount and size of the personal data they use daily, and in the case of notes, I never had performance issues with Litewrite pulling all my notes whenever/wherever I connect my storage: https://litewrite.net/
That's not just because this is actually pretty fast with multiplexing on HTTP/2, but also because you usually don't connect and disconnect all the time on all your devices. So you will usually have your existing data cached and available on app startup (including when you're offline), and only sync remote changes when you get online. This is also what similar proprietary apps like e.g. Google Keep do.
> Of course, no server is actually that dumb - even a file listing with file sizes can get you part of the way there. But if you've got 10000 files in a file store, that list can still get pretty heavy.
Exactly. remoteStorage has ETAGs in folder listings for that. The point is that you can implement a folder structure that enables you to update say just the last week of events plus upcoming ones, which is usually nowhere near 10000. Except with CalDAV you can't (according to the article, I haven't actually looked into it myself).
I didn't notice that JMAP includes calendars and contacts. Looks good!
Personally, I'd prefer a dumb storage with a generic API over yet another custom protocol/API just for these data formats alone. Worked great on people's local drives before the Web, and I think it should work similar on the Web.
Yes, and then you have another optional version of WebDAV, adding to the existing mess, while you don't actually have the benefit of interop that you say would be the reason for using WebDAV in the first place.
The way I read it, that's basically the point of the article.
(Co-founder of 5apps and RS core contributor here.)
> remoteStorage has as far as I know only one production instance running at 5apps
That's not true. 5apps is running the only public service for end users at the moment, but there are certainly more production instances running.
> The benefits of using the RS protocol are mostly due to the CORS headers (which could be implemented easily for WebDAV) and the use of OAuth/Bearer, for which a PR exists for SabreDAV [3].
As both of these would be optional additions to WebDAV servers, all of WebDAV's benefits parish with most servers not supporting these new extensions. That's the very critique in the article as far as I understand. WebDAV alone is not good enough, and optional additions lead to a world of incompatibility and pain.
> One thing missing from WebDAV is the (implicit) mapping of OAuth scopes to ACLs, which should not be too difficult to implement
And another addition.
> I'd prefer something like OAuth authorization server discovery
And another one. Counting 4 now. :)
> but it just doesn't bring (in my opinion) many benefits and loses interop with existing WebDAV clients for no good reason
You just mentioned that to get to feature parity with remoteStorage, a WebDAV server needs 4 optional additions, for only one of which an unmerged PR to a single server implementation exists. Maybe I miss something, but it doesn't sound like interop is WebDAV's benefit in this scenario.