search

remotestorage / spec

remoteStorage Protocol Specification
https://tools.ietf.org/html/draft-dejong-remotestorage
87 stars 5 forks source link

consider adding support for sharing/collaboration #58

Open michielbdejong opened 10 years ago

michielbdejong commented 10 years ago

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 https://github.com/remotestorage/spec/issues/39#issuecomment-33900921 because it would involve giving people outside your Kerberos domain access to documents on your account

raucao commented 10 years ago

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 commented 10 years ago

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

silverbucket commented 10 years ago

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 commented 10 years ago

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.

raucao commented 10 years ago

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 commented 10 years ago

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

michielbdejong commented 9 years ago

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

michielbdejong commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

(we = Paul Tran-Van and myself)

michielbdejong commented 8 years ago

Maybe in 07 ;)

In fact, I think this would live on top of remoteStorage spec, see the I-D mentioned in https://github.com/remotestorage/spec/issues/58#issuecomment-107031200

untitaker commented 8 years ago

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

raucao commented 6 years ago

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?