I think showing the folder names during auth is not very user-friendly, especially if one has to consider localization. For example, if a German user uses a calendar app, the app requesting the contacts scope on the remoteStorage means little to him, since he doesn’t necessarily speak english very well. Even for an english-speaking user, “contacts” is a bit non-descriptive.
I’m not sure how a solution would look like, but I think we need one:
The server could list other apps that have access to the same scope, and say something like “Access data from $APPNAME”.
A special file inside the folder could be used to provider a user-friendly description of that scope. For example, an app could write “Kontakte” into that file for German-speaking users.
I like that idea for server UI. I think it’s useful information on the auth screen.
A couple of issues with that:
An app can only write something to a folder after it has the permission, so it would look different at first and then change for subsequent authorizations.
Any app could change UI/UX for other apps using the same category with this. I’m not sure if it’s good to have app X be able to define what auth for app Y looks like.
Another solution to this problem that I can think of would be to standardize some of the categories (I guess at least all of the ones with official rs.js modules/schemas) and having official translations for them. We also thought about standardizing folder formats in a way that would allow providers to add spaces and capitalization to them.
However, if we were to standardize some scope names, I think we’d also have to specify the exact data layout, and I am not sure if we can come up with something general-purpose.
I don’t see how data formats have anything to do with scope names, though. If we agree on the “contacts” category holding contact data, then it doesn’t matter how that data is represented within. Apps can filter by content type if they have to. No?
I don’t think that’s a good idea, because from the user’s perspective this would basically means that apps see different data within the same folder depending on which schemas they support.
For example, if app A stores some data in the contacts scope, and then I log in with an app B that requests permission to the same scope (shown as “access app A’s data” by the server), then I’d expect that app B sees the same data as app A.
However, this expectation is broken because it so happens that app B doesn’t support the same content types as app A, and therefore shows an empty addressbook (or any different dataset). I, as a user, am not aware of this implementation detail.
Also, my personal goal is to write a CalDAV/CardDAV drop-in replacement spec based on remoteStorage. I’ve described a basic file layout in https://vdirsyncer.readthedocs.org/en/stable/vdir.html (which I already use on the OS filesystem).
However, this means that the resulting schema will not be based on JSON (though ideally it would be) but on an existing standard (which is not a good one, but at least it is one).
Hooray! I had the same plan once but never any time for it. I’d use that from day 1.
JSON is not a must per se. And storing in a single format is also not a must. An app (or rather a client module) could store calendar events in both JSON and iCal formats (and using iCal vocab for the JSON-LD representation) for example. When the rs.js contacts module updates a JSON-LD contact file, why not also let it update a VCARD address book at the same time?
Yes, that’s why the concept of common client modules with common JSON-LD schemas was one of the early pillars of rs.js. There is however the option of not relying on one format only per se. See my above comment.
I see, you’re under the assumption that the clients use the javascript library to access RS, and therefore support all possible formats. Without that assumption, there is still the possibility that app A and app B only support mutually exclusive formats.
Apart from that you still have massive data duplication.
I’m not. And I’m just throwing around ideas here. I don’t think it’s outlandish to agree on common formats among different clients/languages, and I don’t think there’s a lot of overhead in updating 2 files for a simple change of e.g. a contact. That might be a different story for other modules, but that’s why every scope/module/data format should be solved using case-by-case solutions imo.
For contacts and calendar entries it just makes sense to use formats that we can directly drop in to all existing programs that support it. But we could also store transformations of those formats in JSON-LD, which is more suitable for the Web, so that unhosted Web apps don’t have to jump through lots of extra hoops to be compatible to “legacy” standards.
I don’t think contact and calendar data is big enough to call a duplication “massive” by today’s storage and bandwidth standards.
