New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Biased towards personal use? #40

vanrein opened this Issue Oct 24, 2013 · 4 comments


3 participants
Copy link

vanrein commented Oct 24, 2013


After thinking about the mechanism of authorisation, I've turned to the conceptual authorisation model (with :r, :w, :rw privileges and a distinction into public space) and I was wondering if it isn't too strongly focussed on personal applications. It is open for discussion if business applications of remoteStorage make any sense, of course. It might be possible to simplify the spec (!) and leave more freedom to the remoteStorage implementer/hoster.

It is common to distinguish CRUD (create, read, update, delete) privileges, so a user administrator is able to create a resource that users can read and/or edit, but not delete. This is not possible in the current model. The implicit creation (and deletion?!?) of folders may not be equally suitable at every roll-out, and might be a default policy (resource can create/delete its own folders) that can be adapted by administrators. I suspect you want the ability to silently add an application, with data folders underneath that could be helpful for users to edit -- distinctions like these could be configured by the authorisation policy administrator.

Another authorisation practice in business that is not foreseen in remoteStorage is group-wise access. This is basically a generalisation of the public URIs that you specified -- you could define a public group to do just what you describe for public URIs. And another group to define specwriters. And another to describe... This degree of flexibility enables groups to co-operate on a document through remoteStorage, and that is a useful application of the protocol in business use!

Interestingly, the best way to enable these facilities might not be to expand the specification, but rather to remove overly specific parts. I've also argued from another angle that authorisation is too specific -- in fact, I would propose not to mention the {r,w} rights or the public paths in the spec, unless a JS-app needs to be able to rely on them and has no REST-mechanism to find this information. I also wonder if explicitly creating and deleting folders is too much effort for a JS-app; doing this explicitly means that it can also be offered to users in the interface they use. For an implementation it is a big duh that choices like these are needed, but it sounds to me like an issues shared between the resource server, the authorisation setup and the customer. The remoteStorage spec is mainly of interest to the relation between the JS-app and the REST-store, and I wonder if the possible authorisation privileges and their enforcement should be part of that spec?

Just hoping to stir up improvements, in the hope that it is useful.

Schrijven is schrappen :-)



This comment has been minimized.

Copy link

michielbdejong commented Oct 24, 2013

yeah, the set up with the scopes is entirely geared towards how remotestorage.js uses it with modules. still, i think it's generic enough.


This comment has been minimized.

Copy link

vanrein commented Oct 24, 2013

Hi Michiel,

yeah, the set up with the scopes is entirely geared towards how
remotestorage.js uses it with modules.

my concerns are about the spec, as before; not about the code.

still, i think it's generic enough.

Can you tell me which of my statements you disagree with?

  1. that remoteStorage should cover business applications, not just
    personal use
  2. that groupwise co-operation is currently not supported
  3. that groupwise co-operation adds value for business use
  4. that creation/deletion privileges are currently not supported
  5. that creation/deletion privileges matter for business use
  6. that the spec deals with JS-app <--> REST-storage interface
  7. that the spec covers a generic concept, rather than describes an



This comment has been minimized.

Copy link

michielbdejong commented Oct 25, 2013

i think i sort of disagree with 1. it's about per-user user-data storage. if you're looking for just restful storage, then check out rww or webdav.

  1. it's possible for everybody to host versions of the same document (like git does it) if you have a messaging channel on the side (like sockethub). but in general, i agree

i agree with 4. but then again there are infinite possibilities of features you could add that would add value.

if with 8. you mean that there are no creation-only or deletion-only perms, then i agree. it's either read-only, or read-write, including creation, deletion, and updating, all in one bucket.

don't know about 16., i guess i disagree but i also don't know how relevant that is. i also think 'business use' is too generic a term, people do business with their smartphone, but smartphones are still consumer electronics, aimed at end-users.

i guess i agree with 32. and 64., not really sure what they mean.

what i get from this is that you want to add ACLs, is that where you're going? can you make a specific feature request saying what you would change in the spec?

i hope this answers your question (closing the ticket).


This comment has been minimized.

Copy link

skddc commented Oct 25, 2013

I think per-user doesn't necessarily conflict with business usage. A user could still belong to an organization, or use a shared business account (which we do e.g. with Grouptabs and Litewrite at AfricaHackTrip).

The latter is obviously just a hack for very small teams with a lot of trust, and the only thing missing there today to make it convenient is simultaneous connects with different accounts in remoteStorage.js.

For the former, I'd prefer if we discuss that solution using the terms "team" and "organization" instead of just "business". It's natural for humans to form groups in order to achieve goals, and any group, both small and large, would benefit from using something like remoteStorage as well. So why not think about how we can approach that problem?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment