[9:43] FWord Utorid: pushes the button that makes everyone start complaining at the same time, labeled 'semantics'
[9:43] Teravus Ousley: Well, the latest incarnation.. is the work on SLim has nothing to do with the future of OGP.. or that's what I read of it.
[9:43] Tess Linden: SLim addresses many of the use cases requested in SVC-419, but we're here to talk about OGP and how we will be embracing standards in an interoperable world
[9:43] Bjorlyn Loon: is there a url for that Tess? Dale's wiki page?
[9:49] Tess Linden: IM box is a not fully OGP compliant agent domain that has protocols that interoperate with AD's
[9:49] Hydra Shaftoe: So uh...say a really big corporation wanted to set up here, some sims on the main grid, some on a private internal firewalled grid, but wanted to use the same instant messenger to communicate with employee groups between both systems. possible?
[9:49] Zero Linden: er - the IM box is some external, IM system ---
[9:50] FWord Utorid: if you want the gray IM void to have meaning, you need the THX sound, along with a voiceover from James Earl Jones, for emphasis.
[9:50] Bartholomew Kleiber: is a group domain wide or global in the presented scanario?
[9:50] Bjorlyn Loon: what Hydra just said, I know of a corporation actually doing that, wants a firewalled grid for their R&D with full control and security
[9:50] Saijanai Kuhn: I meant invenotry was not part of the IM box
[9:50] Zha Ewry: How wide you want chat/im groups to go, is really important
[9:52] Saijanai Kuhn: A had this quaint little suggestion...
[9:52] Infinity Linden: the firewalled use case should be doable if you put your corporate IM server bhind the firewall and give your employees a way to get to to (vpn, etc.)
[9:53] Tess Linden: in this model, the agent domain would handle your chat messages (whether group or not)
[9:53] Stirling Allen: WHat about reframing this as "agent to agent communication" and think of what the D does in terms of supplying caps. The present IM system would then just be another URL that is sent to participants.
[9:53] Hydra Shaftoe: I'm not too keen on the technical mumbo jumbo. just curious if that's doable.
[9:53] FWord Utorid: ooh, this would allow people to possibly talk from Lively to SL!
[9:53] Tammy Nowotny: what was the uRL for Sai's page from yesterday?
[9:54] Bjorlyn Loon: its the one sai just gave, Tammy
[9:54] Tess Linden: one suggestion made was for using XMPP to communicate chat as the standard protocol for virtual worlds chat
[9:54] Tammy Nowotny: LOL. Thanks. even though I am aredhead I often have blonde moments.
[9:54] Tess Linden: this would mean that we would require XMPP as a dependency to OGP
[9:55] Bartholomew Kleiber: not if these are two different apps like in this chart
[9:55] Teravus Ousley: wouldn't XMPP serve as a serialization of data as well?
[9:55] Tess Linden: so along with requiring REST/HTTP event poll as the underlying transport, we would also require XMPP as well
[9:55] Stirling Allen: I am sure we could find a more verbose, baroque and ornate dependecy if we try.
[9:55] Infinity Linden: @Teravus... there are some parsign issues with generic XML over XMPP
[9:55] FWord Utorid: we should find a new protocol next year, so we can have more meetings.
[9:56] Tess Linden: Teravus: that's another question, if that is what we want, do we want to rely on XMPP for all communication to the viewer?
[9:56] Infinity Linden: it seems to work well for cases where you know what XML is coming over the pipe... less well if you're not sure
[9:57] Bjorlyn Loon: wonders if you need systems which create internal security, and then a broader open chat system without that security, or is the former the responsibility of the OG sim owner?
[9:57] Tess Linden: this use case does not *require* XMPP to be part of the OGP spec
[10:00] Infinity Linden: are there still people selling securities?
[10:00] Tammy Nowotny: and others don't want thier conversations logged, perhaps even for similar legal reasons.
[10:00] Teravus Ousley: Agreed. With the Simulator's current model.. XMPP over BOSH may be the way to go.. that would mean that each Agent domain would do a poll of the IM server.
[10:00] Tess Linden: but in order to achieve interoperability between an external IM system and the agent domain, we would need a standard that's also for server to server
[10:00] Dale Innis: Stirling: does that impose any protocol requirements, or just impelmentation requirements?
[10:01] Hydra Shaftoe: Yeah what Bjorlyn said. I'm not too able to read all these acronyms, but a plain english answer would be appreciated. I want to know if a big corporation entering SL were to deploy an open grid solution for secure internal use, but also 3 public SL sims, would employeees on both grids be able to communicate with eachother and use the group IM tools?
[10:01] Tess Linden: Dale: I believe there is a proprietary component to what Jabber uses
[10:01] FWord Utorid: hydra, anything is possible if you spend a lot of money.
[10:01] Zha Ewry: If you want secured, from public spaces, you're going to need to encripty, or keep the sim off the path, ot bnoth
[10:01] Hydra Shaftoe: I think someone answered me, but it looked like a string of greek letters
[10:01] Dale Innis: Hydra: that's exactly the kind of thing we're discussing.
[10:02] Dale Innis: This is all still very much in progress. :)
[10:02] Hydra Shaftoe: yeah I just cant understand the technical jargon yet.
[10:02] Stirling Allen: It often imposes specific system requirements, in that empolyers often dictate which system is to be used. This argues for communications being a function where the domain, region or agent domain, allows negotiation of, but does not impose any particular requirement on. Example, allowing two agents to communicate over a VPN trading desk system which has its own internal means of establishing connections.
[10:02] Zha Ewry: (plain text, which isn't point to point, but wants to be secure, needs at least tls, and proably real encyprtion
[10:02] FWord Utorid: if you spend 1.4 million dollars you can have what you want, and a bill for another 1.4 million dollars in support. Unless you hire Tess, she will probably hand type it all for you if you ask nicely.
[10:03] Dale Innis: I just meant that questions like "will X be able to do Y?" are ones we can't answer yet, because we don't know! :) But if they want/need to, it's good to write down as a requirement.
[10:04] Tess Linden: We need to identify the specific problems that we're trying to solve and then look at whether what XMPP is optimized for meets our needs, and determine how much they divert from the simplest possible solution
[10:05] Zero Linden: I propose that the security issue is, probably orthogonal to XMPP -- XMPP offers about same level of security -- or less (!) -- as the direct translation of SLs current IM system into the OGP caps framework
[10:05] Tammy Nowotny: oh no, is that bug back, FWord... the one with the trippy 1970s textures appearing where tbey don't belong?
[10:05] FWord Utorid: tammy, i patched that one, but now everyone has extremely large plaid genitals
[10:05] Zero Linden: Both do client<->server TLS and not much beyond that
[10:06] Tammy Nowotny: luckily this is an M-rated sim :-)
[10:06] Dale Innis: Oh, while we're all here: Given that Rob or whoever was complaining about all the sldev talk, where should AWG / OGP / interop talk go?
[10:06] Bartholomew Kleiber: it says it uses a special port for server to server communication, 5269.
[10:06] FWord Utorid: ok, so there's a need to encapsulate all of the functionality that needs to be transferred over the diagram, and then to decide what sort of ascii to use for it
[10:06] Tess Linden: here are some other places that XMPP could be employed
[10:07] Whump Linden: Dale: we're working on a new list for that, will announce later this week.
[10:09] Tess Linden: whereas HTTP/HTTPs is a static pull model
[10:09] Zha Ewry: But, presence, is a tiny faction of what we move traffic for
[10:10] FWord Utorid: ok. let's have a list. 1. local spacial chat 2. group IM 3. private IM 3. spatial voice chat 4. group voice chat 5. group notices 6. group invites 7. group ejections 8. group votes 9. add yours <--- how many of these could be handled by an XMPP based mutation which allows server to server communication and handshaking?
[10:10] Zha Ewry: Every bit we move on a non http pipe is
[10:10] Zha Ewry: a) goign to be harder to get through someone's network
[10:10] Zha Ewry: b) going to mean added likely hood someone else will move it on HTTP
[10:10] Tess Linden: Bartholomew: SIP is for session initiation and management
[10:10] Tammy Nowotny: email to the outside world is possibl number 9
[10:10] Zha Ewry: and make it much, much harder to refactor the system for deploument on different models
[10:14] FWord Utorid: ok. but... i tried to taxonimize the available options and find out what could and couldn't be covered by the TESSXMPP extensions
[10:14] Zha Ewry: Well, the common use pattern, in lots of anoucnements, is infreuqent one to all
[10:14] Bartholomew Kleiber: but youll never have 1000 people writing at one time with 1000 listening.
[10:14] Zha Ewry: but a diferent one, in each case
[10:16] Zha Ewry: if they all talk at once, sure, but, it's the 1 message from each every 10 minutes case which is killer
[10:16] FWord Utorid: lyndell, that's what robots are for.
[10:16] Zero Linden: Let's also be clear --- there is nothing special in the protocol of XMPP, or IRC, or SL's IM system, that enables these uses cases better than the others
[10:16] Zero Linden: they are all simply publish-subscribe systems
[10:16] FWord Utorid: robots will allow you to use your finger for more important things than the scroll wheel.
[10:16] Tess Linden: a popular requeste feature is the ability to mute group chat:
[10:16] Tammy Nowotny: I am reminded of that program they hasd on MTV way back in the l;ast centiury where they broadvcast a sample of chat room traffic in a window below videos, for some reason.... millions to millions text chat... not something we need here, though.
[10:17] Zero Linden: and, the ability for ejabberd, or ircd, or Jabber.com's offering to handle huge loads of messages shaped in whatever shape you particular use case needs, resides in their implementation in server code... NOT in the protocol
[10:17] Tess Linden: yeah -- we're going on a tangent
[10:17] Goldie Katsu: sighs at her poor panicking computer
[10:17] FWord Utorid: tess, i am just trying to arrive at a clear understanding, and to pass the savings on to you... you are proposing maneuvering a variety of these services to a special xmpp variant that has routing capacity, among them, the 1-9 list i pooped above
[10:18] Tess Linden: FWord: I dont think your list was a tangent
[10:18] Zero Linden: Actually - Barth - - I think to be clear, neither XMPP nor IRC nor SIP/SIMPLE has anything in the protocol that actually handles uses cases with the number 1000 in them at all
[10:18] Tess Linden: but we should think about which use cases that list affect (which slide)
[10:18] Zero Linden: XMPP does not, infact have support for effective distribution of large subscribed groups
[10:19] Tess Linden: Zero's saying that the main affect is not server to server but rather client to server
[10:19] FWord Utorid: tess, ok. i presented the list as an opportunity to condense communication on which services might or might not be able to go over this particular new wire
[10:19] Zha Ewry: Also, that 90% of the scaling is inside the servers
[10:19] Zero Linden: (some servers might implement such support, in proprietary extentions or methods, but they are not part of XMPP)
[10:19] Bartholomew Kleiber: true - Iwanted to point out that at some numbers the use case doesnt make sense
[10:20] Bartholomew Kleiber: lets say this sim could hold a 1000 people all attending the meeting - do we have to provide a protocaol that does this 1000 to 1000 conversation?
[10:20] Zha Ewry: I don't think they don't make sense. Most are piulledf from actual usuage. They cause p[ain in interestign ways, but theya ren't exactly devoid of real life usage info
[10:20] Zha Ewry: Well, just like in RL, if 1,000 people al yell
[10:21] Zha Ewry: I can put 1,000 people in an auditoriam
[10:21] Tammy Nowotny: unless they are saying the same thing
[10:21] FWord Utorid: the one question of genuine interest to me is if the voice services can be / will be over this new service, given that the current implementation is proprietary
[10:21] Zha Ewry: and they can all talk, in various ways
[10:21] Rex Cronon: that is what i am talking about. information overload
[10:21] Dale Innis: Not sure what you're saying there, Zero: surely there are IRC groups that have 1000 or more members in the channel at once?
[10:21] Bartholomew Kleiber: yes, but they are not writignn at the same time
[10:21] Zha Ewry: Not with a persistent subscription model, tho dale
[10:21] FWord Utorid: yick, irc would be so icky for this scheme
[10:21] Stirling Allen: But not everything that goes over chat presently is meant for human consumption. For example, a great deal is meant to send messages to scripted objects.
[10:22] Bartholomew Kleiber: thats why professional chat sytsems have built in brakes
[10:22] Zha Ewry: The social scaling, is clearly problematic
[10:22] Stirling Allen: Therefore we can't assume that 1000 peers would not happen, simpley because humans could not follow it.
[10:22] Zero Linden: Dale - I'm saying that there is nothing in the IRC protocol that is especially supportive of that use case - so that by adopting that protocol we'll gain scaling for free
[10:22] FWord Utorid: whoa, are you saying you also intend to ship the non-'audible' communication over the same protocol?
[10:23] Dale Innis: Zero: ah! We *will* gain scaling for free if we use IRC?
[10:23] Zero Linden: FWord - I know of no voice signaling over XMPP
[10:24] Tammy Nowotny: and ideally in voice chat you need a way to filter out background noise,m breathing, snoring etc.
[10:24] lyndell Aleixandre: they used to haqve this kind of issue way back in the age of modems where the modem would flood the serial line .. so they implimented a "buffer"
[10:25] FWord Utorid: ok, fine, lyndell, she has Tess-trogen.
[10:25] Dale Innis: would still suggest that we figure out what the services ARE first, then decide which should flow through the same channels, and what those channels ought to be. :)
[10:25] Tess Linden: that is a Jabber White paper, so probably biased
[10:26] Zha Ewry: cuckles at Tess. "What, people do that?"
[10:26] FWord Utorid: I so hate when people are biased. They should be forced to only have one ass.
[10:26] Latha Serevi: Hey, gang, a mention of a related topic, mostly NOT for today -- my own focus is on how to manage group membership, and trust, rather than chat mechanisms. I hope we might be able to separate those issues cleanly, group-list-management versus communicating-given-a-list. My contention is that there are a couple of distinct kinds of gorups -- land management groups need high security, and have an impact on what can be done by whom; informal chat across grids needs high interoperability that would be positively harmed by having such high security.
[10:26] Latha Serevi: The other day I had mentioned that a secure-groups-management facility would be a potentially useful abstraction on top of which we could implement all of our OGP trust checks; but folks didn't seem to think I was nearly as brilliant as I thought I was. I wrote up a wiki page on it -- [6]
[10:26] Bartholomew Kleiber: Dale the 1000/1000 scenario is ok, but we could allow limit to the number of transactions.
[10:27] Dale Innis: Latha: I commented on your page. :)
[10:27] FWord Utorid: I want to be able to talk to everyone at the same time, whether they like it or not. Can we have that as a feature?
[10:27] Zha Ewry: We haven't found a way to stop you yet, Fword ;-)
[10:27] Teravus Ousley: heh, if you have 1000 people talking to 1000 people.. you're going to be scrolling back a lot more often
[10:27] Dale Innis: Bart: an implementation can certainly impose a limit, but the underlying protocol should scale to any case that seems at all reasonable. imho.
[10:27] Rex Cronon: and everybody has the right to mute anybody:)
[10:28] Zha Ewry: Its not 1000 to 1000 al the time
[10:28] Tammy Nowotny: I went to a RL event in a space aboiut the size of 1 sim where Barack Obama spoke to 10,000 people... and a few hundred people were at unrelated events at a convention center across the street... that's the type of capacity we need in VWs someday.
[10:28] Zha Ewry: but. 1000 to 1000 over several tens of minutes
[10:28] Bartholomew Kleiber: Dale: yes. But if you exchange a KISS solution with a 'better' one for a use case that you actually wont have?
[10:28] Dale Innis: I'd like to encourage everyone to look at Sai's proposal for a first step, and comment. It would give us somehting to start coding and POCing to anway. :)
[10:28] Tess Linden: Latha's use case is more general than the messaging use case we had, it would also rely on server to server communication across domains
[10:28] Whump Linden: / so a subset of 1000 to 1000
[10:29] Dale Innis: Bart: depends just how unlikely "you actually won't have" is.
[10:29] Dale Innis: the world often surprises us :)
[10:29] Stirling Allen: I have a simple one. 1000 objects in a combat game, they communicate over chat, as they do presently. Instead with this system they would be members of a group, and communicate as a group message, thus reducing the amount of filtering doen by the general chat system. Presently use of negtaive channels s used for "chatting members are objects."
[10:29] Zha Ewry: The problem with thinkig it isn't 1000x1000, is you can't ever guess which 10 will tak
[10:29] Stirling Allen: But 1000 peers is easily possible in that use case.
[10:30] Rex Cronon: even if u have 100 people talking at the same time is still hard to follow:(
[10:30] Zha Ewry: sure, but even if you have an orderly flow of conversatoin, you still have 1,000 people, any of which may speak at any moment
[10:30] Stirling Allen: But we aren't taling about people, instead we are talking about agents. Agents are not people necesarily. Agents are potentially processes.
[10:30] Bartholomew Kleiber: you just throttle at some number to keep the load down.
[10:30] Tess Linden: does it help with scaling at all if a subset of the group is "listen-only"?
[10:31] Zha Ewry: You never know who wants to be listen only, and it costs you to change
[10:31] Tammy Nowotny: in my RL case, there were probably more than 1000 conversations goingon before and after the speech
[10:31] FWord Utorid: rex, the issue isn't whether or not the human mind can process the data, that's irrelevant. the issue is whether or not we can cram so much data over the network to make human's heads explode. if they can't filter it themselves, they *deserve* to melt.
[10:32] FWord Utorid: rex, formants actually don't take much in the way of bandwidth, if they are properly processed
[10:32] Zero Linden: typically, this kind of use case optimiztion is left for the servers to implement
[10:32] FWord Utorid: if you wanted an ultra-low bandwidth solution to transmitting audible vocal data with or without inflection, you could leverage formant synthesis.
[10:32] Rex Cronon: there is a limit of how much u can compress data
[10:33] FWord Utorid: rex, there is no limit to how much you can compress data.
[10:33] Bartholomew Kleiber: again, I only vote to keep it simple within reasonable numbers in the first run and to with standards (whatever that is) were apropriate.
[10:38] Zero Linden: needs to run..... looks forward to the almost certain recap (and perhaps some stakes in the ground) at his office hours later today
[10:42] Bjorlyn Loon: another couple hundred thousand in podcast downloads
[10:43] Tammy Nowotny: when I tell people about Second Life, they often say. "like on Science Friday!" Bjorlyn. (more ofetn than they mention "The Office," actually... but maybe that's because I hang out with NPR listeners.)
[10:43] FWord Utorid: most of the things people say are about proving how big their weiner is.
[10:46] Saijanai Kuhn: well, we have such a protocol. It just doesn't scale
[10:46] Tammy Nowotny: especially since some opensim hosts will want their curerncy to be fungible with other currencies... some will want it just to be spacebucks