Implement Public waves

[GoogleCodeExporter]

Public waves should work similar to Google Wave:
1) Any user from 'foo.com' domain should be able to view a wave with 
'public@foo.com' even without being explicitly added as participant to the wave.
2) If user that belongs to foo.com attempts to edit a public wave - he is 
automatically added to the participants.

3) User on foo.com can request to display pubic waves on the foo.com server in 
addition to inbox by changing the search query from 'in:inbox' to 'all'.

4) User can request to display (only) all the public waves on foo.com using the 
"is:piblic" query.

Original issue reported on code.google.com by vega113 on 2 Mar 2011 at 2:46

[GoogleCodeExporter]

Updates on design:
* There's technical difficulty to implement (2) in a sense that it's difficult 
to force the user to be added explicitly to the wave's participants. So, right 
now I intend to skip this requirement.
* A small fix to (4) - it should be "with:public".

Original comment by vega113 on 7 Mar 2011 at 6:22

• Changed state: Started

[GoogleCodeExporter]

2) should already happen implicitly.

Any op that a client constructs against a wavelet is authorized before 
application (see OpBasedWavelet#authorise).  The policy is that if that client 
is not already a participant, an AddParticipant op is injected first, where 
that op is authored by an authorising participant.  The choice of which 
participant is the authoriser is made by a ParticipationHelper.

Most of the code is already code to do this, and it's part of the UX for groups 
in Google Wave.  If you are not a participant on a wave, but you are a member 
of several groups that are participants on the wave (possibly including 
public), then if you start to edit that wave, you become a participant.  The 
mechanism that causes that to happen is in OpBasedWavelet#authorise.  An 
AddParticipant op that adds you is injected into the op stream, and that op is 
logically authored by one of those group participants.  The choice of which 
group to use is made by a ParticipationHelper.  Everything else is wired up in 
OpBasedWavelet.

In Google Wave, that ParticipationHelper knows about all the groups in which 
you are a member, and the access graph of what capabilities you have through 
that group (read, add others, modify content, etc).  For WIAB, using a trivial 
version of that ParticipationHelper (that chooses the public participant as an 
authorizer if they are a participant) should provide the desired behaviour. 

Original comment by hearn...@google.com on 7 Mar 2011 at 11:49

[GoogleCodeExporter]

I see, thanks, I ll investigate this direction.
A side question - is it really the best solution to force the user to become 
participant in order to edit? 
I actually can imagine reasons while it's makes more sense to allow users to 
edit public waves without becoming explicit participants.
For example, you create a wave, and make it public. Some people participate and 
edit/create new blips. Some just read the content without making changes and so 
don't become explicit participants. After a while you remove the public 
participant from the wave. If I understand it correctly - those that were just 
read only implicit participants lose access to the wave, while explicit 
participants retain the complete access. 
Maybe it makes more sense to allow becoming explicit participant only by direct 
addition by another explicit participant...
What you think?

Original comment by vega113 on 8 Mar 2011 at 12:02

[GoogleCodeExporter]

I don't think your example is a particularly convincing argument against adding 
contributors to a wave as explicit participants. If you remove the public 
participant, presumably you can also remove the other participants if that's 
what you want.

It was never clear-cut whether adding contributors as explicit participants was 
a good or a bad idea, but I don't think it was really problematic, so I suggest 
we start by implementing the same in WIAB. If we encounter problems or an 
alternative gains community consensus, we can change it again.

Original comment by so...@google.com on 13 Mar 2011 at 4:59

[GoogleCodeExporter]

Yes, I agree that current WIAB implementation should be aligned with Google 
Wave. I have followed David's advice and the latest patch automatically adds 
editing user to explicit participants.
However, I think that the example above highlights the problem with current 
implementation.

Original comment by vega113 on 13 Mar 2011 at 4:10

[GoogleCodeExporter]

Another design update:
Google Wave has "groups" mechanism which grants access to waves based on the 
group membership with "public" group being special group with everybody being a 
member. 

It is not the functionality proposed in this design. What actually proposed are 
domain-wide shared waves. To reflect this, the waves would be marked with 
"@example.com" participant instead of "public" or "public@example.com" which 
should be reserved for the real public groups. 

Original comment by vega113 on 16 Mar 2011 at 10:58

[GoogleCodeExporter]

fixed

Original comment by vega113 on 3 Apr 2011 at 8:22

• Changed state: Fixed