User:Dale Innis/Group IM in OGP

This page is to capture thoughts about how Group IM will / should / might work in the Open Grid Protocol. It is seeded with some ideas extracted from recent Zero Linden office hours and AWGroupies meetings.

Group Definition

At this point it is not defined what groups exactly are in the Open Grid Protocol architecture. There are at least three possible group implementations to think of:

• RD wide groups
• AD wide groups
• Open Grid wide groups

RD groups are not likely to exist, since the Group IM features is most likely to be handled by the agent domain - still they might be a possible use case and thus be implemented as a specialization of AD groups (possibly with a filter).

Use Cases

• A group wants to do predefined-group IM very much like SL / OpenSim Group IM today, only cross-grid (cross-domain)
• A group wants to do adhoc-group IM (i.e. "Friends Conference") very much like SL / OpenSim Group IM today, only cross-grid (cross-domain)
• Bridging (in any of various detailed senses) between OGP-based Group IM in some virtual world domain(s), and group IM in other contexts (IRC channels on existing IRC servers, Jabber servers, AIM, etc, etc, etc)
• One-to-one IM as a limiting case of any and all of the above (i.e. can the various approaches to the Group IM use-cases also serve for person-to-person IM)
• Spatial chat (i.e. can any or all of the IM solutions above also handle spatial chat, where everyone within range can hear what's being said? The answer may be "no", or "yes, but it's not the best solution", or whatever)
• You are in a RD run, say, at your company for purposes of company research collaboration. You find one of your co-workers is on-line, but in some other sim, but in the research RD. You are in the middle of something where you are so you wish to IM her a question. I think you'd want that text to travel only with the RD servers, so that under those conditions, the company would feel secure that it is all "behind the firewall". So now the question is -- do we need to expose that the users in some way (I have to choose *how* to IM her) or is there a reasonable way we can route that automatically. We need a way, that if the ADs and RD agree, that an AV to AV, or even group IM, can go entirely via the RD. (From Zero, at 2008 Sept 04 Office Hours.)

Requirements

• In at least many use-cases, someone viewing a Group IM message should know with high confidence that it was really sent by the apparent sender.
• In at least some use-cases, it will be desirable to allow messages where the sender is *not* known with high confidence, but the messages are still delivered, and marked as insecure-sender.
• In at least many use-cases, someone posting a Group IM message should know with high confidence that it will be delivered only to bona fide group members.
• The solution should scale to, at the very least, simple extrapolations of the current SL group IM usage patterns.
• The solution should not require providing grid user credentials (username, password) to any agency besides the user's Agent Domain.
• The solution should not create a nonredundant single point of failure for the entire intragrid group IM system.

Approaches

• Sai suggests that, as a very first experiment and proof of concept, we move Group IM into the AD (Agent Domain), and allow inter-domain IMs by using the AD as a relay point.

see discussion page for more...Saijanai 17:15, 16 September 2008 (PDT)

• Various people have suggested that, as the underlying IM infrastructure, we make use of IRC or Jabber or something else that already exists. This still leaves open various questions, such as how identities are mapped and authentication done, but it has been suggested that these are easy to solve. We will attempt to extract from those making these suggestions just how they see it working. Preferably without violating the Geneva Convention.
  • Infinity suggests we investigate the possibility that for cross-grid interoperability, we include a way to get a reference to an existing IRC/{X|I}MPP/RTP/etc. gateway 'cause she things adding XMPP or whatever to OGP is a little heavy.
  • Dale says that that's fine, but we still gotta figure out and write how authentication to / through an existing gateway would work! And no one gets to say it's trivial unless they've describe the steps.
• It has of course been suggested that the underlying group IM mechanism be pluggable. This is a fine idea, but we must still define the interface that a qualifying plugin has to implement.

Specific thoughts on the applicability / scalability of existing IM systems

Jabber

In his Office Hours for 2008 Sept 04, Zero comments that Linden Labs looked at the possibility of using Jabber for SL Group IM traffic, and came to the conclusion it wouldn't scale according to their needs. This is due in particular to the large number of group IM sessions that each AV is potentially in at once, as well as the extremely large number of AVs in each group. They talked to a professional Jabber service provider, who estimated that scaling to SL levels would require lots of hardware and the provider's own proprietary extensions to the Jabber protocol.

IRC

IRC was also discussed at Zero Linden's Office Hours for 2008 Sept 04, and Zero stated that current IRC servers couldn't handle the load SL would put on them ("...IRC has the problem that the servers can't handle the number of group chat rooms that we have").

A Simple Design Example

Some preliminary thoughts on how an existing IM / group IM protocol, server, and client (libraries) might be used to satisfy the requirements of the use-cases, and implications for OGP.

In the simplest architecture, we take some existing IM / group IM protocol that uses a central logical server (probably implemented as a scalable cluster), and that includes username / password authentication (this is more likely to be available than a cap-based one).

Each participating AD registers each of its users with the central server, using a uniqueified version of the username (username_ADname or whatever), and a password that the AD generates and records internally for that user, as well as passing to the viewer. (The user's AD password is not used, to avoid exposing it to the central IM server, per the requirements above.) Note that the server has to be modified so that not just anyone can create the user DaleInnis_SecondLife; only the authenticated SecondLife AD can be allowed to do this.

When the user logs in or logs out, joins or leaves a group, or does a query for existing groups, the information flows directly between the viewer and the IM server, using the uniqueified username and the generated password; the AD is "copied" on information about what groups the user belongs to. Similarly actual messaging traffic flows between the IM server and the viewer, which acts like any other client for the IM system, presenting to the user a view of the IM activity that conforms to the overall UI to the VW in question.

In summary, the AD's only role is to generate and store a password, to register the user with the IM server when the user is first created (and presumably to deregister the user if the user leaves the AD), and to track the list of groups the user belongs to. All other information flows between the viewer and the IM server.

Where does this design fall short, what are the limitations and challenges?

• One problem is that the central IM server is a serious single point of failure for all IM. We can imagine instead that there are a potentially large number of IM servers (potentially one per AD, even), each handling some subset of the existing groups. (Each AD's own IM server, for instance, could handle the groups that are "native" to that AD.) The viewer and the AD would then co-operate to register the user with the IM servers corresponding to all of the groups that the user joins.
  • Finding out what groups exist is an issue here. One approach would be to provide easy access to the groups that are "native" to the IM server associated with the user's own AD, and (how?) allow the user to specifically ask what groups are available from other IM servers if the user knows their names.
• The existing IM server and protocol might not provide all of the functions that we expect of our group system. Would it provide "Busy"? Would it provide some form of Group Notices? (Or perhaps Group Notices would be done by another channel entirely.) Would it provide correctly for group ownership control, ejecting users from closed groups, and so on? (Need to add some of these to the design example.)
• Need to add group creation and deletion to this design. Does that introduce any fundamental complexities?

What requirements does this design place on OGP?

• To first order, only the communication between the viewer and the AD as to the list of groups that the user belongs to, and the generated password under which the user is registered with them. All other communication takes place over the relevant IM protocol, between the IM-client code in the viewer and the IM server.
• Anything else?

My own take is that the AD should be a relay point for messages from any given IM server. The IM server should send messages to the AD which then decides what to do with them. Someone else suggested that the client poll the AD for incoming messages, but either way, the relevant info concerning whether or not a given avatar is online should be local to the AD, and the server should never know (unless the AD provides notice caching as an optional service, in which case, if no avatar is online, the AD notifies the server of this fact, to reduce message traffic). Saijanai 02:48, 16 September 2008 (PDT)

Loosely related, further ramblings

Since this page was started there is news that should influence our thoughts on group messaging, messaging in general, and how it could (or should) be handled by future protocols.

• One of these news ist that LindenLabs announced a new lite viewer, "a lightweight, voice-enabled instant messaging client that will allow you to communicate with your Second Life friends without logging in to the full viewer. ". This is one way to deal with things and IMHO a good one, especially when it comes to the now technology-wise closed voice chat. Still, there should be a way to open text and voice chat to webservices suitable for furure needs, either exising ones (IRC, see above), or not yet existing ones (one idea here would be to SIP enable voice chat, but there are many more).

• The other news would be from Eric Reuters saying that "IBM showcases an integration of Sametime chat into 3D worlds" which would bridge text chat from Sametime into 3D worlds, most noteably Second Life. This again emphasizes that there is some use case for integration of ('plugable') (web) services to a variety of systems suited for content and community management.
  • As one of the researchers involved in Sametime 3D i just want to point out that Sametime 3D is about integrating virtual world technology into Sametime: that is you can turn a sametime chat session into a virtual world meeting. There is a chat "integration" between OpenSim (which we are using as underlying virtual world platform for Sametime 3D) and Sametime, but that is just to relay chat traffic from sametime to the OpenSim region and back (for those participants that are not joining the in-world meeting). And we are currently doing it via OpenSim's IRCBridgeModule... Dr Scofield 08:48, 27 September 2008 (PDT)

Some of the most relevant chat transcripts

• AW Groupies chatlog 2008/08/26
• AW Groupies chatlog 2008/09/02
• Zero Linden office hours chatlog 20080/09/04
• pyogp irc discussion in group IM 2008/09/14
• AW Groupies chatlog 2008/09/16
• Zero LInden office hours chatlog 2008/09/16

See Also

• AW_Groupies
• Protecting content in an open grid
• Open Grid Protocol
• SLGOGP_Teleport_Strawman (old?)
• OGP Trust Model
• OGP Trust Model Use Cases
• Proposed person-to-person IM flow in OpenSimulator (Teravus Ousley)
• Splitting OpenSim's Chat Module
• ImprovedInstantMessage spec