#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:3 smcv]:
 > So: just what is a group, conceptually? It sounds as though you have
 some working definition in the 1CC office that I'm not fully aware of. Use
 cases?

 A group is a list of contacts who have organized themselves around a
 common interest or goal.  The group provides a persistent "collaboration
 space" within which the members may work on activities, chat, and share
 objects with each other. The membership of the group is known to everyone
 within the group, and anyone in the group may invite others to it or leave
 it at any time.

 Use cases could be "third grade class" or "my band" or "chess lovers" or
 "reading group 5."

 > And some more concrete questions, on the assumption that my view of what
 you mean when you say "groups" isn't a million miles from the truth:
 >
 > * Who can be in a group? Am I right in assuming a group contains (only)
 contacts?

 Strictly speaking, yes, but the existence of a group implies that other
 state is kept around (bulletin boards, for instance, require a shared
 space for "posting" files and notes).

 > * Are groups determined per-user (the user chooses to put Alice, Bob and
 Chris in the group "my bestest friends"), or imposed by others (the
 teacher chooses to put Alice, ..., and Zack in the group "class 12a" and
 all their laptops automatically pick that up), or both?

 Neither, exactly.  The current vision for a group is that anyone may start
 one, and anyone within the group may invite others, who become members
 only upon acceptance of such an invitation. Groups are private, but openly
 extensible; a group has no manager.  As such, a user invites (not places)
 Alice, Bob, and Chris to the group "our tight-knit group", and then some
 (not necessarily proper) subset of those invited will accept the
 invitation.  Likewise, a teacher could invite Alice, ..., and Zack to
 "class 12a", implicitly becoming a member of the group herself, and then
 each child would have to accept the invitation.

 > * Do you need to still be aware of groups while offline? (Assuming
 they're server-stored, that would mean PS would have to save them locally,
 since Salut obviously can't store anything on its lack of a server)

 Absolutely.  Groups should be made "more efficient" by the server, but
 should function without it.  The extent to which the shared "bboard" space
 is stored offline requires some thought.  If we simply store a local list
 of references to all objects on a bboard, for instance, we can apply the
 same visual design for presence and absence to indicate those which can be
 retrieved from someone around within the group, and those which aren't
 accessible based on the current network composition.  If I was out sick
 today, I can find out from my neighbor Alice that evening what others
 posted to our group bboard, but I can only retrieve the files that Alice
 herself posted or downloaded, perhaps.

 > * When can you edit groups? Only when connected to the server, or while
 offline with synchronization later, or what?

 Groups can be modified at any time.  If I choose to leave a group, I can
 do so even when no other member of the group is around.  My action will be
 conveyed to other group members once I am back in contact.  Likewise, If
 Alice, Bob, and Chis are in a group, and Alice goes home where the only
 other person she can reach is Dan, she may invite Dan to the group.  Bob
 and Chris will be informed of the new membership later.

 > * Who can see who's in a group? Is it public information, or available
 only to members, or available only to privileged members (e.g. only the
 group creator), or does it need to be switchable?

 We're virtually eliminating management completely.  The creator is in no
 way distinguishable from the members she first invited.  Groups, at least
 for now, will be private spaces within which activities can be
 collaborated on, conversations may happen, and objects may be shared.  No
 one outside the group can see any of these activities, conversations,
 objects, or for that matter, the group membership.

 Obviously in cases like "chess lovers" it might be nice to have public
 groups that anyone could find and join.  This, however, adds a management
 step to the group creation process, even if it is just one checkbox, which
 we can ignore for now. (I say creation because it's a ''very'' hard
 problem to deal with once the group has membership, since no member has
 ownership or managerial status.  If members ''join'' a group knowing it's
 public, then they are aware that anything they say or share is also
 public.)  I think this is a great thing to have eventually, but it
 requires more work to figure out how to create them and also how to
 visualize them so others may join.

 > * Do groups need an associated chatroom? If so, how is it used? Would it
 be sufficient if it was implemented as "start the Chat activity and invite
 all the people in this group" or does it need special-casing?

 We do need a form of chatroom for the group, which will likely ''not'' be
 an activity.  Instead, some of the thinking leans towards a "bubble chat"
 overlay in Groups view, which could be toggled on and off (one and the
 same as the bboard, perhaps?).  This would be an transient chat space,
 with messages appearing over the XOs and then disappearing shortly
 thereafter.  It does not serve as a permanent record of conversation;
 that's what the Chat activity is for.  Of course, any member of the group
 could start a "group chat" trivially by rolling over "Chat" in the Frame
 and selecting "Chat with Group...<my group>", which would invite all group
 members.

 > * Can there be more than one group with the same human-readable name?

 This is a very good question.  My inclination is that we have to assume
 so.  Without a server to mediate groups at all times, this is going to
 happen.  It's simpler to assume that, as group membership is only known to
 its members, the two groups may never conflict.  The only troublesome case
 occurs when Alice gets invited to a group of the same name as one she is
 already in.  Perhaps in such a case we simply allow Alice to create a "pet
 name" for the new group as she accepts the invitation, so that it's
 locally distinguished for her.

 > * What are the priorities of the above considerations, on a scale from
 "meh, don't really care" to "1.1 blocker"?

 Groups as an organizational concept comes first.  That is, having a way to
 initiate activities with (or change sharing scope to) a predefined contact
 list is the fundamental building block.  The chat and bboard
 functionalities are extensions of the group concept which provide the
 persistent collaboration space.  I'm not sure, offhand, which of these is
 more important in the near term.  As mentioned, I'm more interested in all
 of these at the private level for now.

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