[9:52] Morgaine Dinova: defers re-requesting "state of AD" info until after IM topic
[9:53] Saijanai Kuhn: Well, as far as I can tell, we can shoehorn any other messaging system into the IIM packet, so the only real issues are concerning that conection point
[9:53] Dahlia Trimble: I've looked at XMPP a bit but I can't seem to find an ecample where it's in use and serving more than 50-60 clients at a time for any one "room"
[9:54] Zha Ewry: Can we assume we'll replace that mess with a set of caps?
[9:54] Morgaine Dinova: Dahlia: the company backing ejabberd development tested XMPP with 1 million users.
[9:54] Saijanai Kuhn: oh yes. Infinity wanted to just go with UDP as an interum solution at one point and I'm like noooooo
[9:54] Dahlia Trimble: 1 milliion users, but hoe many n a single room?
[9:55] Morgaine Dinova: A mix, I'll try to find you the reference
[9:55] Dahlia Trimble: ejabberd seems to be the fastest implementation as far as I can see
[9:55] Morgaine Dinova: But any discussion about XMPP for IM currently founders on Zero's phrase "XMPP is a bad semantic fit for SL".
[9:56] Saijanai Kuhn: but again, as morgaine has said, the back-end is separate fromt eh front end. I can see various group IM servers getting merged at some point but all looking the same to the SL client
[9:56] Dahlia Trimble: I wasnt attempting to suggest that LL™ adopt xmpp
[9:57] Dahlia Trimble: rather I was investigating how it may fit with opensim
[9:57] Morgaine Dinova: Since Zero's statement hasn't been explained too well technically (to my liking), I'm not even sure if XMPP is actually non-viable or if it was just an excuse.
[9:57] Saijanai Kuhn: Dahlia, seems to me you'll hit the same issues as for SL
[9:59] Morgaine Dinova: That's why I'd quite like to talk to any Opensim devs that may have examined highly scalable IM. It's not a case of "just hack something in" --- LL did that, and it's not good.
[9:59] Saijanai Kuhn: checks his crystal ball to see who is actually on...
[9:59] Zha Ewry: Nobody has done it in OpenSim, Morgaine
[9:59] Lim Catteneo: Zha, group IM or agent-agent IM?
[9:59] Zha Ewry: Agent-agent is pretty simple in comparison
[10:00] Dahlia Trimble: the highest volume conversation I've found is #ubuntu on freenode, and it's typically over 1000 clients at one time, but it's IRC
[10:00] Morgaine Dinova: Zha: yesterday we had a discussion about it, and some suggested that some Opensim devs are at least *thinking* about it.
[10:00] Xugu Madison: Can we try finding a Jabber Eliza bot or something, put a few thousand in a "room" and tell them our day was terrible?
[10:00] Xugu Madison: ...see if it works, basically
[10:00] Rex Cronon: agent-agent would be even easier if it was p2p:)
[10:00] Saijanai Kuhn: A 1 million avatar room is a real world issue. Metanomics has been talking to Ira Flatow on how to implement it for Science Friday
[10:01] Lim Catteneo: Rex, firewalls wreck havoc on p2p
[10:01] Zha Ewry: Presence and keepign track of who is on inside a group, is the scale mess
[10:01] Zha Ewry: You end up with a lot of activity in the form of "John's now on at endopint x" if you don't watch it
[10:01] Saijanai Kuhn: Lim, reverse http-ptth can handle firewalls in theory
[10:01] Goldie Katsu: replicate presentations across multiple "shards" of islands with a relay system and bots for the copies of the original presenter.
[10:02] Zha Ewry: IRC, in the face of serious load partitions furiously
[10:02] Morgaine Dinova: Given the numbers we're working too, I think we may be going beyond current XMPP implementations. But my first concern is whether the MODEL of XMPP suits, because if it doesn't then it's pointless continuing down that road. And Zero has said it doesn't suit.
[10:03] Rex Cronon: what goldie says migh have a high chance of sucess at least for rooms of 100k, could even work for 1mill:)
[10:03] Zha Ewry: Well, I'd start with a basic question of what the model of a group IM session is, and nail down the scale points
[10:04] Morgaine Dinova: I have a second but equally important worry: that people are going to hack this into existing grid code, and hence end up with license non-interoperability. It should be an independent project, with LL and Opensim as no more than fully committed clients.
[10:05] Saijanai Kuhn: Morgaine, with OpenSIm being bsd and pyogp being apache v2 I think we will have at least 2 open references to the code
[10:06] Morgaine Dinova: But others will be GPL, so it's no-go.
[10:06] Morgaine Dinova: Whereas an independent project avoids that.
[10:06] Goldie Katsu: (looks like wow shards are about 8k active players - and that is across many separate regions)
[10:06] Xugu Madison: Could we use Jabber for avatar-avatar, and an IRC transport gateway (which I'm fairly certain Openfire has, for example) for group chat?
[10:07] Saijanai Kuhn: Xugu, I don't think its just messaging that is the holdup with SL group IM
[10:07] Lim Catteneo: Zha, if you think of group IM as an equivalent to IRC channel, the presence bit can then be handlend client side. On login, the client "joins" needed "channels" and displays in UI appropriatly when messages arrive
[10:07] Xugu Madison: Doesn't Jabber have enough presence support, or does it get too complex?
[10:07] Morgaine Dinova: Presence can be tracked as just the control part of group IM. It's essentially IM without data transport.
[10:08] Lim Catteneo: Morgaine, you neet to track presence somewhere
[10:08] Saijanai Kuhn: yeah, but there's a LOT of precence traffic for a single SL group
[10:08] Zha Ewry: watches as the puff os blue and pink smoke twirls encouraglinly
[10:09] Zha Ewry: and yes Lim, you clearly want to do that
[10:09] Morgaine Dinova: Tackling presence in IM is unavoidable: every presence change alters the coresponding messaging exploders. It's so strongly tied that it makes no sense handling presence separately.
[10:09] Saijanai Kuhn: Zha IIM packet is kinda a given for the near term just because of hte client interface coding issue (IMHO)
[10:09] Infinity Linden: YES. IIM will be replaced with LLSD/LLIDL via a Cap
[10:10] Saijanai Kuhn: right, but still that massive multi-purpose thingie, at least for a while...
[10:10] Infinity Linden: sure. IIM will be with us... probably for at least a year or so
[10:10] Dahlia Trimble: will it still be required to go through the current simulator?
[10:10] Saijanai Kuhn: Dahlia hoping we can get the connection points defined between AD and client instead
[10:11] Infinity Linden: that is... i can't imagine we would be able to agree on a design, implement it, test it, fix performance problems, give up and redesign, then retest and redeploy in less than a year
[10:11] Lim Catteneo: Dahlia, very good question, asked it many times, but there is still no one big overview of the OGP archicecture
[10:11] Saijanai Kuhn: Testing will take care of itself once pyogp matures a little bit. Enus has vissions of cloud computing pyogp with 10K avatars for testing
[10:11] Infinity Linden: right. there was some wrestling internally about the question "does the Agent Domain _really_ handle GroupIM?"
[10:12] Morgaine Dinova: In effect, IM will be a new Domain block --- IMD
[10:13] Zha Ewry: but th endpoint you use to deliver to. you want to be seperate from where you are in the grid
[10:13] Dahlia Trimble: well if for example it hands it off as a set of credentials to connect to a jabber serer
[10:13] Lim Catteneo: well we should be able to IM wihtout being rezzed :)
[10:13] Infinity Linden: Morgaine... it has the ability to become it's own domain, but the current plan of record is still to deploy it as part of the Agent Domain
[10:13] Infinity Linden: that's one of the reasons why authentication is distinct from the inital rez
[10:14] Infinity Linden: you can authenticate yourself, get the seed cap (which should contain a reference to your group IM cap) and just chat away without placing yourself anywhere
[10:14] Saijanai Kuhn: Infinity, seems to me that with multiple ADs that's really an implementation detail
[10:14] Infinity Linden: and one of my great hopes is to be able to implement this in JavaScript
[10:14] Infinity Linden: i'm looking forward to the day where this works without UDP/IIM
[10:14] Morgaine Dinova: Infi: it would be a bad move to put it in AD, because the AD will then not use service calls to it but take shortcuts, and hence won't be using the same service as Opensim.
[10:15] Saijanai Kuhn: tried to implement AD in ActionScript but too many issues with server authorization list
[10:15] Infinity Linden: implementaton is distinct from interface, Morgaine
[10:15] Rex Cronon: group IM in javascript, client side?
[10:15] Zha Ewry: to my mind, the AD is just providing the IM message delivery point for the burters
[10:15] Infinity Linden: right... i really want to be able to have a Google or Apple Dashboard widget that can do group IM
[10:16] Morgaine Dinova: Actually, if Infinity says it's going into AD, then it's a disaster project-wide, because it'll be impossible to implement it as a separate service to which LL and Opensim are just clients.
[10:18] Morgaine Dinova: Yeah, not Hypergrid, which is a lot more.
[10:18] Infinity Linden: gets rather embarassed about the "ease of extensibility" relating to the SL viewer
[10:19] Goldie Katsu: thinks about reinventing the wheel.
[10:19] Saijanai Kuhn: the GPL client needs a specialized GUI thing which means we need to leverage the interface that exists for IIM (for now)
[10:19] Goldie Katsu: Rather than creating new rims
[10:19] Saijanai Kuhn: Infinty, sorry. Still obsessed with that after trying to reuse folders for my keyword tree thingie...
[10:20] Infinity Linden: no seriously... if the OpenSim community wants to implement HyperGrid, they should implement HyperGrid. I'm just thinking there will be some people who want to operate an OpenSim instance thats interoperable with SL
[10:20] Saijanai Kuhn: Dale Glass knows how to do it, but I bounced off the class hierarchy
[10:20] Morgaine Dinova: So, Infinity, your answer means that you don't expect Opensim to create a scalable IM system and hence you're writing your own closed one, is that right?
[10:20] Infinity Linden: in which way is our interface closed?
[10:20] Goldie Katsu: Why are we having an IM that is separate from existing IM platforms?
[10:21] Goldie Katsu: or do we ned to add additional functionality to existing protocols to start to build cross functionality with the rest of the web.
[10:21] Lim Catteneo: sai, stop confusing things with gpl viewer interface talk :)
[10:21] Morgaine Dinova: OK, so let's ignore interface. I am talking about system code for a scalable IM.
[10:22] Saijanai Kuhn: thinks that is the point. Its confused, so we have to spearate things out in a workable way
[10:22] Morgaine Dinova: You propose to make a closed implementation of scalable IM, which Opensim cannot use
[10:22] Saijanai Kuhn: Morgaine, here is what I see us doing...
[10:22] Infinity Linden: for the record, there was a proposal floated that included an XMPP interface into the agent domain for external chat clients
[10:24] Xugu Madison: Good to know you looked at jabberd, thanks for clarifying there Infinity
[10:24] Infinity Linden: we all benefit from 1000 flowers blooming
[10:24] Dahlia Trimble: or could a future client maintain group IM while interacting with a standalone opensim region?
[10:24] Morgaine Dinova: You propose to make a closed implementation of scalable IM, which Opensim cannot use, instead they has to implement yet another one. Why?
[10:24] Saijanai Kuhn: Morgaine the only SL-relevant bit is the IIM packet part, to let the GPL client have a GUI without serious mods
[10:25] Infinity Linden: it will be so tightly dependent upon our architecture as to be virtually useless to anyone else
[10:25] Saijanai Kuhn: libsl or pyogp or anything else can be modded to use an entirely new interface, so this is really just a client <=connection=> issue, not a scalability one
[10:26] Zha Ewry: Long term, I am not unhappy, as long as we do it so that we can plug together multipe
[10:26] Zha Ewry: versions of code which meats the spec
[10:26] Infinity Linden: the fact of the matter is... the discussion about "just adopting XMPP" is over and done with
[10:26] Morgaine Dinova: Infinity: there is no need for it to be dependent on your architecture at all. Group IP and presence can be done portably.
[10:26] Zha Ewry: and get a web of IM which works properly
[10:26] Infinity Linden: we cannot (we believe) implement XMPP without some serious under the hood work
[10:26] Lim Catteneo: The way I imagine this working (using IRC terminology, not implying use of irc backend): You authenticate against AD which hands you a CAP for joining in "channels". Its up to the client at this point to "join", connect to these "channles" for which it got URLs. The act of "joining" a channel should allow group IM service to handle presence without needing to talk to central services, beyond initial authenitcation token validation.
[10:26] Infinity Linden: which makes us wonder... why are we doing this?
[10:27] Morgaine Dinova: We're doing it so that VW's IM isn't dead as a dodo.
[10:27] Saijanai Kuhn: Morgaine, can we agree, that for now, in order to keep SL in the loop, we have a SL viewer compatible connection protocol? anything else is up for discussion, but in ofrder to use the only viable fully functioning client right now, we need to keep an IIM connection poitn
[10:27] Infinity Linden: yup. and in an ideal world, the IM protocol endpoints could represent IRC, XMPP, SIMPLE, IIM or OGP IM
[10:28] Infinity Linden: but... in the near term... we're thinking our plan is to wrap a LLSD/LLIDL wrapper around our systems that currently implement IM
[10:28] Saijanai Kuhn: or all of the above or something entirely new
[10:28] Morgaine Dinova: Sai: OF COURSE we want SL compatibility. :-) The problem is that LL wants to hold tight onto IM instead of going for open IM + compatibility layer.
[10:28] Saijanai Kuhn: Morgaine I don't hink they are saying that
[10:29] Infinity Linden: Morgain... it's an open world... if you don't like our interface, just code another one
[10:29] Morgaine Dinova: By keeping the code proprietary within their AD, they are saying exactly that.
[10:29] Infinity Linden: nothing we're doing will prevent you from doing that
[10:29] Saijanai Kuhn: I think the "compatibilty layer" is the IMM XML-LLSD protocol between client and Ad
[10:29] Infinity Linden: i would actually like it if you did
[10:29] Infinity Linden: because the more ideas that can be demonstrated, the better
[10:30] Saijanai Kuhn: and once that connection poitn is defined for the AD, we can always test NEW protocols for connection, but just not (easily) with the GPL client
[10:30] Rex Cronon: how hard would it be to code an interface to whatever IM system ll decides to use?
[10:30] Morgaine Dinova: Infinity: but by keeping it closed, others can't use the same scalable IM back end, and the only eyeballs finding bugs in yours are LL eyeballs ---- which is a tragically short resource.
[10:30] Dahlia Trimble: could care less what LL™ uses *internally* for group IM, as long as it *works* :)
[10:30] Infinity Linden: and were I not logged in as Infinity Linden, i would point out the fact that it's much easier to prototype ideas using an open code base than to try to poke us to test things out on one of our dev grids
[10:34] Saijanai Kuhn: the IIM LLSD thing is just a convenience thing to get the GPL client workign with whatever new IM system is worked out
[10:34] Infinity Linden: because it allows us to decouple the deployment of the client that uses LLSD IM from any improved server IM implementation
[10:34] Saijanai Kuhn: its the compatibility layer Morgaine was talking about
[10:34] Morgaine Dinova: Infinity: 160k is a completely ridiculous figure to design to! The figures of [1] still stand, unless LL has climbed down massively.
[10:34] Infinity Linden: because IM is not the only service we're going to LLSDify
[10:35] Saijanai Kuhn: she did say (or more) Morgaine
[10:35] Morgaine Dinova: That's not massively scalable, that's toying at the edges.
[10:35] Rex Cronon: if you have 1mill users in group chat, u won't be able to read what people type, the text will scroll too fast
[10:35] Infinity Linden: anyone remember the bad old days when you had to download a new client each time we pushed out new sim code?
[10:36] Infinity Linden: Morgaine... the sad truth of large system development is that you tend to do a lot of incremental stop-gaps
[10:36] Infinity Linden: i've seen that at Linden as well as the phone system
[10:37] Infinity Linden: there was a time when the 5ESS's couldn't handle one tenth of their current capabilities
[10:37] Saijanai Kuhn: BUT, with a well-defined connection point, and independent Agent Domains, we can be workiong on multiple stopgap deigns at the same time
[10:37] Morgaine Dinova: Almost, but not quite: you design for the big picture, you roll out for the needs of today and tomorrow.
[10:37] Infinity Linden: yet we don't complain that AT&T screwed up in 1972 with SS7
[10:37] Zha Ewry: You define endpoints and scale design to make ti scale
[10:38] BlueWall Slade: maybe it would be helpful to design in a "near-instant-message" system to handle postings that do not need a reply to group IM?
[10:38] Zha Ewry: I don't care about people's insddes
[10:38] Zha Ewry: I care about the interfaces being right
[10:38] Zha Ewry: so we can compose up as good an inside as you want
[10:38] Infinity Linden: one key aspect here is that we need to separate the interface from the implementation
[10:39] Zha Ewry: and allow a mesh of multipel provdiers
[10:39] Infinity Linden: and... we need to plan to implement something "soon"
[10:39] Infinity Linden: what's the OpenSim IM protocol right now?
[10:40] Morgaine Dinova: So, perhaps we'd better ask ... what numbers are we designing to? Because if it's just a stopgap for the next year then it's a waste of time to set up a project for it. Just keep tinkering. :-)
[10:42] Infinity Linden: which, IMHO, is one of the reasons it's difficult to scale
[10:42] Zha Ewry: Crossing OSI layers is always painful and to be avoided when you can
[10:42] Morgaine Dinova: Well you have to look at the engineering tradeoffs. Just because some of us have an aversion to XML is not a valid reason for dismissing it.
[10:47] Zha Ewry: has at variosu times done OMG, W3C, JCP, OASIS and IETF work
[10:47] Lim Catteneo: its like saying plague is better than collera :P
[10:47] Infinity Linden: mm... there seems to be a disconnect between the hard-core REST folks and the SOA folks these days
[10:47] Morgaine Dinova: I'll stack specific technology advocates up in a heap, and light the match :-)
[10:48] Infinity Linden: i suspect it might just be a community thing.. it seems like the SOA crowd are more into process than the RESTafarians
[10:48] Zha Ewry: Well, until you've actuall shipped a product built around an interoperabel standard, and had it worked against another companies implementation
[10:49] Lim Catteneo: Infinity, is there appetite at the Lab to allow client to connect to more than one service. Ie. abandon current way of having sim be the grand proxy?
[10:52] Morgaine Dinova: That defines the bodies of REST messages, right?
[10:52] Infinity Linden: but we figured people thinking we were trying to reinvent CORBA IDL was better than people thinking we were trying to reinvent ASN.1
[10:56] Morgaine Dinova: Cool. So, we've got the REST envelopes, we've got the contents of messages defined (at an early stage), now where are the nouns? Ie. do we know what resources we're manipulating?
[10:56] Infinity Linden: @Lim... yeah. that's what we were thinking too
[10:57] Infinity Linden: the nouns are defined in the LLIDL of the resource description
[10:57] Lim Catteneo: likes the goal of eventually being able to do with javascripts's httpRequest :)
[11:01] Saijanai Kuhn: @ Infinity adn Morgaine: seems to me that just because we're using IIM for the GPL client, doesn't mean we can't start experimenting with better factored messages on the non-GPL client, and once those become matjure, bring them back into the gPL CLIENT
[11:04] Zha Ewry: Saij.. can you turn off the recorder?
[11:04] Morgaine Dinova: It would require LL to interface their prototype REST-based IM service into the live one though. Then we could tack on using the REST interface as an alternative to the current IM interface.