Prior discussions on granular sharing / multi-user access

Getting Started
1

Hi all — I’ve been spending more time with remoteStorage recently and really enjoying how clean the model is for personal data and simple sharing via public paths. Thanks for working on this project and building a community around it.

Feels like I’m 10 years late to the party, and I see discussions around adding new features to the spec that I am interested in today. Specifically, I want to explore how far I can take RS to build apps with granular sharing, and realtime feedback (not discussed here), since many apps/users expect these features these days.

From what I understand, granular sharing has come up multiple times over the years, but hasn’t really landed — partly because:

  • remoteStorage is intentionally focused on simple personal data storage
  • identity and permissions become complex quickly, especially across servers
  • and there hasn’t been a clear, low-complexity model that fits the existing philosophy*

I’d like to explore whether a much more constrained version of sharing might work, and wanted to sanity check the direction before going deeper.

Specifically:

  • same-server only (no federation, no cross-provider identity)
  • folder/subtree-level sharing
  • simple roles (reader / writer)
  • server-enforced ACLs (not app-layer only)
  • treated as an optional capability, not part of the core protocol

The goal would be something closer to: “shared folders between users on the same storage server”, rather than a full distributed sharing model.

I’d like to support use cases that go slightly beyond purely personal data (shared collections, small-team apps, etc.), while still keeping things aligned with the RS model.

I’m also curious whether something like this could:

  • live as a server feature (e.g. Armadietto extension)
  • be exposed via rs.js as an optional capability
  • and map onto existing backends like Dropbox / Google Drive (where sharing already exists)

Open questions

  • Does this still run into the same fundamental objections as earlier ACL discussions?
  • Has anything like a same-server-only sharing model been explored before?
  • Is there any concept of “extensions” or capability negotiation in RS that this could fit into? Perhaps so I can work on this out of spec, while keeping it tightly integrated?

If this has already been explored in a similar form, I’d love pointers.

Otherwise, happy to sketch something more concrete — just wanted to make sure this is not a really bad idea.

Thanks!

1 Like
2

Hey @jonocodes! Welcome, and thanks for documenting / sharing these reflections :folded_hands:t4::sun:

I think “shared collections, small-team apps” or any kind of collaborative design is something I’d also like to support. The way I thought to do it until there’s a more clear consensus would be to pair:

  1. a server-side interface that generates an OAuth token associated with some set of paths, and
  2. support for multiple storages in rs.js

The second would require some change to the library, but otherwise it seems like the least amount of change needed to make it possible. I will let other people chime in about previous discussions…

3

In theory, you could generate a bunch of OAuth tokens for those you wish to allow (limited) write access to some location with your storage provider. You’d just give everyone unique scopes (directory names) to write to. You’d design some function that takes as input a concatenated challenge and response (e.g. their email address concatenated with the answer to a question that you’re confident that only they would know—maybe even a passphrase you’ve shared with them out-of-band) from which the function derives a secure, unique ID which can itself be used to derive the scope and to retrieve the pre-generated token. After completing the challenge-response process, they (read: their client—probably the one you implemented) could begin depositing things into their designated subdirectory.

Caveat: it’s coming out of your storage quota.

For a group, you could pre-generate a bunch of different scopes for everyone in the group, make sure each person’s scope contains a metadata file listing all the (public) scopes for the other users in the group, and have the client poll all of those scopes to look for writes from others in the group.

There would really be no benefit in this over having each user just register their own account with a remoteStorage provider and employing a similar scheme for gossip between clients, except there’s maybe some marginal disadvantage in requiring them all complete registration and the need for you to wait for them and give you their user@provider identifier. (But in that case, if you were doing this because you know they don’t have an account with a storage provider, you could just register an account for them and communicate the login details the same way that you would have shared the passphrase for their challenge-response pair).