User talk:Dale Innis/Group IM in OGP

Comments from Xugu:

• Comments from Zero about Jabber were mis-attributed as being about IRC. Corrected, and statement about IRC added.
• Would anyone object to adding a requirement that the protocol can handle encrypted IM traffic, even if that handling basically involves ensuring that IM traffic can be passed through as binary without the protocol trying to decipher it as a character set.

Xugu Madison 17:33, 16 September 2008 (BST)

Well, the easiest thing to do would be to pass an encrypted cap to the client through the viewer, that requires a PGP key to unlock. The AD can't do man-in-the-middle attacks on something when it can't tell what the connection points are.

Saijanai 17:09, 16 September 2008 (PDT)

Comments from Lillie:

• Strongly disagree about RD groups not existing. There are a number of use cases for IMs being RD, including scripts, since IM is an means of communication.
• There's no reason to involve the AD in all Group IM.
• RDs may or may not want to expose land management to the AD, one current function of groups, and there fore possibly of group IMs.
• Use case, agent/object communication. Objects can currently IM agents. They should be able to IM groups that they are a member of, and should be able to receive IMs. A particular Grid may opt not to allow agent/object, object/object IMs, but it is something that many people want, and should be supportable by, the protocol and design.

• Requirements should include that the solution corrects the current time delay problems, or at least dramatically improves time performance.
• Requirements should include that the solution dramatically improves the current failure rate of message sending, as well as the number of false positive error messages.
• Requirements should include encryption as a possibility.
• Requirements should include that the system be able to send arbitrary streams, including text, sound, video, or any other binary stream of data. (e.g. whiteboard e.g. midi e.g. cap)
• Requirements should include that group management be able to read group capabilities. (i.e. some group members can send IM, others cannot.)
• Requirements should include that messages be marked for delivery only to online agents, or will be delivered as soon as an agent logs in.

Lillie Yifu 04:48, 16 September 2008 (PDT)

Lillie, I think that whiteboard and the like would require a P2P solution, which COULD be implemented, but isn't strictly part of standard group IM, IMHO. Saijanai 17:11, 16 September 2008 (PDT)

Comments from Saijanai:

• Implementing the current gorup IM in OGP 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.

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 17:19, 16 September 2008 (PDT)