#4043 HIGH Update.: [discussion] Group support in gabble and salut

[Zarro Boogs per Child]

#4043: [discussion] Group support in gabble and salut
------------------------------+---------------------------------------------
  Reporter:  kimquirk         |       Owner:  smcv    
      Type:  enhancement      |      Status:  new     
  Priority:  high             |   Milestone:  Update.2
 Component:  telepathy-other  |     Version:          
Resolution:                   |    Keywords:          
  Verified:  0                |  
------------------------------+---------------------------------------------

Comment(by Eben):

 Replying to [comment:9 smcv]:
 > The requirement to support colliding OLPC-group names means we have to
 use a pseudo-random string, or a UUID, or something (generated by the
 creator of the group) for its JID, rather than creating a meaningful JID,
 much like we do with activity IDs - the real name of "Class 3a" will have
 to be something like 45729a98f472cc39de at groups.cambridge.xs.laptop.org
 rather than Class.3a at groups.cambridge.xs.laptop.org.
 >
 > We could either give groups a prefix on their random JIDs to stop them
 colliding with activities, or use two MUC services (e.g. groups.foo and
 activities.foo) to host their chatrooms.

 You can also prefix the UUID with the human readable name, if that string
 would ever be exposed and need to make sense to someone.

 > The requirement for OLPC groups to have no privileged users requires
 that we automatically promote every member to be an owner. (XMPP MUCs have
 a concept of access levels and roles, whether we want it or not - the
 owner can designate others as owners, so the easiest thing would be to
 just promote everyone we invite to have owner status. We plan to do the
 same thing at some point for activities to guarantee everyone has full
 control, which I'll file a bug about).

 Sounds good.  That's also nice because it allows us to change things later
 if it's ever necessary to have ownership.  Hopefully our open and equal
 model will suffice, though.

 > At the Telepathy level, we probably want OLPC-groups and activities to
 look very similar - it's only in the Presence Service API that they need
 to start looking different.

 This is an important point, especially so because we have discussed the
 idea of an activity ''as'' a temporary group.  That is, an activity could
 have an associated bboard, chat, etc. while it exists.  That group could
 be used to initiate new activities having the same members (eg. I meet 3
 people in a chat and we decide we want to draw something together...this
 is a one step process if there is a temporary group for the members of the
 chat).  We also discussed the possibility of bestowing permanence on such
 a temporary group.  Doing so would invite all the members of the activity
 to the group, and of course preserve any of the shared object state that
 they already have around.

-- 
Ticket URL: <http://dev.laptop.org/ticket/4043#comment:10>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system