Need a design for per-activity chat

[kimquirk]

This is Walter's feature request -- a group chat should always be available when activities are shared. If groups get delayed beyond frs, this bug should also be delayed.

[smcv]

Is this the same as having some sort of integrated one-chatroom-per-activity provided by the framework, or is this something else entirely?

Presence Service provides a text channel (chat room) for each activity; this is needed for Tubes, but the idea was that this would also be used for some sort of overlay or sidebar chat implemented in the sugar.activity library. At the moment, the only activity which uses this text channel is Chat (everything else just ignores it), but it'd make many activities much more useful (I was trying out Web earlier today and thought it'd be much better with some sort of chat, for instance).

On the other hand, if you want to have a chatroom per "group", where a "group" is some nebulous entity like "Class 3b" or "My friends", then we'd need to write quite a lot of code in Presence Service to support this.

Would per-activity chat meet your requirements? If so, it should just require a UI for existing PS functionality to be designed and implemented, probably by adapting code from Chat; the current PS could probably be left untouched.

[Eben]

Replying to smcv:

Is this the same as having some sort of integrated one-chatroom-per-activity provided by the framework, or is this something else entirely? Presence Service provides a text channel (chat room) for each activity; this is needed for Tubes, but the idea was that this would also be used for some sort of overlay or sidebar chat implemented in the sugar.activity library. At the moment, the only activity which uses this text channel is Chat (everything else just ignores it), but it'd make many activities much more useful (I was trying out Web earlier today and thought it'd be much better with some sort of chat, for instance).

This is a really big part of it...

On the other hand, if you want to have a chatroom per "group", where a "group" is some nebulous entity like "Class 3b" or "My friends", then we'd need to write quite a lot of code in Presence Service to support this.

...but considering the ways which we've been considering introducing it at the interaction level, it may make more sense if the chat is always around the "group" regardless of whether or not that group is a temporary one around an activity or not.

Would per-activity chat meet your requirements? If so, it should just require a UI for existing PS functionality to be designed and implemented, probably by adapting code from Chat; the current PS could probably be left untouched.

Per activity chat would obviously be a huge leap forward, making collaborations around activities that much more meaningful. Having persistent group chats would really amount to having something equivalent to an IRC channel for the group. We should get a better idea of exactly how hard these two options are if that needs to inform the design decisions in the coming months.

[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.

[Eben]

I'm pretty sure Groups won't be around until 1.1 or later.

[smcv]

Adding keyword collaboration so our Trac bookmarks will keep track of it.

[bemasc]

Eben: This feature should go into the new Sugar design, before it's all frozen and implemented. This feature has exactly zero dependence on any "groups" feature, and will be trivial to implement apart from pure UI.

You should also consider the question of pervasive per-activity voice chat ("push to talk").

[Eben]

I wanted to state our current design direction, for the record. We're leaning towards focusing efforts solely on per-activity chat (with the assumption that a "nebulous group chat" will be covered by an actual chat activity, once we add groups, which is independent for the purposes of this ticket).

We'd like to integrate the chat with the presence indication in the Frame, which manifests itself as the people list. I've included a really rough mockup of what this could look like, rendering the bubbles (boxes) in the XO color and positioning them relative to the position of the XO within the Frame. Of note, this is designed to be a non-persistent chat interface; there is no scrollback buffer, and anything missed will never be seen. There are a number of questions to be asked, such as:

1. Does the chat appear 1-1 along with the Frame, or is there a way to make it stick as visible above the activity even when the Frame is hidden? We do have that unused button next to the Frame, which could be useful...
2. How do we handle long messages (and do we impose a hard cap)? Can we have a fixed limit on the width of the message by default, and then expand the window to show the full message on rollover?
3. If we have a way to make the chat a persistent overlay, can we make the window event-transparent, so that it doesn't get in the way of interacting with the activity beneath?
4. How do you create a message? Do you have to invoke the frame and click on your own buddy to get an input field? Is there a shortcut? Is there a "reply" button within the other bubbles so it's easy to respond?
5. Do we add a module to the control panel for setting things like a) the default width for messages before expansion b) how long the messages appear for ?

Also of note, this visual approach opens up the door to future groups/neighborhood chat implementations which place colored bubbles within those views directly, which could be rather fun.

Feedback is appreciated! I'm working on pulling together some better examples to post to the Designs section of the wiki. Since the underlying framework is already there, it might be possible to have a volunteer hack this into existence in the not too distant future.

[HoboPrimate]

Beautiful idea! Looking forward for the mockups in the wiki to comment (I have a few already, but I'm not sure here is the best way, as the sugar team then gets confused on what they should actually program to. :) Just one quick one, having the scrollback of within-activity discussion would be something usefull to have, especially when you think that this is discussion that happens around a collaboration (when did we decide this? Or why?).

[gregorio]

Milestone FutureFeatures deleted