On Wed, Feb 10, 2010 at 6:27 PM, Ronald C.F. Antony <ronald.ant...@gmail.com> wrote: > On 10 Feb 2010, at 11:59, Bart Thate wrote: > >> Well one thing i know from my IRC days is that its best to put the >> power into the owner hands and NOT distribute this power to other >> participants as you will get the old take-over days all over again. > > It all depends. Waves between friends, in a corporate settings, in a > semi-public or public environment etc. are all different. > > If Wave is going to supplant e-mail, and I have a one-on-one with my > girlfriend, it should have different semantics than when Wave supplants a > mailing list on e.g. VW engine repair issues. > > It is because Wave can potentially replace E-mail, IRC, IM, BBS, > collaborative workflow software, Wiki, etc. that it needs a more > differentiated approach, because these various currently used tools have each > different assumptions of trust, and all of them have to be mappable into > Wave. And that's the challenge. > > So by default, all the power should be with the creator. But there need to be > mechanisms to relax control, and there need to be mechanisms to assign trust > levels to certain users, such e.g. in the above girlfriend scenario, I don't > have to explicitly give her all sorts of permissions each time a start a new > wave with her.
What i ment is that the power to give permissions should be with the owner. Ofcourse you need to be able to allow participants certain actions, put don't distribute the power to give these permissions (the +o in IRC terms) > > Maybe one way of dealing with this is that e.g. adding users to a wave is > only possible if that new addition has the same or higher assigned trust > level with the creator of the wave. > > Example: I trust my buddy, my girlfriend, but not her sneaky room mate. So I > start a new wave with my buddy. He adds my girlfriend to the wave, which > works, because she has the same or higher trust level assigned in my list of > contacts as he has. She wants to add her room mate, and that will trigger a > permission request to me, because now the entire conversation (according to > the weakest link theory) will degrade in trustability. > > The question is, will my buddy have to agree to having the room mate added, > too, or can I simply rule yes, because I started the wave? > > I guess in a collaborative setting like the above example, he should be > asked, too, unless she's already on the appropriate trust level in his list > of contacts. > > I more structured Wave, there should be something like an admin/owner. So > either we need to have different wave types we instantiate, or we need a > mechanism to alter the type of the Wave e.g. based on the number of > participants, whether or not it's a public wave, etc. > This gets complicated ;] > The tricky part is, it not only has to do what we need and be secure, it also > has to be easy to understand, because the best mechanisms are useless if they > are so complicated that people don't use them properly. > > Maybe Google should come up with a plan for all this access control stuff, > deletion issues, etc. and have list dedicated to discussing it? I don't want > to clutter the list here with these rather vague ideas in a vacuum of > knowledge of Google's plans. On the other hand, I do think these things need > to be addressed, because in some ways Wave is woefully inadequate in these > regards as it stands now. I dont think discussing this here is a problem as its so related to where wave is heading esp. what the new API will implement. The lack of knowledge of Google's plans is problematic i think as its pretty much black box for us until we have the new API code. Bart -- You received this message because you are subscribed to the Google Groups "Google Wave API" group. To post to this group, send email to google-wave-...@googlegroups.com. To unsubscribe from this group, send email to google-wave-api+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-wave-api?hl=en.
