Difference between revisions of "User:Dale Innis/Group IM in OGP"

From Second Life Wiki
Jump to navigation Jump to search
Line 83: Line 83:
* [[AW Groupies/Chat Logs/AWGroupies-2008-09-02|AW Groupies chatlog 2008/09/02]]
* [[AW Groupies/Chat Logs/AWGroupies-2008-09-02|AW Groupies chatlog 2008/09/02]]
* [[User:Zero_Linden/Office_Hours/2008_September_04|Zero Linden office hours chatlog 20080/09/04]]
* [[User:Zero_Linden/Office_Hours/2008_September_04|Zero Linden office hours chatlog 20080/09/04]]
* [[User:Saijanai_Kuhn/Gridnauts_irc-2008_09_14|Gridnauts irc transcript 2008/09/14]]


=See Also=
=See Also=

Revision as of 16:25, 14 September 2008

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

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?

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=91303"