Correct docs about permissions for Dropbox backend (and why not Google Drive?) about remotestorage.js HOT 4 OPEN

It's not the lack of a permissions model that's the problem, it's that Dropbox (and Google Drive) have permission models that conflict with the RS permissions model.

An RS scope can be accessed by more than one app (for example, the documents scope is accessed by both Litewrite and Notes Together). So, unfortunately, Dropbox App folder scope does not match the RS permissions model. So, while an app using remotestorage.js will only access files in the remotestorage subtree, there wasn't a way to request just that from the Dropbox API, when I last checked. Likewise for Google Drive, last I checked.

from remotestorage.js.

Yes, that's correct. You can either grant the app permission to write its own files, or you can have interoperable apps that access the same data.

See this current Webmarks issue for some more discussion and info regarding Google Drive. There's a scope where you can write to /remotestorage/category, but the app can only see documents that it created there itself.

It may make sense to switch rs.js to app folders entirely by default, and tell users that single-app access is the drawback compared to RS, especially for new apps where data migration to a different folder is not necessary.

from remotestorage.js.

It may make sense to switch rs.js to app folders entirely by default, and tell users that single-app access is the drawback compared to RS, especially for new apps where data migration to a different folder is not necessary.

Yeah! I just want Drive and Dropbox support so (a) users can try my feature without having to make a new account (with a company they haven't heard of), and (b) as a backup sync method. Both of those backends were slower than RS via 5apps --and I was intending on telling users that-- but they worked well enough for a try or for a backup method.

@DougReeder got you. Sharing data doesn't make sense for my application (which is adding a device sync feature to a web app that was designed only for local storage), for a few reasons, most importantly because nobody else would use it. There is probably some well-organized effort to make an interoperable data format for LLMs that I don't know about. Making an RS data module would make sense for them.

Back to my main suggestion. I probably told Dropbox that I want a "Scoped App (App Folder)" when I set it up. Looks like this in the main dropbox app settings page: Screenshot from 2024-04-06 15-52-01
but that would be the only possible difference between what I did and what the RS docs advise (permission scopes are the same: account_info.read, files.metadata.read, files.metadata.write, files.content.read, files.content.write). So it is very easy to set up Dropbox so that it gives a non-alarming consent screen like this:

I can't say the same for Google Drive. I tried patching remotestorage.js and fiddling with the google dev console settings for a couple hours, but couldn't get the consent screen to change.

from remotestorage.js.

With Google Drive, you'd have to change the scope to drive.file, both for your OAuth dialog in the Google Developer Console, as well as in rs.js.

from remotestorage.js.