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)

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.

See Also

• AW_Groupies
• AW Groupies protocol from 2008/09/02 (dealing with Group IM issues)
• Protecting content in an open grid
• Open Grid Protocol
• SLGOGP_Teleport_Strawman (old?)
• OGP Trust Model
• OGP Trust Model Use Cases

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.