User:Dale Innis/Group IM in OGP

From Second Life Wiki
< User:Dale Innis
Revision as of 08:31, 16 September 2008 by Xugu Madison (talk | contribs) (Corrected statements about Jabber (mis-attributed to IRC) and added Zero's statement on IRC)
Jump to navigation Jump to search

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

implement current group IM in the Agent Domain as the behavioral use-case for any new architecture

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

This would allow us to test not only group IM functionality, but inventory exchange, group notices, the concept of region vs agent domain vs universal groups, etc., while working on better design(s).

My idea is to simply use a cap obtained via the Agent Domain seed cap , to receive group IM messages ala the current ImrpovedInstantMessages packet. We could establish a separate pipe for sending IM messages TO the Agent Domain as well (this brings up an interesting point: is it more efficent to use the long-poll to recieve group messages in a "pull" scenario instead of using the reverse http "push" strategy?).

Seems to me that implementing the current group message handling in OGP would be relatively trivial: just use the AD as the unchanging connection poitn for sending/receiving IIM packets and modify the OGP group IM server to always send to the AD rather than to the sim where the agent is currently rezzed. More specialized behavior on the part of the AD/IM server interactions could be tweaked behind the scenes without changing the protocols at all, and with (I hope) only minimal changes required at first for the group IM server AND the client: just disable switching connections when the avie changes sims, and treat the AD as a simulator from the IM server's perspective AND the client's perspective (for now).

As we get more familiar with how even THIS minor change works, we can start playign with new ways of sending/receiving gorup IM, such as irc or jabber or xmpp, but keep the connection poitns the same between client and AD. Perhaps a wrapper for the IIM packet could be devised to identify WHICH kind and source of group IM was being used to serve the packets). Just some thoughts. Saijanai 13:15, 15 September 2008 (PDT)

I want to emphasize that this is mean as a temporary thing, not THE OGP design, and probably shouldn't be part of the OGP spec--perhaps an interim spec meant only for protocols expected to exist only during testing.Saijanai 13:41, 15 September 2008 (PDT)

etc

  • 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

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.

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

Some of the most relevant chat transcripts

See Also

Retrieved from "https://wiki.secondlife.com/w/index.php?title=User:Dale_Innis/Group_IM_in_OGP&oldid=91529"