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]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
