[9:40] Dale Innis: Phaps there are two different questions: underlying mechanism (IRC or Jabber or whatever as long as it scales) and trust. How do we make sure that only people in the whatever group can read #whatever?
[9:40] Dale Innis: How do we prevent identity spoofing? etc.
[9:40] Gareth Ellison: spoofing in IRC is a solved problem and has been for al ong time
[9:43] Tao Takashi: nicks are different maybe, these can be obtained by asking for more information
[9:44] Dale Innis: The viewer is the end client app.
[9:44] Tao Takashi: and might look like Tao Takashi@syntronik.de
[9:44] Zha Ewry: I will warn people I am still on the jet lagged side
[9:44] Gareth Ellison: remember the IRC transport is only for group chat or inter-user IM on the current system, but you could have inter-user IM on some other protocol and only group chat on IRC
[9:44] Gareth Ellison: hands zha a selection of the contents of her cupboard
[9:44] IntLibber Brautigan: well ideally we need to have domains point to grids like grid.intsgrid.com, and gridserver email servers that allow email addys like firstname.lastname@intsgrid.com
[9:44] Tao Takashi: Zha: we make sure you don't sign the proposed spec just now :)
[9:44] Movies1963 Beck: Zha that's the price you pay for being a rock star
[9:44] Gareth Ellison: you know what i keep in there zha ;)
[9:44] Movies1963 Beck: your right up there with Dee Snider from Twisted Sister
[9:46] Zha Ewry: well, if we're truely being REST and sane.. then, yes, grids are nbothign more than collection of closely relate dweb services
[9:46] Gareth Ellison: zha - looking at absolutely everything through HTTP glasses - is it really needed?
[9:46] IntLibber Brautigan: hi tess, we haven't been introduced but this is nice
[9:47] Tao Takashi: I basically would like the AD to be some sort of master server which knows when you are online etc. and does some handshaking and other services being losely grouped around it
[9:50] Tao Takashi: but the AD might need some interface which can inform services (which know about it) about avatar details etc.
[9:50] Gareth Ellison: there's no RequestTextureDownload cap on the agni sims
[9:50] Gareth Ellison: anyway, downloads are good on HTTP
[9:50] Gareth Ellison: realtime 2-way discussion amongst groups of users, not so good
[9:50] Tao Takashi: and if we use IRC it might be nice if you could also connect with a normal IRC client.. this might then look different in an OGP viewer though
[9:51] Gareth Ellison: get a cap with an IRC server address from your agent domain
[9:51] Dale Innis: Gareth, we really got to get you to write down the design, rather than just chatting it during meetings. :)
[9:51] Tao Takashi: there is probably a way without caps ;_)
[9:52] Gareth Ellison: dale - i write it down in neural ink
[9:52] Tammy Nowotny: is there ant danger of intrenet providers trying to kill off IRC, like they are doing with usenet at the moment (althoiugh usenet is probably not needed for our work. LOL.)
[9:52] Gareth Ellison: tao - yeah, but you could put it in caps if needed
[9:54] Tao Takashi: I think it was in the context of email to openid mapping
[9:54] IntLibber Brautigan: btw I'd like to bring up something people need to think about to improve performance: caching recent sims visited. SL military groups have determined that the main source of lag in their combat operations comes purely from avatars being killed, tpd home, then tping back and having to redownload the whole sim all over again. is there a way we can enable sim caching of recently visited sims? This would obviously improve performance for more uses other than just combat games.
[9:54] Gareth Ellison: goes to hijack an IRCD dev and try to get the fastest SL client download and login ever
[9:55] Dale Innis: IntLibber: that sounds like viewer issue? Not really for this group.
[9:55] Zha Ewry: has anyone actually looked at how IRC scales in the slightly odd scenarios SL presents?
[9:55] Tao Takashi: SRV records also seem to be hard to maintain as putting up a textfile for service discovery seems easier than contacting your ISP
[9:55] Tao Takashi: depending on your setup of course
[9:55] Gareth Ellison: zha - group chats are IRC channels
[10:01] Saijanai Kuhn: which is why I want to see the current system brought into the OGP, even if only on a trial basis. We know what its supposed to do. We know how badly it behves in certain conditions. Can we change that?
[10:02] Zha Ewry: One of the things we see repeatedly, is that SL doesn't follow normal usage patterns.
[10:02] Tao Takashi: but is that also true for Group chat?
[10:02] Gareth Ellison: hands up how many people have been pissed off at the current group chat's random failures and "error messaging" 10 minutes later
[10:12] Tao Takashi: as for IRC you usually have this huge base of people idling.. but they are still in the room because of sometimes a good topic pops up they engage in the discussion
[10:12] Gareth Ellison: notes something with live music - it works way better with voice chat
[10:12] Dale Innis: would like to point out again that "use IRC" or "use Jabber" still leaves alot to be worked out and verified.
[10:12] JayR Cela: ok who is the idiot with the live mic?
[10:12] Latha Serevi: I'm wondering, if we have a pluggable IRC-or-other group chat service ... how we would use the service in OGP-land. Do you auto-join all group chats when you login? Is group membership a capability held by the client or by the AD?
[10:12] Tammy Nowotny: who is playing metallica in here?
[10:15] Dale Innis: So I think we should (a) write down IM requirements for OGP, (b) see if IRC etc meet them and how much glue would be involved, and (c) figure out what would be needed for Sai's most simplest experiment.
[10:16] Lillie Yifu: A group on the AD should have a set of contact methods. When an agent logs into the AD, their list of contact methods can be matched with the group. So for example, if a group uses AOL as it's group chat method, and the agent hs an AOL, and relased that to the group, then the agent could be given the information needed to log into the group's AOL
[10:16] Dale Innis: And do that on the WIki, not interspresed in chat with music reviews. :)
[10:16] Tao Takashi: a group itself could again have e.g. some XRDS document for service discovery
[10:17] JayR Cela: i could not even find burning life on it
[10:17] Tao Takashi: Gareth: I am not saying everything needs to be implemented but that way some winner might emerge
[10:17] Dale Innis: The AWG parts of the Wiki are pretty usable; what problems have you been having?
[10:17] Lillie Yifu: aso could have voice, video or other communications services, for example whiteboarding.
[10:17] Latha Serevi: Gareth, thanks for a specific example model. Yours doesn't have any security, I notice. Question, does IRC have any ability to restrict channel use to a member list?
[10:17] Gareth Ellison: what if i have a viewer with IRC support but no AIM support, and group X only does AIM
[10:18] Lillie Yifu: Gareth --> that's a service iscovery, the viewer says "I have IRC I am willing to tell you about." "Group says, sorry I only take AOL."
[10:19] Tao Takashi: a group will have a URI, you send the Accept: xrds header with it and you get the XRDS document which lists all the services available
[10:19] Gareth Ellison: latha if it's on the agent domain, you send it your password
[10:19] JayR Cela: screw the LL implementation ofGrioup IRC
[10:22] Latha Serevi: Oh, OK, I'm starting to get Gareth's model. AD runs an IRC relay and can mediate it. So, all AD's of all group members would be part of an IRC net, I guess. I wonder how they would determine what new nodes to add.
[10:22] Gareth Ellison: and nobdoy else can spoof staff.litesim.com
[10:22] JayR Cela: Zha / this is true / but LL and their track record with group IM has proven to be spotty at best
[10:22] Zha Ewry: Tha puts nickserve on the scaling path, which is noe mor ething to think abotu
[10:23] Bartholomew Kleiber: lol, I just had - for the first time - a group chat timeout.
[10:23] Latha Serevi: Tao, why do you want to "get around" caps? I thought they were the cool new thing?
[10:23] Dale Innis: Many providers will not want to outsource their group IM to (say) Nickserv. We have to have models where the AD owner owns more of the resources.
[10:23] Tao Takashi: Latha: maybe in SL but outside SL nobody understands them, no web framework supports them, you need some proxy or other complex setup (or some trickery) and all in all it makes this protocol hard to adopt
[10:27] JayR Cela: i cant begin to tell yuou how many groups i have left because of group chat / mindless chatter
[10:27] Tess Linden: We do have a design to revamp group chat reusing as much of the current architecture as we can, but if OGP is going to support plugin ones, then we should discuss how that'll work
[10:27] Tammy Nowotny: I wish you cd mute indivduals on a grpup chat channel
[10:27] Gareth Ellison: tess - what's that design look like?
[10:27] Dale Innis: Is there a description of either the current arch or the proposed new one for Group IM, Tess?
[10:28] JayR Cela: @tess / answer to that probem seems fairly straightforward....
[10:28] Tess Linden: Gareth: it has to do with what ways we hash group ids and agent ids
[10:28] Tao Takashi: I think there also should be some separation between the "talk groups" and the groups which you need for maintaining land and such
[10:28] JayR Cela: use an Oen Source / cross platform plug-in
[10:28] Tess Linden: Gareth: Sean is the author of that design, I would grab him for details
[10:28] Gareth Ellison: anyone in the AWG group chat right now? see my double lol
[10:29] Gareth Ellison: screwed up ordering of chat and bad lag
[10:29] Zha Ewry: Can we get Sean to stop by and give us a rundown of his thinking?
[10:29] Dale Innis: Isn't grabbing Lindens a ToS violation? :)
[10:42] Tao Takashi: so OGP should then enable also something like Gareth's ideas. The big question is then how we can make it so while also supporting different models. And that's your homework! ;-)
[10:42] Dale Innis: volunteers to start a Wiki page, since no one else is going to. :P
[10:42] Tao Takashi: as said, for me the wiki usually is too slow to be usable for anything productive
[10:42] Zha Ewry: I think that, on the whole, plugability is fine, but .. that it's not a pure answe for the problem
[10:43] Tao Takashi: well, of course we also need to add one default method to use now
[10:43] Dale Innis: And we should pay attention to Sai's suggestion to just try the minimal thing and see what happens.
[10:44] Gareth Ellison: move the current chat system to be purely agent domain... that would require having none-HTTP components in the agent domain
[10:45] Tao Takashi: but even if we keep some sort of the current system in an enhanced way we might still want to have some plugin method on top
[10:45] Dale Innis: I'd love to see a writeup of exactly how to do it via IRC. But no one loves the poor Wiki.
[10:45] Latha Serevi: Regarding all those uses for gruop membership, what about the suggestion of separating out insecure-group-chat from the other set of uses for secure-group-membership as capability? Then, we could consider having one OGP mechanism for managing secure-group-membership, and using it for pretty much every trust group and authentication issue, including what AD's are trusted to rezz objects by a given RD, etc.
[10:46] Dale Innis: Group chat has to be secure also.
[10:46] Gareth Ellison: KISSARSE - Keep It Simple Stupid And Request STandard Environments
[10:47] Gareth Ellison: you can enforce that authentication is needed to connect
[10:47] Gareth Ellison: that's a standard option on most IRCDs
[10:48] Latha Serevi: We're trying to define OGP for a variety of needs, Dale, including bridges to other non-SL environments. A major use case is "connect with a group of chatters in an incompatible system, and I don't care so much about security" -- and this is a way easier bridge to make than a secure one, perhaps
[10:50] Latha Serevi: Well, I was just trying to see if there were two distinct cases -- super-secure-groups-standing-in-for-capabilities, and super-insecure-groups-standing-in-for-unregistered-IRC-channnels.
[10:51] Gareth Ellison: and all users would identify to nickserv
[10:51] Graph Weymann: you could have a widget in the region that bridges to IRC
[10:51] JayR Cela: so while you all babble about something as silly as this i am leaving
[10:51] Tao Takashi: there is a chatwindow between us
[10:51] Zha Ewry: ( I mostly had internet access the whole time but oddly was vqacatinf)
[10:51] Gareth Ellison: perhaps zha would register with chanserv
[10:51] Dale Innis: i.e. all this "virtual worlds" stuff shold really just be a text chatroom, eh? lol
[10:52] Latha Serevi: Gareth, oh, I forgot about spatial chat altogether! Good point, can we think of a model for how to implement spatial chat inside a group chat mechanism (e.g. gruop is sim, filtered on client side by distance) ?
[10:52] Tao Takashi: for such meetings I would say "yes" ;-)
[10:54] Latha Serevi: Graph, I mostly agree -- except if performance is not an issue for chat, and we could turn two separate implementations into one.
[10:58] Tao Takashi: I guess it's sort of hard to define all this right now.. but it would be nice if OGP would have the extension points needed for experiments
[10:58] Tammy Nowotny: if yoiu let objects do LLregionsSay() on open chat
[10:58] Gareth Ellison: my model little python on my desk just fell over :(
[10:58] Bartholomew Kleiber: Gareth, could you throw your notes over to Dale or me?
[10:59] Gareth Ellison: i'll get some together and throw them at dale
[10:59] Latha Serevi: Question, does anyone anticipate spatial-chat being very high bandwidth, same order of magnitude as position-updates? Or might I get away with imagining it being less bandwidth-intensive in most cases, so we might use a less bandwidth-optimizing means for it? Or am I forgetting about, say, widespread use of object-chat as a requirement? Objects typically can't join groups, but they can local-chat. Hmm.
[10:59] Dale Innis: Or stick them in the Wiki. :) But at me is fine too. DaleInnisEmail@gmail.com or whatelver.
[10:59] Tao Takashi: Barth: btw, I will try to write the second part of the trust blog post tomorrow or thursday
[11:00] Bartholomew Kleiber: I was going to ask that ( bad conscience on my part)
[11:00] Dale Innis: I stuck the Wiki pionters in as a comment on that post. :)
[11:00] Tao Takashi: at least I managed to publich part 1 ;-)
[11:01] Dale Innis: To Infinity's pages on trust and all.
[11:01] Latha Serevi: Gareth, thanks for the interesting IRC stuff today. Sounds like definitely one thing we should consider is to shove as much as possible into IRC and see how that looks.
[11:01] Tao Takashi: cool, Dale, I was thinking I mentioned it.. but it might be in part 2
[11:01] Tao Takashi: where I refer to the stakeholders