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

consider adding support for sharing/collaboration #58

Open
michielbdejong opened this Issue Feb 10, 2014 · 14 comments

Comments

7 participants
@michielbdejong
Member

michielbdejong commented Feb 10, 2014

i'm against Access Control Lists! sharing in remoteStorage should work like git: you publish your version, and send pull requests to the people you collaborate with.

having said that, i think it's fair to say that this decision is what is currently costing us most market share. people will say "oh, but i need sharing/collaboration", and develop their unhosted web app for the Dropbox platform or the GoogleDrive platform instead (which both do have sharing/collaboration built in). see http://community.remotestorage.io/t/collaboration-through-public-sharing/84/8?u=michielbdejong for a discussion of how this affects app development.

it's worth noting that this would clash with #39 (comment) because it would involve giving people outside your Kerberos domain access to documents on your account

@skddc

This comment has been minimized.

Member

skddc commented Feb 10, 2014

Sharing via long URLs is easy already. Collaboration is the real problem to solve here as far as I see it.

(I mean spec-wise. Some kind of generic sharing support in the library might make sense as well.)

@michielbdejong

This comment has been minimized.

Member

michielbdejong commented Feb 11, 2014

right, sharing = read-only, collaboration = read/write

@silverbucket

This comment has been minimized.

Member

silverbucket commented Feb 17, 2014

We definitely need collaboration, it's a major pain-point for most potential app developers, and it's often one of the first things I'm asked about when I give someone a 5min technical overview.

What about some sort of list an a URI endpoint which allows POSTS from sources which are identified in some way in the list? I'm being intentionally vague as I'm not sure what the best approach is for identifying 3rd parties because you don't have the OAUTH token accross RS vendors.

@michielbdejong

This comment has been minimized.

Member

michielbdejong commented Feb 17, 2014

i think it could be done by adding 3 verbs, one to create a derived token (read or read/write) for one specific document or folder, one to delete it, and one to get a list of derived tokens.

with that, an app could create a link to share in order to invite people to collaborate on a document, just like in GoogleDrive.

my only concern is whether we have enough manpower at the moment to commit to developing this feature. if we add this to the spec without anybody using it, then that's in itself useless.

even if we insert this as point 2 1/2 in http://community.remotestorage.io/t/roadmap-three-phases/98 (before native support) i think we don't have enough people to successfully develop this for at least another year or so. realistically, i think we could start work on this in one year from now, and finish it in two years from now. not to poop the party, just trying to be realistic about expectations. :)

that's why i proposed that maybe we should delay it until the 04 spec.

@skddc

This comment has been minimized.

Member

skddc commented Feb 17, 2014

Completely agree with these estimates. I think we should keep it in mind, but first get everything working as best as possible with what we have.

@jaredly

This comment has been minimized.

jaredly commented Aug 12, 2014

👍 this would be so awesome. I'm really excited about remotestorage, and collaboration would really seal the deal

@michielbdejong

This comment has been minimized.

Member

michielbdejong commented Sep 17, 2014

pushing to 05 since we have nobody in the community who would currently have time to work on this.

@michielbdejong michielbdejong changed the title from consider adding support for sharing/collaboration in the 04 spec to consider adding support for sharing/collaboration in the 05 spec Sep 17, 2014

@michielbdejong

This comment has been minimized.

Member

michielbdejong commented Oct 27, 2014

We can keep this ticket open for now, but I'm starting to think it's better to implement collaboration at a higher level, e.g. on top of rss. People can then use remoteStorage or whatever else they want to publish their rss feed. I plan to experiment with this and can hopefully have something working before the 05 spec.

@trokster

This comment has been minimized.

trokster commented Dec 6, 2014

Question: why not publish encrypted data to public. From what i read you already have a contacts list, so potentially their public keys. When reading data you would filter out anything you can't decrypt( so not for you ).

@michielbdejong

This comment has been minimized.

Member

michielbdejong commented May 30, 2015

@trokster you can choose to do that at the data module level, certainly. But doesn't need to be mentioned in the spec.

Leaving the topic of sharing out of scope for version 05, we did write about it here yesterday, a bit related to this issue maybe.

@michielbdejong

This comment has been minimized.

Member

michielbdejong commented May 30, 2015

(we = Paul Tran-Van and myself)

@michielbdejong

This comment has been minimized.

Member

michielbdejong commented Nov 17, 2015

Maybe in 07 ;)

In fact, I think this would live on top of remoteStorage spec, see the I-D mentioned in #58 (comment)

@fkooman fkooman added this to the remoteStorage-07 milestone Nov 17, 2015

@untitaker

This comment has been minimized.

Member

untitaker commented May 28, 2016

Do we really want this in draft-07? Proposing "maybe one day" milestone.

@untitaker untitaker changed the title from consider adding support for sharing/collaboration in the 05 spec to consider adding support for sharing/collaboration May 28, 2016

@skddc

This comment has been minimized.

Member

skddc commented Feb 3, 2018

There's a new argument against adding this: the fact that SOLID, a project that is lead by timbl, is basically a big, much more feature-rich RS, that has sharing built-in. The USP of RS in comparison is the simplicity and how easy it is to implement both clients and servers right now.

I'd say let's close this issue and put it on the "maybe some day" agenda, as @untitaker proposed almost two years ago. WDYT?

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