[discussion] Group support in gabble and salut

[kimquirk]

Need to get the work effort that is needed for supporting groups in salut and gabble. This requires some discussion with Sugar/UI as well. This trac issue is to start the discussion on development effort needed.

[smcv]

We can't really comment on the implementation difficulty of "groups" in Salut/Gabble without some idea what the UI/concept requires from us. Adding Cc Eben (for UI/requirements) and walter (since he seems to have some interest in groups).

If a less generic name could be chosen, that might be helpful, since Telepathy already has at least two concepts called "group". If you can't come up with anything more specific we'll call it an "OLPC group" or something when designing the API. On the other hand, depending on your definition of "group", we may need to split it into several orthogonal concepts at the API level.

Discussion already started in #3310. In the comments on that bug I explained what primitives are available without additional server support (= more easily).

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?

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?

* 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?

* 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)

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

* 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?

* 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?

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

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

(In each case, the obvious assumption about "which option is harder to implement?" is probably right.)

[daf]

Groups

* are mutual -- their membership is shared rather than personal

* should work offline

* have contacts in them

I'm not sure about who should be able to see group membership. I can imagine cases for both private and public membership; perhaps we need both.

We were thinking of storing group information using affiliations to a persistent MUC on the XMPP server.

I think this ticket is more about discussion than implementation; the implementation is not to be finished for 1.0.

[robot101]

I'd suggest "Community" as a less overloaded term. It implies a gathering of people, usually with some common interest, whereas group confers other (different) meanings in Telepathy, XMPP, UNIX, not to mention in mathematics... :)

[Eben]

Replying to 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.

[Eben]

Replying to robot101:

I'd suggest "Community" as a less overloaded term. It implies a gathering of people, usually with some common interest, whereas group confers other (different) meanings in Telepathy, XMPP, UNIX, not to mention in mathematics... :)

While community is a nicer term, it's also loosely synonymous with "neighborhood", which could be confusing. I'll have to think about this issue some more.

[daf]

I think there will be less confusion overall if we keep the "group" name rather than inventing a new term. We can always refer to them as "OLPC groups" to disambiguate them from any other kind of group.

[smcv]

Some thoughts on implementation:

Given what Eben has said, Telepathy's HANDLE_TYPE_GROUP isn't a suitable representation for OLPC groups, so we won't be using that. (It models XMPP roster groups, which are private tags placed on a user's buddies by the user - completely different.)

Representing OLPC-groups by XMPP server MUC chatroom affiliations seems a sane mapping; this would automatically give us (A) a chatroom per OLPC-group and (B) convenient server-side storage.

This would mean that each MUC is either an activity, or an OLPC-group, or a non-OLPC chatroom (we don't really support the latter very well on OLPC, but they exist and we have to think about them, if only to say "unsupported").

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@… rather than Class.3a@….

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.

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

The bboard file-sharing could be implemented with Tubes or file transfers in the OLPC-group's MUC, and/or with some sort of online file storage.

The desired membership of the OLPC-group will have to be cached in the XO (probably in the PS) for offline use, with changes pushed to the server when we go online.

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.

[Eben]

Replying to 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@… rather than Class.3a@…. 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.