Sharing Data

Hello!

I’ve been looking for something like remoteStorage for a little while and am glad to have found it :smile: This is very exciting stuff and I hope that things move in this direction. On to the question:

I have an app that is in the gaming space. It’s basically a platform for tabletop games. The games are persistent and I require storage space. I’d love to use something like remoteStorage. All the examples I have seen demonstrate data that is visible to only one user. My app requires that an “owner” share data with typically 2-10 other people who all can create data. Imagine a game board whose state must be seen by all players, each having some write capabilities so that they can move their own piece. Is this possible?

On a related note…do you have any tutorials or how to docs? All I’ve been able to find are the raw api docs.

Hi and welcome!

There’s no way of writing to someone else’s storage at the moment. The protocol doesn’t have any concept of ACLs or any other permissions than owner read/write for that matter. You can share data from a user’s /public directory, and you can use long secret URLs in order to keep it hidden from unintended viewers.

For things like live online games, I think it would make more sense to exchange game data directly between users via WebRTC.

These are not just live games, but persistent. Imagine a chess by mail type scenario. The game might take place between two people who can both change the state of the chess board, but they each take moves at different times, on different days and the whole game might take 2 months to play.

Unfortunately, it sounds like this scenario isn’t possible. I must say, it’s very disappointing. It seems like the move to user-owned and controlled data has completely forgotten about the notion of collaboration. ;(

It’s hasn’t been forgotten by accident. It’s about keeping the spec/technology simple, so that many people can understand and implement it.

remoteStorage does not aim to be a solution for every storage problem there is. For messaging and collaboration, we’re also working on Sockethub for example, where you could use other protocols to solve this from your unhosted web app (also not with the current version though).

You can get involved in the remoteStorage spec discussion anytime, or ask about the specific reason for in/excluding features:

Is there anything new on this front? I think remoteStorage is really interesting, but asynchronous private collaboration is an important feature for me. Is there a different project that addresses this need?

I’ve seen the “long secret URL” suggestion a couple of times, but I don’t think the security-through-obscurity approach is appropriate for the vast majority of use-cases.

It’s not really obscurity. It’s exactly the same as giving someone an access token, just as a URL.

There’s a current discussion on the Unhosted mailing list, which we should probably continue here in the remoteStorage forums: Redirecting to Google Groups

How is it not obscurity? If someone discovers the URL, there is no more security.

A single token is not a great model of authentication either, but at least you can revoke one user’s token without interrupting the access of every other user. Can you do that in this case?

Also, doesn’t the fact that a token is transmitted as part of the body of the request instead of as part of the URL have security benefits as well? If the request is intercepted, the URL can be read, but the body will be encrypted.

It just has to be clear to the user that it’s a secret URL, which is more of a UI problem to solve (and not a difficult one).

It’s not a multi-user permission model. There have been discussions about ACLs and they never lead anywhere. Please feel free to re-open this discussion anytime either here in the forums or over at GitHub (spec repo).

As far as I understand, in the case of HTTPS, if the request is intercepted, then it doesn’t matter if it’s the URL or the body. I think you should make it hard to intercept in the first place by using PFS, HSTS, cert pinning, etc…

Also, this is not a high-security permission model. If you really want to share something your life depends on, I think you should encrypt it with the recipients public key anyway. Doing this without PGP or integrating it into the spec is hitting the limits of the remoteStorage model, though, and you should probably also evaluate options like GnuNet or MaidSafe. Unfortunately, it’s not exactly a solved problem for end users yet (if we’re talking about good UX), but I think MaidSafe in particular looks very interesting so far, although I haven’t tested it yet.

Is this documented anywhere? I couldn’t find a mention in the API docs. How does this work from a programmatic point of view?
Can you do something like remoteStorage.access.claim('https://uri.tdl/to/public', 'r');?

When you claim access, you automatically have access to both the category as well as the category in the public folder. E.g. claiming access to documents gives you access to /documents/ and /public/documents/.

I just realized that this is not explained very well in the docs. In general, you do nothing different than when writing private data. You can just use the public path for storing files and objects and that’s it:

When using modules, defineModule gives you two instances of BaseClient, one with a private and one with a public scope: http://remotestorage.io/doc/code/files/modules-js.html

When using remoteStorage.scope, you can just give it the /public/something path that you have access to: http://remotestorage.io/doc/code/files/baseclient-js.html#RemoteStorage.BaseClient.RS#scope

Does that make sense to you?

You can also check out the code of https://sharesome.5apps.com – an app that stores files in the /public/shares/ directory – on GitHub. Here’s the shares module it defines:

https://github.com/skddc/sharesome/blob/master/vendor/remotestorage/remotestorage-sharesome.js

that looks like the way to write to the current user’s public directory. How do I read from someone else’s?

Before the client library rewrite we had a special kind of BaseClient called ForeignClient (iirc). I don’t know why it hasn’t been implemented in the rewritten version.

In general, you can just do HTTP requests to their public objects and files (anything else won’t work, as e.g. listing contents of a public directory is not allowed). In order to find the storage base URL, you could use RemoteStorage.Discover, same as the library does when connecting one’s own storage. Unfortunately, it’s not well documented, so getting help on IRC or opening a new thread here on the forums might make sense. You can also just read the source, of course.

Ultimately, I think we need to work towards bundling general sharing code in helper modules, as well as re-introduce the ForeignClient at some point. The latter would be rather easy; maybe you can even contribute it when developing it for your app?