#3310 NORM First D: Groups: when you are sharing an activity in a group, there is a chat for the group

[Zarro Boogs per Child]

#3310: Groups: when you are sharing an activity in a group, there is a chat for
the group
-------------------------------+--------------------------------------------
  Reporter:  kimquirk          |       Owner:  Eben                  
      Type:  task              |      Status:  new                   
  Priority:  normal            |   Milestone:  First Deployment, V1.0
 Component:  interface-design  |     Version:                        
Resolution:                    |    Keywords:                        
  Verified:  0                 |  
-------------------------------+--------------------------------------------

Comment(by smcv):

 I'll reiterate that we already have a chatroom per activity (for Tubes),
 so if you want it, per-activity text chat is very cheap (obviously the UI
 code needs to be written, but the PS and Telepathy components wouldn't
 need any changes). It sends unformatted plain-text messages, similar to
 IRC. If you decide you need per-group chat too, there'd be nothing to stop
 you having both per-group and per-activity.

 > Having persistent group chats would really amount to having something
 equivalent to an IRC channel for the group

 If you want to be able to share things (perhaps files) with a group,
 that's an argument in favour of the groups being implemented as (perhaps
 invite-only) chatrooms on the server.

 In case it helps to inform design decisions, here are the primitives that
 we have in the underlying protocols:

  * contact: an account on the server, or a _presence._tcp mDNS record on
 Salut. We map these to OLPC Buddies. Each contact can give themselves a
 limited amount of arbitrary metadata which is passed on to everyone who
 can see their presence (see below). Additionally, contacts can send each
 other arbitrary one-off messages, including text messages, Tubes and
 whatever protocol extensions we care to devise.

  * chat room: a chat room similar to an IRC channel. Gabble implements
 these as MUCs (XMPP multi-user chat) on the server, Salut implements these
 as something deliberately similar to a MUC using Sjoerd's "reliable
 multicast" protocol. We currently map all of these to OLPC Activities, but
 that could be changed. Everyone in a chat room receives all messages sent
 to the chat room; these include text messages used for chat, Tubes
 messages, or anything else we want to pass around (the protocol is
 extensible). Nobody not in the chat room receives these messages (in
 particular, contacts who have been invited to a room but have not joined
 it yet don't get the messages). Some chatrooms on Gabble are invite-only
 (enforced by the server, which relays invitations) and some can be joined
 by anyone. Chat rooms on Gabble, by default, disappear when everyone
 leaves, but they can be configured to be persistent. Chat rooms on Salut
 always disappear when everyone leaves.

  * contact list: there are two of these, 'publish' (the list of people who
 can see your presence, i.e. when you're online) and 'subscribe' (the list
 of people whose presence you want to see). On Gabble these represent the
 XMPP roster (the server has a hack to put everyone on the server on
 everyone else's roster, although you can also add people on different
 servers), on Salut these always both contain everyone you can see locally
 (and you can't change them).

  * contact group (only exists on Gabble): a user-defined group of
 contacts. Contacts can be in no groups, or in more than one group, so this
 is basically equivalent to each user being able to assign arbitrary
 Unicode tags to each contact they know about. Assuming the server isn't
 compromised, nobody can see or change the tags the user has assigned to
 others, except the user themselves. Salut does not implement this concept,
 and we don't use it on OLPC, but Gabble supports it.

 There are no others (that I can think of). Anything beyond these would
 require extensive modifications to be made to the server (ejabberd), which
 is likely to be difficult (we don't have any Erlang experts here) and
 reduces the potential for interoperability with non-OLPCs, so there's a
 strong incentive to stick to these primitives.

-- 
Ticket URL: <https://dev.laptop.org/ticket/3310#comment:4>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system