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.

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

Using the AD as a simple relay

Thoughts on the interface to a general plugin

Specific thoughts on the applicability / scalability of existing IM systems

IRC

(In his [https://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/2008_September_04 Office Hours for 2008 Sept 04, Zero comments that they looked at the requirements of using IRC for SL Group IM traffic, and due in particular to the large number of group IMs that each AV is potentially in at once, even a professional IRC service provider estimated that scaling to SL levels would require lots of hardware. Not initially clear how the scalability compares to any other, non-IRC, approach, but it seems that this would at least potentially be a strain on existing IRC infrastructures.)

Jabber

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.

User:Dale Innis/Group IM in OGP

Contents