Difference between revisions of "User:Dale Innis/Group IM in OGP"
Jump to navigation
Jump to search
Dale Innis (talk | contribs) (→Jabber: See Also, and categories) |
|||
| Line 1: | Line 1: | ||
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. | 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). | |||
=Requirements= | =Requirements= | ||
Revision as of 11:31, 3 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).
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.
- 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.