User:Zero Linden/Office Hours/2008 October 02

• [8:35] JC Hill: ah bettie bettie thats all folks
• [8:35] VoidTraveler Seetan: hello
• [8:36] VoidTraveler Seetan: ty
• [8:37] Kevin Paisley: *meow*
• [8:38] VoidTraveler Seetan: so whats the meeting about sorry didnt catch it right
• [8:38] Turbo Racecourse: hi!
• [8:38] Tiglo McMillan: hello :)
• [8:38] VoidTraveler Seetan: hi
• [8:39] Kevin Paisley: someone eating ribs on voice chat? i hear a mic open
• [8:39] camerone Vestel: hello
• [8:39] VoidTraveler Seetan: yeah me too i hear that
• [8:39] Zha Ewry: We seem tobe zeroless
• [8:39] Tree Kyomoon: mmm ribs
• [8:39] VoidTraveler Seetan: id love ribs right now
• [8:39] INDICATOR: OFF:
• [8:39] Kevin Paisley: Yeah I know
• [8:39] VoidTraveler Seetan: pulls one of tree
• [8:40] Tree Kyomoon: eeep
• [8:40] VoidTraveler Seetan: 8)
• [8:40] Tree Kyomoon: soylent green!
• [8:40] Kevin Paisley: hehe
• [8:40] VoidTraveler Seetan: sit on my lap lyndell
• [8:40] Tiglo McMillan: o/
• [8:40] Rex Cronon: greetings
• [8:40] Tiglo McMillan: o/
• [8:40] Tiglo McMillan: eijaoiojeaiojea
• [8:40] Tiglo McMillan: huhsHAUHsuhAUSHuahushUSHUAHSuhAUShuAHSUHASuhaushAHU!!
• [8:40] Widget Whiteberry: what's our agenda?
• [8:41] Kevin Paisley: *mew* Heya Rex!
• [8:41] Saijanai Kuhn: There,you see? Crash more than 2-3 timesin a row, and someone takes your seat
• [8:41] Zha Ewry: Ooh. Signs of Zero
• [8:41] Rex Cronon: hi
• [8:41] Saijanai Kuhn: Good Morning Teacherzzzzzzzzz
• [8:41] yen Dagger: hello =)
• [8:41] Tree Kyomoon: zeero is neero?
• [8:41] Zero Linden: nil est!
• [8:41] Rex Cronon: does anybody know why a new viewer is suddenly required?
• [8:41] Zha Ewry: I hope not nero. That would imply fiddling while the grid burns
• [8:42] Saijanai Kuhn: Welll, I got on with the old one, but the newer RC crashed on me three timesin 5 minutes just now
• [8:42] Tree Kyomoon: monsieur smarty pants
• [8:42] Zero Linden: hello hello
• [8:42] Rex Cronon: hello zero
• [8:42] VoidTraveler Seetan: hi
• [8:42] Zero Linden: well then - welcome to the Burning LIfe edition of my office hours!
• [8:43] Kerry Giha: Hello Zero
• [8:43] Zero Linden: what's up, burners?
• [8:43] Tree Kyomoon: stick it to the man!
• [8:43] Rex Cronon: we get to burn your office:)
• [8:43] Kevin Paisley: Yayyyyyyy!!!!!!!!!!!!!!!!!!!!!!
• [8:44] VoidTraveler Seetan:  ?
• [8:44] Tree Kyomoon: wonders if the bailout will reach any of the SL banks
• [8:45] Kevin Paisley: spent so long getting voice to work under linux and now i just hear someone eating ribs and saying "test" over and over :(
• [8:45] Saijanai Kuhn: Interesting. I wasn't required to download the latest RC when I logged in
• [8:45] VoidTraveler Seetan: ha ha kevin
• [8:45] Rex Cronon: i guess everybody is contemplaiting their monitors
• [8:45] Saijanai Kuhn: can't hear anyone
• [8:45] VoidTraveler Seetan: no one is talking thats why
• [8:45] Zha Ewry: Siaj, diid you have a leftover from last session?
• [8:45] VoidTraveler Seetan: aww
• [8:45] Saijanai Kuhn: voice suddenly not working...
• [8:45] Tree Kyomoon: they call 'em fingers but Ive never seen 'em fing.
• [8:46] Kerry Giha: It seems to be working fine, just no-one is talking.
• [8:46] Zero Linden: ...leftover.... ribs....? what is this, a picnic? Interoperability ain't no picnic! (and you can quote me on that!)
• [8:46] Saijanai Kuhn: Just wanted to promote implementing current IM in the OGP (for now). WHump suggeseted I make a jira to that effect
• [8:46] Kevin Paisley: hehe
• [8:46] Zero Linden: Okay - Agenda items
• [8:47] Tao Takashi: Moin
• [8:47] Zero Linden: Moin^2?
• [8:48] Turbo Racecourse: ... this is a crash test, please don't sit in the middle of the road when the truck approaching! ...... this is a crash test, p
• [8:48] Turbo Racecourse: ... this is a crash test, please don't sit in the middle of the road when the truck approaching! ...
• [8:48] Turbo Racecourse: ... this is a crash test, please don't sit in the middle of the road when the truck approaching! ...
• [8:48] Turbo Racecourse: ... this is a crash test, please don't sit in the middle of the road when the truck approaching! ...
• [8:48] Turbo Racecourse: about the sound....it happens sometime....i hear a little scratch and sl log me off.....receiving the crash advice...then i got a msg about
• (error with sl voice)
• [8:48] Tao Takashi: northern german greeting
• [8:48] Turbo Racecourse: sorry for this stupid text....a gesture i have to rid
• [8:49] Saijanai Kuhn: In fact, I'm having trouble with voice also.
• [8:49] Tree Kyomoon: voice doesnt work for me ... am I missing all the cool conversations?
• [8:50] Kerry Giha: I just don't think anyone is talking.
• [8:50] Larissa Vacano: hello ;-)
• [8:50] Zha Ewry: This is a text meeting
• [8:50] Tao Takashi: chilly meeting then :)
• [8:50] Turbo Racecourse: btw...is about 2 days now that i dont encounter this matter, but if i will go in a specific sim it happens and happens again....when i will be
• back it will be ok then
• [8:50] Zero Linden: Okay --- well, only Item I hear is IM
• [8:50] Zero Linden: SO
• [8:50] Rex Cronon: everybody is asking: How does tree get his bones so shiny:)
• [8:50] Widget Whiteberry: offers Zero aspirin and coffee
• [8:50] Zero Linden: Let's open that can of worms and see where it gets us!
• [8:50] Rex Cronon: hi
• [8:51] Tree Kyomoon: crelm bone polish
• [8:51] Tao Takashi: will think further about this topic at tomorrow's holiday :)
• [8:51] Zha Ewry: gets out her worm repllent
• [8:51] Zero Linden: Is it Nationial Text Msg day in Germany?
• [8:51] Tao Takashi: It's reunion day
• [8:51] Larissa Vacano: tomorrow its reunion day
• [8:52] Zha Ewry: Last time we talked about this, there was some arguing that you just needed a plug point to put in random messaging systems, and that OGP needn't
• touch it at all
• [8:52] VoidTraveler Seetan: ok where is this meeting going has it even started?
• [8:52] Tree Kyomoon: oh I did have an item...is forced object load ordering a reasonable topic?
• [8:52] Tao Takashi: maybe we need a national text messaging day in SL :)
• [8:52] Zha Ewry: forced, in what sense?
• [8:53] Zero Linden: uhm, sure, Tree -- added as #2
• [8:53] Tree Kyomoon: like an island owner can determine certain objects to be always loaded before any others
• [8:53] Zero Linden: So - there are three kinds of IM in SL (!)
• [8:53] Zero Linden: person to person IM
• [8:53] Zero Linden: group IM
• [8:53] Zero Linden: and ad-hoc group IM
• [8:53] Saijanai Kuhn: I'm OK with that. ALl I'm arguing for right now is to implement the current system as a temporary solution to give us a working group IM for:
• community amongst the gridnauts and to see what happens when you send real info downthe AD Event QUeue
• [8:53] Zero Linden: they all (sigh) work differently
• [8:54] Tao Takashi: and they are mixed with object transfer and stuff like this, right?
• [8:54] Zha Ewry: That's impressively annoying
• [8:54] Zero Linden: Ah - well, Saijanai - not really possible --- at present, the IM is handled by the region
• [8:54] Saijanai Kuhn: [1]
• [8:55] Saijanai Kuhn: Iguess that's sorta my point
• [8:55] VoidTraveler Seetan: ok go on zero
• [8:56] Zha Ewry: And certanly, the region could care less
• [8:56] Zero Linden: Well - yes and no, Zha
• [8:56] Saijanai Kuhn: it seems to me, that if the AD is going to act as some kind ofproxy for group IM, that we will have to solve this issue at some point
• [8:56] Zero Linden: Here's the use case that has come up internally
• [8:56] Zero Linden: say Amy and Bob work for the same company
• [8:57] Saijanai Kuhn: and need to establish secure communications with each other..
• [8:57] Tree Kyomoon: misses Amy and Bob
• [8:58] Zero Linden: If they are on random regions out in the virtual-world
• [8:58] Zero Linden: then we would expect that any IM traffice would go: Amy <--> A's AD <--> B's AD <--> Bob
• [8:58] Zero Linden: BUT
• [8:58] Zero Linden: if both are on a region
• [8:59] Zero Linden: inside their company
• [8:59] Zero Linden: then
• [8:59] Tao Takashi: I would think it goes Any <--> IM Service <--> Bob
• [8:59] Zero Linden: it might be the case that they WANT their IM to go: Amy <--> Region <--> Bob
• [8:59] Zero Linden: so that it stays within the corporate firewall
• [8:59] Tao Takashi: IM service could be provided by their company and highly secure
• [8:59] Zero Linden: (or rather, the company may want that)
• [8:59] Zha Ewry: well, through the regoin, or pointed to by the region?
• [8:59] Zero Linden: Tao -
• [8:59] Tao Takashi: they might also want to use group IM while not being logged in to a region
• [9:00] Zha Ewry: The regoin, isn't in any sense, about IM management
• [9:00] Zero Linden: I think that *if* we simply put in a vector to the users's preferred IM system, then
• [9:00] Zero Linden: we will achieve a disconnected world
• [9:00] Zero Linden: what happens if I want to IM you, but you are not on the IM system I am?
• [9:00] Zha Ewry: Which feels very wrong, since you end up without any ties to the rest of the system
• [9:00] Tao Takashi: we could specify a prferred system in the spec but keep the protocol open to add new ones (or additional ones)
• [9:00] Zero Linden: And, if we just vector out to other systems, then we also lose all the integration with them
• [9:01] Zero Linden: like group chat and ad-hoc chat
• [9:01] Tao Takashi: but when doing it all outselves we are reinventing things and then we are disconnected from the rest of the internet
• [9:01] Zha Ewry: right. Its not any good, if by allowing Amy and Bob to talk securely, nobdy else can talk to them
• [9:01] Saijanai Kuhn: all of this seems to be a rason to implement the current system so we have a working situation to play around with...
• [9:02] Zero Linden: Or - we could spec the IM protocol from the viewer to either AD or RD --- but nothing stops those (especially the AD) from peering with other IM
• systems
• [9:02] Rex Cronon: once u allow outside message u no longer have security
• [9:02] Zero Linden: there just doesn't seem to be any benefit to the user to support multiple protocols in the client ---- it is access to multiple IM systems that is
• of value
• [9:02] Tao Takashi: Zero: That's my point. We can still provide a hook in the protocol to let clients connect to other IM systemns but specify one as the OGP one
• [9:02] Zero Linden: so why not simplify the client, one IM protocol (after all, they aren't rocket science), and then
• [9:03] Zero Linden: allow the AD to offer your account services like peering or account aggregation with other IM systems (like what meebo does)
• [9:03] Tao Takashi: this hook might even be a general one which does not only is useful for IM
• [9:03] Zero Linden: But Tao, that would be client side, not domain side, yes?
• [9:03] Tao Takashi: basically it would be getting information about the user I guess
• [9:04] Tao Takashi: well, the service the client connects to might want some information about the agent and might get it from the AD
• [9:04] Tao Takashi: so the AD might have some information webservice which can be called by e.g. some OAuth protected URL
• [9:04] Zero Linden: So, let's look at a very specific case
• [9:05] Zero Linden: Amy is on region Alpha - her AD is AvatarsRUs (ARU)
• [9:05] Tao Takashi: the IM service could then show this agent as a verified agent if this web service could have been called
• [9:05] Zero Linden: Bob is on region Beta - his AD is BetterAgentsHere (BAH)
• [9:05] Tao Takashi: Amy@ARU
• [9:05] Zero Linden: Now, Amy wants to IM Bob
• [9:06] Zero Linden: Presumably, first, Amy's viewer asks ARU for her friends list, and their presence
• [9:06] Tao Takashi: Amy can do a service discovery for Bob and gets the preferred IM service of Bob
• [9:06] Ratcloner101 Burner: bqd LoL
• [9:06] Zero Linden: presumably, ARU has subscribed to BAH for Bob's presence and has that he is on line
• [9:07] Tao Takashi: Hm, that means we need to have lots of subscriptions between ADs for presence information?
• [9:07] Zero Linden: So - let's look at that -- Amy fetches some service discovery URL for Bob (supplied by ARU in the firends list) and gets what? URLs for AIM and
• Jabber?
• [9:07] Zero Linden: wonders if there are URL schemes for AIM or Jabber .... thinks no.....
• [9:08] Zha Ewry: cringes as she thinks about how hard most of this would be to hide from users
• [9:08] Zero Linden: But okay, so Amy gets aim:BroCool1982 and jabber:BobSmith@jabber.org
• [9:08] Tao Takashi: these can be created. But it might be some service which might mark itself additionally as AD aware (so we know it's some service which can ask an
• AD about detail information or not)
• [9:09] Tao Takashi: I don't know about the Jabber protocol but for IRC she could then login to that IRC server and eventually allow this server to retrieve her agent
• information from her AD
• [9:09] Zero Linden: at this point - *IF* Amy has an IM account on one of those systems, AND her viewer has the appropriate protocol support --- then she can IM Bob
• [9:09] Zha Ewry: (And if all the names map and permissions map, and friends are regiistered correctly)
• [9:09] Tao Takashi: as said, we might define one protocol as the standard one
• [9:09] Zero Linden: but it seems like at best, this is just client-side protocol integration --- like mutli-protocol systems
• [9:10] Tao Takashi: still you might want to have the ability for some service to verify an agent
• [9:10] Zha Ewry: has friends who may well be on systems but have not gotten around to authing all my various names to them
• [9:10] Zero Linden: and we've lost any possible integration: How do you give inventory over this channel?
• [9:10] Tao Takashi: via some webservice of the AD?
• [9:10] Rex Cronon: insiside the IM:)
• [9:11] Zero Linden: So - all of this additional protocol - the back mapping of identifiers, webservices to the AD, service discovery is to what end?
• [9:11] Tao Takashi: I am not sure I would put inventory stuff into an IM protocol
• [9:11] Tao Takashi: she contacted Bob already so she has Bob's AD URL
• [9:11] Rex Cronon: is just text tao
• [9:11] Zero Linden: I posit that none of the existing IM systems have any protocol magic (they are literally about 7 message types)
• [9:12] Saijanai Kuhn: [2] for reference to what existing IM does
• [9:12] Zero Linden: The only value is integration with friends on other networks? And if so, why not leave that all out of the spec and do it in the agent domain?
• [9:12] Tao Takashi: so she can call PUT [3]
• [9:12] Zero Linden: Sai - yes - that SL needs so many types is an example of the integration that will be lost using, say AIM
• [9:12] Tao Takashi: only value of what?
• [9:13] Zero Linden: What is the value for Amy and Bob to negotiate which IM protocol they use?
• [9:13] INDICATOR: OFF:
• [9:13] Saijanai Kuhn: That gets back to my point, I think. Gt the conection point working for the current setup via the AD EQG CAP and see how we can change the
• protocol coming into the AD without affecting the client's interface
• [9:13] Tao Takashi: the ability to hook up new protocols easier.. but I am really simply just talking about a way for external service to verify an agent
• [9:14] Zha Ewry: You *may* get some real value, if it integrates into the company IM system, but.. that's more a gateway story, I think
• [9:14] Tao Takashi: so there is also the possibility then to extend the functionality easily.. people who want to experiement with whatever protocol could then do so
• easily
• [9:15] Zero Linden: I think the loss of garunteed interoperability is a problem ---
• [9:16] Zero Linden: --- and really, there isn't anything stopping anyone from doing service discovery on Bob (if we provide the end point) --- and vectoring to ALL
• SORTS of services
• [9:16] Tao Takashi: as said, we can define one protocol as the standard one which has to be implemented
• [9:16] Tao Takashi: that's my point
• [9:16] Zero Linden: I just think IM is one of those integral aspects of a virtual world -- and it has to just work
• [9:16] Zero Linden: If so - then there is no reason to do service discovery for the integrated IM -
• [9:16] Tao Takashi: but do we really want to put all those things in the IIM list into one protocol? This looks to more more like separate web services
• [9:17] Zero Linden: it should be a protocol suite you get from the Agent Domain --- and possibly the REgion Domain
• [9:17] Tao Takashi: ok, if we have a default, then there isn't a need but it might be a COULD
• [9:17] Zero Linden: (for constrained to region chats)
• [9:17] Zero Linden: and there ya go
• [9:17] Saijanai Kuhn: Again, this goes back to my suggestion: get SOMETHING working, see how it can be played with in a "real" situation, and go from there
• [9:18] Saijanai Kuhn: also gives us the current inventory transfer system "for free" so we can start experimenting with security/trust issues in a workng setup
• [9:18] Tao Takashi: but implementing the improved IM seems to be quite some work ;-)
• [9:18] Tao Takashi: and seems to touch many systems
• [9:18] Saijanai Kuhn: well, if the packet remains thesame as it comes into the client, then its all AD-side work
• [9:19] Saijanai Kuhn: and if we decide to make it several different types of packets, no reason why that can't be done also
• [9:20] Zero Linden: well- I think the 1-on-1 IM system is pretty simple
• [9:20] Tao Takashi: my other point is though that defining our own IM system makes implementing an AD more difficult
• [9:20] Tao Takashi: using existing systems and maybe adding something might be easier
• [9:20] Saijanai Kuhn: Tao, why?
• [9:20] Tao Takashi: because it's a lot of work to implement it from scratch
• [9:20] Tao Takashi: the less I have to implement the better
• [9:21] Saijanai Kuhn: is not from scratch. Existing client uses existing protocol. Existing IM server could treat AD as a never changing Sim
• [9:21] Zero Linden: I don't know, Tao -- using an existing one means figurring out how to mirror state from the agent domain in the IM system
• [9:21] Zero Linden: and mapping identifiers
• [9:21] Tao Takashi: seems easier than implementing a system from just a protocol specification
• [9:21] Zero Linden: so - I don't think picking Jabber, say is going to save you any implementation time
• [9:22] Tao Takashi: at least I'd know that basic IM is already working
• [9:22] Saijanai Kuhn: Zero is there something wrong with my understanding of how the current system works? The group IM sends data to the sim, which forwards it to the
• client via UDP, right?
• [9:22] Zero Linden: after all- that and IRC are the only two available building blocks (AIM being propritary as is MSN and Yahoo) -
• [9:22] Zero Linden: but I don't think those servers are especially integratable
• [9:22] Zero Linden: Sai - yes
• [9:23] Tree Kyomoon: I wonder how gaim / pidgeon does it
• [9:23] Zero Linden: Tree - those are clients, not server side
• [9:23] Tree Kyomoon: right sorry
• [9:23] Saijanai Kuhn: so... tell the group IM server that the AD is a sim, and let the AD reroute stuff to the client
• [9:23] Zero Linden: gaim / pidgeon, and others have reversed engineered the AIM and other propriatery protocols
• [9:23] Saijanai Kuhn: seems reasonably trivial, at least when I sayit
• [9:23] Zero Linden: there are legendary internet stories of AIM changing the protocol and all the open clients scrambling
• [9:24] Zha Ewry: Unless you do a lot of work, you end up with a very imersion breaking solution, I fear
• [9:24] Tao Takashi: feel free to code it for pyogp, I'd say it's not rtrivial ;-)
• [9:24] Tree Kyomoon: well I guess my load order agenda item wont have time :(
• [9:24] Zero Linden: Sorry - tree - let's take it next time
• [9:25] Saijanai Kuhn: its the AD part that needs to change substantially, over time, but as a first pass, just estabish the current im srver <=> sim connection between
• the IM server and the AD
• [9:25] Tao Takashi: but in general my main issue is that we should allow for people to add additional protocols if they want to
• [9:25] Tao Takashi: so there is room for experimentation
• [9:25] Tao Takashi: exchange these 2 lines ;-)
• [9:25] Saijanai Kuhn: the general main issue is that we need to have SOMETHING working through the AD, and see where it takes us
• [9:26] Saijanai Kuhn: as a second pass, get the AD talking to multiple IM servrs
• [9:26] Tao Takashi: how is it handled if some agent at AD 1 talks to somebody at AD 2? I guess there needs some inter-AD protocol then for IM
• [9:26] Saijanai Kuhn: Then have them come in via different kind of connections to simulate different protocols
• [9:26] Goldie Katsu: ponders SIP
• [9:27] Saijanai Kuhn: or different AD's talking to different ADs
• [9:27] Zha Ewry: SIP merely helps you find each other, in this context
• [9:27] Tao Takashi: and how are groups named?
• [9:27] Saijanai Kuhn: are servers part of hte AD, or merely conected THROUGH the ad... or is that an implementation detail?
• [9:27] Tao Takashi: Gridnauts@secondclife.com ?
• [9:27] Saijanai Kuhn: all of which is addressed while getting the current protocol set up to work with the AD
• [9:27] Zero Linden: Sai - that would be hard - the viewer desn't have a UDP relationship with the AD
• [9:28] Tao Takashi: we need some lightweight viewer to experiment with
• [9:28] Saijanai Kuhn: that's the only chnge... convert the IIM to the XML-LLSD
• [9:29] Saijanai Kuhn: You've got the client setup to handle all other UDP packets that way, so why not IIM?
• [9:29] Zero Linden: okay - so imagine that we had provisional_im/improved_instant_message as a resource in both the viewer (accessed via the event queue) and in the
• agent domain (accessed via cap)
• [9:29] Saijanai Kuhn: or is IIM an exc3eption?
• [9:29] Zero Linden: then, yes, we could build a viewer that did the IM via the agent domain without much work..... methinks
• [9:30] Saijanai Kuhn: "much work" to get all the current functionality (in theory) working, so we can test different designs, trust models for inventory, etc.
• [9:30] Zero Linden: the format of POSTs to that resource class would mirror the LLSD representation of the current UDP message
• [9:31] Mug of: Coffee : Hot strong coffee!!
• [9:31] Saijanai Kuhn: right, not sure if there is an isue with the binary bucket part, but that seems relatively easy to handle, compared to all this "which protocol"
• stuff we have ben arguing
• [9:31] Tao Takashi: I have to get back to work but thanks for the good discussion :)
• [9:31] Tao Takashi: see you at tomorrow's pyogp meeting
• [9:31] Saijanai Kuhn: KK
• [9:32] Saijanai Kuhn: hopes to have a closer to working GUI by then
• [9:32] Tao Takashi: and I hope to have had time to look at recent changes and the legacy login