Wow, that's a lot of thinking! Before this thread spirals out of control can I please suggest anyone responding to some aspect of Tad's message start a *new thread* for discussion of that particular aspect. Or discuss in the linked wave.
A. On 2 December 2010 19:24, Tad Glines <[email protected]> wrote: > Here's a brain dump of everything I'm currently thinking regarding groups > implementation in WiaB. > > Here's a link to the same contents in a wave: Wave: Notes on groups > implementation in > WiaB<https://wave.google.com/wave/#restored:wave:googlewave.com%2Fw%2Ba8IefihkA> > > > Notes on groups implementation in WiaB > > *Phased Approach* > > I've given a lot of thought about implementing groups in WiaB and I think a > phased approach is best. > > > 1. Implement group data persistence. Group members initially will be > limited to only users local to the server. > This involves defining the internal representation model and an initial > set of group member roles/capabilities. These roles/capabilities may not > have a one-to-one relationship with the roles/capabilities that are exposed > in federated groups. > 2. Implement basic UI for managing group membership > 3. Modify the server's client frontend code to allow a client to > request deltas from a wavelet where the user is on at least one > authentication path that terminates in a wavelet participant. > 4. Modify the server's client frontend to add group wavelets to the > user's index. > 5. Modify the server's client frontend to allow delta submissions from > the user to group wavelets. > 6. Define the method where-by a server communicates group membership to > of remote users to their server so it can properly route wavelet updates. > 7. Define the method where-by the group server can tell the remote > server about the wavelets the remote server should be adding to it's user's > indexes. > 8. Add support for adding remote users to the group, but limit their > interaction to read-only. > 9. Add support for delta submission from remote users. > > I'm working on implementing #1 right now. Once I have the interface > defined, I'll submit a patch for code review. > As part of the interface I'm trying to define an initial set of group > member roles/capabilities. That's what prompted the OP to this thread. > > *Capabilities* > > *Background* > > The Access Control > White-paper<http://www.waveprotocol.org/whitepapers/access-control>defined > the following set of permissions: > > - Indexed to (INDEX) - wavelets addressed to address B will be written > into the index of the account associated with address A (transitively). > - Add (ADD) - address A can add address B to wavelets. > - Add myself as (ADD_ME) - address A can add address A to wavelets as > address B. > - Read (READ) - address A can read wavelets addressed to address B. > - Write (WRITE) - address A can do anything as address B. This could > also be called "act as". > - Grant (GRANT) - address A can grant additional access edges to > address B. > > In the the class org.waveprotocol.wave.model.account.Capabilities ADD_ME is > renamed to JOIN and GRANT is absent. > In either case I think they are insufficient for use in describing the > capabilities needed for groups and delegated addresses. > > *Proposed* > > Here's the set of capabilities I think should be defined and communicated > to clients and servers with group members: > > - READ - The member can read group wavelets. This is implied by group > membership. > - JOIN - The member may submit a delta containing only an > AddParticipant operation adding him/her self to the wavelet. The delta's > author must be the group's id. > - WRITE - The member may submit deltas to a group wavelet but member's > id must appear in the author field. > - IMPERSONATE - The member may submit deltas to a group wavelet with > the group's id in the author field. > > In the case of WRITE, the delta's author field must contain the member's > id, the authentication path must terminate with an ID that is a wavelet > participant, and the delta must be signed by the servers of all domains that > appear in the authentication path (including the author). > > Regarding INDEX, I don't think this should be treated as capability or > permission, but instead as a user preference. I as a user should be able to > choose whether or not I want the wavelets from a group to appear in my > inbox. As such, this should be a local server managed matter and doesn't > require communication between servers. > > These capabilities only define what member's may do with group wavelets. It > does not define what the member may do with the group itself. > > Here's the complete list of the proposed group capabilities. > > - READ - The member can read group wavelets. > - JOIN - The member may submit a delta containing only an > AddParticipant operation adding him/her self to the wavelet. > - WRITE - The member may submit deltas to a group wavelet but member's > id must appear in the author field. > - IMPERSONATE - The member may submit deltas to a group wavelet with > the group's id in the author field. > - VIEW_MEMBERSHIP - The member may view the group membership list. > - VIEW_MEMBER_CAPABILITIES - The member may view the capabilities > granted to members. > - GRANT - The member may grant self held capabilities (excluding GRANT > & REVOKE) to other users. > - REVOKE - The member may revoke self held capabilities (excluding > GRANT & REVOKE) from other members. > - META - The member may grant or revoke GRANT & REVOKE (if held) to or > from other users or members. > - OWN - The member may grant any capability or revoke any capability > excluding OWN to or from any user or member. > > These individual capabilities can be combined to create the roles I had > proposed previously. > > And, since we're on the subject of capabilities, here's a set of proposed > wavelet capabilities. > > - READ - Holder may read wavelet content. > - ADD - Holder may add documents to a wavelet and may edit self added > documents. This includes registering the document in an model specific > manifest. > - WRITE - Holder may modify any document. > - GRANT - Holder may grant self held capabilities (excluding GRANT & > REVOKE) to other users. > - REVOKE - Holder may revoke self held capabilities (excluding GRANT & > REVOKE) from other users. > - META - Holder may grant or revoke GRANT & REVOKE (if held) to or from > other users > - OWN - Holder may grant any capability or revoke excluding OWN to or > from any user. > > It might also make sense to add something like a LOCK or RESTRICT > capability that means the holder may restrict edit access on their editable > documents to self or some subset of participants. > > *Federated group communication model* > > *Special Participant IDs* > > I think there is a need for some special participant ids. Here's what I'm > proposing: > > - *...@domain* - The server itself. Used when a server needs to have > access to a wavelet's contents, but the contents should not be > made available to any users at the server. > - *...@domain* - Everyone within the domain (public, but only to users > with the same domain). > - *...@** - Everyone on the planet. > > The UI would most likely use aliases for these, or hide > them entirely when appropriate. > > *Group's Server to Member's Server Capabilities Document* > > The group's server needs to notify the member's server of the capabilities > its users hold for the group. The group server would construct a single > wavelet that contains capabilities for all of the server's groups in which > the user is a member. > > WaveId: (ID = capabilities, Domain = Groups's domain) > WaveletId: (ID = Member's id, Domain = Group's Domain) > Participants: Member's Server. > Documents: (one per group, named after the group) > > In each document would be a sequence of elements of the form <grant > c="<CAPABILITY>"></grant> where c contains the name of ONE capability. > The group id and member id are derived from the document name and the > wavelet id. > > The wavelet is not modifiable by anyone but the origin server. > > *Group Index* > > One initially considered option for sending the group index is to do it in > a wavelet. The problem with this is that the index would potentially have as > many deltas in it as there are deltas in all group wavelets combined. This > doesn't seem very scalable. Given that the index entry is limited to about > 100 characters it seems reasonable to just send the whole thing every time > it updates. Since it doesn't need to be signed, it's still going to be > smaller than any delta. Also, entry updates can be queued and sent no faster > than every 10 seconds. > > Here's what the messages might look like in protobufs form. > > message ProtoIndexEntry { > // The wave id > required String entry_id = 1; > > // The last index version at which this entry was modified > required long entry_version = 2; > > // The wave title > optional String title = 3; > > // The wave digest from the point of view of the group's participant > optional String digest = 4; > } > > message ProtoIndexUpdate { > // The group id > required String index_id = 1; > > // The index version created by this update. > required long index_version = 2; > > // The set of entries modified by this update. > repeated ProtoIndexEntry = 3; > } > > message ProtoIndexAck { > required String index_id = 1; > > // The index version being ack'ed > required long ack_version = 2; > } > > message ProtoIndexHistoryRequest { > required String index_id = 1; > required long last_known_index_version = 2; > } > > When a new remote member is added to a group, the group's server would sent > a ProtoIndexUpdate with no entries and would then send updates after that. > The receiving server would make a history request once recieving the first > update. Periodically the receiving server will send a ProtoIndexAck. The > group's server will persist the last known index version acked by the remote > server. If the group's server doesn't get an ack within 60 seconds, it will > periodically (with backoff to 24 hours) try and send a ProtoIndexUpdate with > just the version number in it until it is acked then all updates will > commence again. > > *User's group capabilities document* > > The user's client also needs to know about the set of groups the user > belongs to and what capabilities that user has for each group. the ser will > collect all the capabilities the server to server capabilities wavelets and > place them in a user accessible wavelet. > > WaveId: (ID = capabilities, Domain = server's domain) > WaveletId: (ID = user's id, Domain: server's domain) > Participants: User > Documents: one per group, named after group > > In each document would be a sequence of elements of the form <grant > c="<CAPABILITY>"></grant> where c contains the name of ONE capability. > The group id and member id are derived from the document name and the > wavelet id. > > The wavelet is not modifiable by anyone but the server. > > -Tad > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
