AW Groupies/Chat Logs/AWGroupies-2008-09-30

• [9:36] Latha Serevi: hi Sai
• [9:36] Rex Cronon: hi sai
• [9:36] Saijanai: Kuhn: hey all
• [9:36] Saijanai Kuhn: admires the totally grey landcape with stuff popping in
• [9:36] Rex Cronon: r u using the new rc?
• [9:37] Saijanai: Kuhn: yeah
• [9:37] Rex Cronon: u had to download it?
• [9:37] Tao Takashi: Hi
• [9:37] Rex Cronon: there was no notice on the main page about a new rc
• [9:37] Rex Cronon: hi tao
• [9:38] Rex Cronon: i checked like 20 minutes before
• [9:40] Latha Serevi: There were a couple of group IM's to the effect that Zha's on vaca, and some jokes about her having kidnapped Sai.
• [9:40] Latha Serevi: If we can get a quorum, my favorite/only topic revolves around groups. Dale Innis and I always agree on problems and disagree wildly on solutions. I hope we can touch upon this email comment from Dale at today's 9:30 Groupies: "So far we haven't been talking much about the non-IM aspects of groups. I'm sure that interesting new considerations will appear when we do."
• [9:40] Saijanai: Kuhn: well, that would be intersting sense I've been here every day
• [9:41] Bartholomew Kleiber: Hi all
• [9:41] Tao Takashi: who knows who is sitting at your computer ;-)
• [9:41] Tao Takashi: Hi Barth
• [9:41] Rex Cronon: hi bartholomew
• [9:41] Kopilo Hallard: greetings
• [9:41] Rex Cronon: hi kopilo
• [9:41] Tao Takashi: well, I might be a little quiet today as I have stuff to do
• [9:41] Kopilo Hallard: it could be some psychotic pizza loving geek!
• [9:43] Kopilo Hallard: waves hello to the familiar faces
• [9:43] Saijanai: Kuhn: Tao, correct me if I'm wrong, but there's no permanent object associated with avatar data in pyogp, right? no place to store name/password, etc?
• [9:44] Tao Takashi: no, that's part of what the app needs to do
• [9:45] Tao Takashi: well, the passwordcredential is an object which holds this data
• [9:45] Gareth Ellison: greetings
• [9:45] Saijanai: Kuhn: right. Was trying to decide on a structure for the GUI/commandline/external conotroller
• [9:45] Kopilo Hallard: greeting gareth
• [9:45] Tao Takashi: Hi Gareth
• [9:45] Rex Cronon: hi garter
• [9:45] Rex Cronon: i mean gareth:)
• [9:45] Bartholomew Kleiber: Hi Gareth
• [9:46] Gareth Ellison: we got an agenda of any kind today?
• [9:46] Saijanai: Kuhn: I'm thking that we can create a dictonary of such avatar objects with the name as the key
• [9:47] Rex Cronon: group ims
• [9:47] Gareth Ellison: ah
• [9:47] Saijanai: Kuhn: and send comands relevant to each by naming the avatar,
• [9:47] Gareth Ellison: IRC or IRC-like
• [9:47] Gareth Ellison: that's a proven system
• [9:47] Gareth Ellison: and i'm not saying much beyond that
• [9:47] Gareth Ellison:  :)
• [9:47] Rex Cronon: ask latha
• [9:48] Saijanai: Kuhn: not familiar enough with any system to coment. Just recall that Zero and Zha both say that normal IRC may have problems with SL behavior for group IM
• [9:48] Bartholomew Kleiber: I am totally +1 with what Dahlia wrote today in the mailing list.
• [9:48] Gareth Ellison: normal IRC would have small issues
• [9:48] Gareth Ellison: but an IRC-like protocol would work great
• [9:48] Tao Takashi: my main thing is not so much about IRC yes/no but mostly about enabling as many possible systems as possible
• [9:49] Kopilo Hallard: it would have to support multicast right?
• [9:49] Tao Takashi: then people will figure out the best way to implement it
• [9:49] Bartholomew Kleiber: even better, right
• [9:49] Gareth Ellison: i dislike the idea of multiple possible systems - since we burden client/server devs (both of them) with having to implement them all OR risk being incompatible
• [9:49] Gareth Ellison: we should standardise on one protocol
• [9:49] Tao Takashi: which means the less an AD has to provide the better.. because it would be great if you don't need to run an AD in order to play around with your IM implementation
• [9:49] Kopilo Hallard: *nods*
• [9:49] Tao Takashi: there can be one standard way of doing it we propose
• [9:50] Latha Serevi: I duno if we have much of a quorum for "what are groups and how to manage them" discussion. My own interest is in the non-IM side. BTW, I think there should be two different kinds of groups, totally-insecure and totally-secure
• [9:50] Saijanai: Kuhn: well, if the AD doesn't handle authentication for EVERYTHING, then you run the risk of having multiple authentication systems for the same avatar
• [9:50] Tao Takashi: can be bound together by OAuth
• [9:51] Tao Takashi: or other techniques but that's a standardized one and gaining momentum
• [9:51] Rex Cronon: there is no such thing "totally-secure"
• [9:51] Latha Serevi: "secure enough to handle land management", then
• [9:51] Tao Takashi: I guess we mean "as-secure-as-we-can-get" ;-)
• [9:51] Saijanai: Kuhn: yeah, but you can have models that inherently are less easy to secure
• [9:51] Gareth Ellison: i think we need to take a leaf from HTTP's book
• [9:51] Gareth Ellison: and allow some equivalent of the Upgrade: header
• [9:52] Gareth Ellison: i.e make it forward compatible, but for the sole purposes of future protocol enhancements
• [9:52] Gareth Ellison: and promote only 1 official group IM protocol
• [9:52] Gareth Ellison: in the standard OGP spec, we should have that 1
• [9:52] Tao Takashi: it still would be nice though to reuse existing services even if they are not as-secure-as-we-can-get
• [9:52] Kopilo Hallard: I agree with gareth
• [9:53] Saijanai: Kuhn: well, seems to me that there might be one "official" protocol, but that the OGP needs to allow queries to establish multiple lines of communication via the AD
• [9:53] Kopilo Hallard: with using one protocol
• [9:53] Gareth Ellison: we can have optional enhancements, but the spec should state they are optional and implementations may not support them
• [9:53] Gareth Ellison: sai - that's what i'm getting at
• [9:53] Saijanai: Kuhn: OK
• [9:54] Latha Serevi: There are issues of authentication in OGP; don't we want to have some kind of cross-grid-chat that does NOT depend on ironclad authentication?
• [9:54] Latha Serevi: lowest common denominator vs best-we've got
• [9:54] Gareth Ellison: latha - why do we want to make authentication un-important?
• [9:54] Gareth Ellison: i'd say that's a vital issue
• [9:54] Gareth Ellison: authentication can be handled using standard PKI methods
• [9:55] Latha Serevi: Because then if Lively doesn't play our best-practices authentication game, we can't chat with them.
• [9:55] Gareth Ellison: quick offtopic question: what's the viewer param to yield a small amount to the OS?
• [9:55] Saijanai: Kuhn: Latha, right. BUT... that's where alternative channels come in.
• [9:55] Gareth Ellison: again, HTTP comes in
• [9:55] Gareth Ellison: HTTP and HTTPS
• [9:56] Saijanai: Kuhn: Gareth you mean a command line option?
• [9:56] Bartholomew Kleiber: [1]
• [9:56] Gareth Ellison: thanks
• [9:56] Bartholomew Kleiber: np
• [9:56] Saijanai: Kuhn: beat me to it
• [9:56] Bartholomew Kleiber: yay!
• [9:56] Kopilo Hallard: in client terminal :O
• [9:56] Tao Takashi: in fact nobody will play our best practives auth game if we don't play the games which are around (like OAuth or OpenID) ;-)
• [9:57] Kopilo Hallard: xD
• [9:57] Latha Serevi: So y'all are saying, "chat bridge" style IM is looser and to-be-defined-by-somebody-else-later, and you're more interested in the "real internal OGP group IM" ?
• [9:57] Kopilo Hallard: btw why are we standing?
• [9:57] Bartholomew Kleiber: are we?
• [9:58] Latha Serevi: Because sitting just ties you down, man.
• [9:58] Bartholomew Kleiber: listens to Pink Floyds 'Dogs'
• [9:58] Tao Takashi: I am all about the AD delegating it's work by handling authorization and service discovery
• [9:59] Tao Takashi: small components
• [9:59] Kopilo Hallard: service discovery? like jini?
• [10:00] Latha Serevi: I'm interested in, and concerned about, how we do authentication in OGP. Can we at least modularize it, so we don't have to go back and re-do group IM when we realize how we wanted to do authentication in the first place?
• [10:00] Kopilo Hallard: *nods*
• [10:01] Tao Takashi: like XRDS-Simple
• [10:01] Saijanai: Kuhn: well, the current scheme is just the name/password login. OTher authentication thigns wil happen between the AD and some other service. The AD acts as the proxy for the Agent, sothe agent need not login to the other service
• [10:01] Tao Takashi: firday is a holiday which is when I will try to write something down about all this :)
• [10:02] Tao Takashi: right now I am more in post-vacation workload
• [10:02] Latha Serevi: Anybody have opinions on Shibboleth? [2]
• [10:03] Kopilo Hallard: *reads*
• [10:03] Bartholomew Kleiber: wasnt aware of it
• [10:03] Latha Serevi: Seems to be somewhat like OAuth, but a bit more general. "The operation of the Shibboleth System is based on, and conforms to, the Security Assertion Markup Language (SAML) standard (version 1.1), published by OASIS [(http://www.oasis-open.org/)"] ...
• [10:04] Teravus Ousley: I dunno.. Shibboleth.. OpenID.. LiveID.. all disparate standards..
• [10:04] Latha Serevi: Shibboleth has groups.
• [10:04] Latha Serevi: What I don't know is, if it's bloated, usable, etc.
• [10:05] Teravus Ousley: didn't know about it before you mentioned it.. so .. potentially.. might not be highly popular
• [10:05] Bartholomew Kleiber: any info on what projects use it?
• [10:05] Tao Takashi: from what I heard at the IdentityCamp it's a bit too hierarchical to be used for free form situations like the web
• [10:05] Tao Takashi: we had somebody from a swiss university talking about it
• [10:05] Latha Serevi: Seems to be oriented toward university student ID's
• [10:05] Bartholomew Kleiber: ETH Zurich?
• [10:05] Tao Takashi: the problem was to decide who is allowed into the realm and not IIRC. And this needs some institution handling it
• [10:06] Tao Takashi: I don't think it was ETH but it's big in switzerland
• [10:06] Bartholomew Kleiber: well, that sounds like what is needed here.
• [10:06] Tao Takashi: not really, I don't want a global institution deciding who is allowed to access what
• [10:06] Saijanai: Kuhn: Tess incoming
• [10:06] Bartholomew Kleiber: ah right, the 'Verizon' lemma.
• [10:06] Kopilo Hallard: Hoooo!
• [10:07] Bartholomew Kleiber: we got incoming
• [10:07] Tao Takashi: and OAuth is also not about authentication but authorization. It's main purpose is to give access to certain services without the need to give out your password
• [10:08] Kopilo Hallard: that sounds like what is needed for IMs
• [10:08] Tao Takashi: probably for many things
• [10:08] Tao Takashi: also more and more services use it, like Google or MySpace
• [10:09] Latha Serevi: Well, their main use-case is an individual human at a web-browser trying to give permission for a photo-sharing site to give a photo to a photo-printing site.
• [10:09] Gwen Hermit: 2 viewers were disliked :(
• [10:09] Kopilo Hallard: greetings Tess
• [10:09] Gwen Hermit: is Gareth
• [10:09] Tess Linden: hey :)
• [10:09] Tao Takashi: Hi Tess
• [10:09] Rex Cronon: hi tess
• [10:09] Tess Linden: You were talking about group IM?
• [10:09] Tao Takashi: so we have 2 services here: an AD and an IM service
• [10:09] Kopilo Hallard: yeap
• [10:10] Tao Takashi: and it doesn't need to be a web browser
• [10:10] Gwen Hermit: oddly, this runs much better inside firefox
• [10:10] Latha Serevi: Sort of, Tess. And authentication/trust related to such.
• [10:10] Tess Linden: Tao: 2 services?
• [10:11] Latha Serevi: My proposal that there be two distinct kinds of groups, ultra-insecure and ultra-secure, hasn't gained traction.
• [10:11] Bartholomew Kleiber: nah, it just wasnt commented yet
• [10:11] Bartholomew Kleiber: I am in favour
• [10:11] Bartholomew Kleiber: also to the modularization
• [10:11] Tao Takashi: Tess: I see OGP as a bundle of many service actually
• [10:12] Tao Takashi: services
• [10:12] Kopilo Hallard: I don't mean this to sound rude, but what is the point of ultra insecure?
• [10:12] Latha Serevi: (use case 1 - very portable cross-grid chat, ultra insecure)
• [10:12] Bartholomew Kleiber: mainly because we dont know which of theses 'standards' will be standard
• [10:12] Tao Takashi: insecure might be when you access a regular IRC server without AD support
• [10:12] Latha Serevi: (use case 2, land management - ultra secure)
• [10:12] Tao Takashi: I think the main point is to make clear to the user how identified chat participants are
• [10:13] Kevin Paisley: ox31cd4a
• [10:13] Tao Takashi: and actually the IM service can also belong to another AD as long as we are not just talking about intra-AD IM
• [10:13] Rex Cronon: i don't think that anybody would feel confortable being in the "ultra-insecure" mode
• [10:14] Saijanai: Kuhn: normal IRC is ultra insecure, IMHO
• [10:14] Kopilo Hallard: /agree
• [10:14] Gwen Hermit: IRC can use SSL and password auth
• [10:14] Tao Takashi: ultra insecure = normal web ;-)
• [10:14] Latha Serevi: ultra portable
• [10:14] Saijanai: Kuhn: Gwen, sure, but that's not "normal"
• [10:14] Gwen Hermit: and with the right set of services, it can handle secure authentication of users and channels
• [10:14] Bartholomew Kleiber: as ong as it's ultra ... *shrugs
• [10:14] Gwen Hermit: it's not highly weird
• [10:14] Rex Cronon: neverthless people still use the web to do monetary transactions
• [10:14] Gwen Hermit: something supported out the box on nearly all IRCDs
• [10:14] Kopilo Hallard: lol
• [10:15] Latha Serevi: How private and secure is today's Groupies chat?
• [10:15] Tao Takashi: we don't know ;-)
• [10:15] Kopilo Hallard: xD
• [10:15] Tao Takashi: as we cannot look at the implementation
• [10:15] Bartholomew Kleiber: I bet somone over at google is reading this
• [10:15] Tao Takashi: LL is reading this..
• [10:15] Tess Linden: despite man in the middle possibilities, all traffic does go through SL servers at least
• [10:15] Bartholomew Kleiber: waves
• [10:15] Saijanai: Kuhn: its more secure than it used to be I think.
• [10:15] Gwen Hermit: nobody not on this sim or without access to a sniffer on the network between you and the sim can read it other than LL
• [10:15] Tao Takashi: that's enough to consider it as insecure ;-)
• [10:15] Kopilo Hallard: but we know it is being stored at minimally 10 different locations
• [10:15] Latha Serevi: Nor care. It's quite private, perhaps, until Sai posts the transcript to the open web. Which I approve of wholeheartedtly, BTW.
• [10:16] Bartholomew Kleiber: Sai - you are a mole?
• [10:16] Saijanai: Kuhn: usually don't with gorup IM unless its an arranged meeting
• [10:16] Kopilo Hallard: rofl
• [10:16] Saijanai: Kuhn: though I have been known to quote Prokofy extensively in private
• [10:16] Bartholomew Kleiber: LOL
• [10:17] Gwen Hermit: "this isn't something you treat like a frig" < prok quote
• [10:17] Latha Serevi: So, "clarity of purpose" is something that we'll want to try to facilitate, social engineering wise. The posting of transcripts is publicly announced; good transparency for us.
• [10:18] Kopilo Hallard: so: anyone against the ultra-insecure, ultra-secure system?
• [10:18] Gwen Hermit: btw, about IRC being ultra-insecure - who actually bothers themselves on IRC with the security issues? sensitive matters get taken to an SSL-only server or get taken somewhere else
• [10:18] Rex Cronon: i am against the "ultra-insecure" system:)
• [10:18] Kopilo Hallard: rofl
• [10:19] Latha Serevi: You don't want to be able to set up a chat bridge, Rex?
• [10:19] Tao Takashi: I am for a system which allows unpatched services to be used as well
• [10:19] Saijanai: Kuhn: well, right now gorup IM is used to send money and items
• [10:19] Tao Takashi: like irc.freenode.net
• [10:19] Tess Linden: I like Latha's idea of the 2 different types of trust
• [10:19] Rex Cronon: i don't like its name, i think it should be called "normal" system:)
• [10:19] Tao Takashi: so if that's the ultra-insecure/secure model then I favor it
• [10:19] Rex Cronon: right now it can scare people aways
• [10:19] Gwen Hermit: sai - let's seperate IM from other issues
• [10:19] Tess Linden: I've been thinking of the Agent Domain as the thing that vouches for your identity or vouches for others to trust you
• [10:19] Tao Takashi: it just needs to made clear to the user how secure it is
• [10:19] Gwen Hermit: oh, and brb
• [10:20] Saijanai: Kuhn: well, they are conflated right now. If we develop a secure IM system, it should probably be useable (or the model if tnot the protocol) for what gorup IM is already being used for
• [10:20] Tess Linden: IM's won't be used to send money and inventory going forward
• [10:20] Tao Takashi: there also might be OGP-enabled IM services which still allow "normal" participants in, then also it should be made clear who is authenticated by an AD (and which probably) and who isn't
• [10:20] Teravus Ousley: no Binary Bucket use :D
• [10:20] Saijanai: Kuhn: Tess, didn't expect it would. But the problems for money transfer are the same as problems for "secure" gorup IM I think
• [10:21] Tao Takashi: IM will only be used to send love :)
• [10:21] Kopilo Hallard: >_>
• [10:21] Kopilo Hallard: IM could contain banking details
• [10:21] Bartholomew Kleiber: ultra love?
• [10:21] Tao Takashi: ultra secure love
• [10:21] Kopilo Hallard: lol
• [10:21] Bartholomew Kleiber: wow
• [10:21] Tao Takashi: good luck with that ;-)
• [10:21] Latha Serevi: I wonder if there's a way to define a general enough group IM protocol that there can be two instantiations of it. In the less secure, the "are you a member of the group" doesn't involve crypto authentication, but just asking a service.
• [10:21] Rex Cronon: u mean XXX im?
• [10:22] Teravus Ousley: money/transactions over CAPS please! :D
• [10:22] Kopilo Hallard: good idea Latha
• [10:22] Latha Serevi: ...and the "make a connection to receive IM stream" can be either SSL or not ...
• [10:22] Kopilo Hallard: maybe even just use pseudo keys for the instance, like mobile transactions in austia?
• [10:23] Tao Takashi: the IM service could ask the AD back if the user is who it claims to be
• [10:23] Tess Linden: if we make the client -> server messages secure, with the current architecture, it should be secure
• [10:23] Kopilo Hallard: *nods*
• [10:23] Saijanai: Kuhn: seems there would be three levels: not-secure, AD secure, and via encrypted CAP that the AD can't use
• [10:24] Tess Linden: I'm confused, whats the CAP that the AD can't use ?
• [10:24] Saijanai: Kuhn: Was a use case Zero mentioned
• [10:25] Latha Serevi: The third may be a separate "encrypted content" capability, and there are really only two IM levels plus two kinds of content
• [10:25] Saijanai: Kuhn: If your company wants to establish a line of communcation with your avatar, it can send an enncrypted cap via the AD that YOUR client alreadyknows how to unencrypt
• [10:25] Rex Cronon: u mean decrypt?
• [10:26] Saijanai: Kuhn: decrypt, yes
• [10:26] Kopilo Hallard: *confused* you mean sychnous or asychronous encryption?
• [10:27] Saijanai: Kuhn: not sure what you mean there
• [10:27] Kopilo Hallard: shared public key
• [10:27] Kopilo Hallard: vs, public private key
• [10:27] Saijanai: Kuhn: The cap is encrypted at the company end, sent via normal AD channels to the client, which decrypts and establishes a separate IM channel outside AD knowledge
• [10:28] Saijanai: Kuhn: can't do a man int he middle attack on a url that is encrypted
• [10:28] Saijanai: Kuhn: for times when the AD isn't trustworthy enough
• [10:28] Kopilo Hallard: *nods*
• [10:29] Latha Serevi: Y'all take my point that "communication pipe" and "contents going thru pipe" can be distinguished?
• [10:29] Latha Serevi: And that there aren't three IM use cases at all, thn?
• [10:30] Saijanai: Kuhn: well, not sure what you mean
• [10:30] Bartholomew Kleiber:  ?
• [10:30] Tess Linden: so this is for the use case of your wanting a secure IM channel outside of the AD through another network that you trust differently from your AD?
• [10:30] Saijanai: Kuhn: the encrypted cap isn't a pipe that the AD knows about
• [10:30] Latha Serevi: Or rather, there aren't three "kinds", but 2x2 options of (insecure who-to, secure who-to) x (unencrypted content, encrypted content)
• [10:31] Saijanai: Kuhn: Tess, righty. someone in your company wants secure chat via teh virtual worlds system
• [10:32] Tess Linden: Sai: but your AD is not part of the company
• [10:33] Latha Serevi: So those things sent via the AD must not be crackable by it, in order to be company-secure. e.g. an encrypted cap.
• [10:33] Tao Takashi: wouldn't it be easier to open a direct connection to some secure IM service?
• [10:34] Kopilo Hallard: not only that but it might be more secure
• [10:34] Saijanai: Kuhn: Tao, sure, but maybe the virtual worlds thing is important for some reason
• [10:34] Latha Serevi: Easier, except for giving up the AD's help in discovering group membership?
• [10:34] Saijanai: Kuhn: Tess, yes, but if the CAP is sent encrypted, the AD can't use it
• [10:35] Tao Takashi: well, when you are inside an IM you are inside a window anyway.. maybe in the very secure case I would even want to not involve the AD on purpose
• [10:35] Teravus Ousley: hrms
• [10:35] Teravus Ousley: tries to figure out what Saijanai means when he says 'encrypted'
• [10:35] Rex Cronon: u could encrypt your messages, send them over the IM system:)
• [10:35] Saijanai: Kuhn: Tao, sure, but then you lose out on whatever services the AD can offer, like establishing who is online in your group
• [10:35] Rex Cronon: or group chat:)
• [10:36] Rex Cronon: or u could do it in public chat, and nobody would understand a thing:)
• [10:36] Kopilo Hallard: btw when you say group chat do you mean conferences as well?
• [10:36] Latha Serevi: There seems to be a capabilities equivalent to a "secure encrypted envelope", that allows a cap to be passed via insecure channel but not be useable by any man-in-the-middle. I think that's what Sai is referring to. Could presumably be used for private messages, as well as non-stealable caps.
• [10:38] Saijanai: Kuhn: Latha from whatsisname's thesis right? That's where I got the idea, but no need for anythng more elaborate than standard public/private key encyrption for this scenario
• [10:38] Teravus Ousley: I dunno.. SSL ultimately results in the same 'stuff' that you get over HTTP.. it's just got two added features.. 1. Can't be decrypted by someone listening Except by through a proxy or something like that . 2. You can verify that the person with the public key is who they say they are.. because we've previously established trust..
• [10:38] Teravus Ousley: so.. Caps over HTTPS = secure mode
• [10:39] Saijanai: Kuhn: except if you don't sufficiently trust the AD to know about hour billion dollar corporate secret
• [10:39] Rex Cronon: my net connection went down 4 like 2 minutes:(
• [10:39] Kopilo Hallard:  :/
• [10:39] Tao Takashi: Sai: the IM service can provide me with information who is logged in to it
• [10:39] Bartholomew Kleiber: Teravus: +1
• [10:40] Kopilo Hallard: xD
• [10:40] Teravus Ousley: Well, that's a item of trust.. that you'd have to establish beforehand.. or.. if they don't want to bother.. they could turn off certificate authority chain validation
• [10:41] Teravus Ousley: Anyway.. that seems to give service providers enough control and options..
• [10:41] Saijanai: Kuhn: dunno.
• [10:43] Rex Cronon: .
• [10:43] Teravus Ousley:  ! :D
• [10:43] Bartholomew Kleiber: ..?
• [10:44] Teravus Ousley: yeah.. the crickets are out tonight.
• [10:44] Kopilo Hallard: *listens to the symphony of crickets*
• [10:44] Bartholomew Kleiber: lol
• [10:44] Rex Cronon: i thought i lost connection again
• [10:44] Saijanai: Kuhn: hmmm zha still not online, even for IM
• [10:45] Teravus Ousley: maybe got stuck in traffic or something..
• [10:45] Bartholomew Kleiber: I have to go now, cu all
• [10:45] Rex Cronon: bye barth
• [10:45] Latha Serevi: Anybody know who might end up defining the IM protocol? Is all this OGP stuff being chatted-about by us, and then done by Lindens under their control?
• [10:45] Bartholomew Kleiber: be back on IRC later
• [10:45] Kopilo Hallard: to be honest I think conferences and ims should be encrypted because generally people use IM and conferences for private conversations
• [10:46] Kopilo Hallard: where as group im is more general and like local chat
• [10:46] Tao Takashi: I guess Lindens will implement their caps based IM service in order to stay backwards compatible
• [10:46] Teravus Ousley: Latha.. write up a spec.. I think .. would be the best way to submit your idea.
• [10:46] Tess Linden: hey c'mon Latha. We're talking about this very openly, and nobodys controlling anything.
• [10:46] Rex Cronon: do u need e encript?
• [10:46] Rex Cronon: who can intercepy?
• [10:46] Tess Linden: why would LL implement something that people don't want?
• [10:47] Latha Serevi: Tess - the Lindens are being great about doing OGP openly, but if I ever disagree with the approach, I'm gonna lose the argument by definition.
• [10:47] Kopilo Hallard: heh?
• [10:47] Tess Linden: thats not true. If you make a good argument and it's the right thing to do then it would be stupid of us to implement it the wrong way.
• [10:47] Latha Serevi: So, I'm mentioning it now and then, to see if we Groupies and other non-LL open gridders might need to establish a separate pole of influence.
• [10:48] Latha Serevi: Tess: it's obvious that all decisions will be made by LL in the end, if the work is being done by Lindens on a linden site.
• [10:48] Tao Takashi: the question is the difference between the spec and the implementation.. and on LLs side there might also be business implications like the amount of work to rewrite the whole IM system without any clue if the new one will be scalable as needed
• [10:48] Latha Serevi: I'm not saying this is because the lindens are being mean; but rather that the rest of us aren't doing our job to stay a little independent.
• [10:49] Tess Linden: but Linden chose to work on this stuff openly, we're at the AWG that Linden started a year ago
• [10:49] Tao Takashi: which is again a reason why I propose an open architecture.. then LL can implement their "proven" system and others can experiment with their ideas and in the end we will see what will work best
• [10:49] Latha Serevi: Right - Linden is "choosing" to listen to Groupies. But, if we started defining an OGP-ish protocol over at Opensimulator and gained enough momentum that LL had to join _us_, then LL lawyers wouldn't rule the grid.
• [10:50] Saijanai: Kuhn: well, its why I'd like to see the current system proted to the AD as-is. SO we can see how the current systembehaves and have a workign model to work from
• [10:50] Saijanai: Kuhn: current group IM, that is
• [10:50] Latha Serevi: I'm just mentioning this periodically so we realize that we're under LL auspices and "helping" with something we don't "control"
• [10:50] Kopilo Hallard: *tries to hide the grave digger shovels*
• [10:51] Teravus Ousley: isn't really interested in 'competition' personally... would rather work together
• [10:51] Tao Takashi: the main problem is I guess that there is no real process which defines how the spec is defined and who decides what in the end.
• [10:51] Latha Serevi: There is a process, Tao. The Lindens currently assigned to OGP decide.
• [10:51] Tao Takashi: I am also for working together but keeping the possibility to plug something new in cannot be bad ;-)
• [10:52] Rex Cronon: if u can the approval of Mr M, u can consider it done:)
• [10:52] Saijanai: Kuhn: so far, I haven't seen any problems with how the OGP is progressing. Ther's a storng incentive to make OGP SL-compatible, OS-compatible AND generic enough to be used by other VW's
• [10:54] Latha Serevi: Right - and I hope to continue all this - but establish a little bit of an OpenSim "moral center" also.
• [10:54] Tao Takashi: Here is the process for OPenSocial btw: [3]
• [10:54] Latha Serevi: Hence the occasional reminder that we are forgetting to stay independent because we love LL so much.
• [10:55] Latha Serevi: What is OpenSocial anyway? Never heard of it.
• [10:55] Teravus Ousley: OpenSimulator uses the 'OpenSocial' process internally
• [10:55] Tao Takashi: It was started by Google and is a general way to implement Facebook like apps
• [10:55] Tao Takashi: but in the meanwhile it's a standalone foundation
• [10:55] Teravus Ousley: .. the process for spec anyway.
• [10:56] Tao Takashi: and it can be used for more than just writing vampire apps ;-)
• [10:56] Teravus Ousley: .. + votes.. - votes have to be resincded.. etc..
• [10:56] Tao Takashi: like it's also defining a sort of complete data structure for profile information
• [10:56] Rex Cronon: vampire apps?
• [10:56] Tao Takashi: aren't thos apps the most deployed ones on Facebook?
• [10:56] Tao Takashi: so myspace uses it in conjunction with OAuth to make their data available to third party sites
• [10:57] Tao Takashi: as it also defines a REST interface
• [10:58] Tao Takashi: and I was a while in their spec discussion group and it seemed quite a good process at least from glancing over it
• [10:58] Tao Takashi: but they also have a dedicated group of people at Google managing it I think
• [10:59] Teravus Ousley: Well.. I don't think there's an issue with the process for most things.... Though.. based on the way the SL Community has reacted to some topics.. I'm not entirely sure using that process for everything would be super productive.
• [10:59] Latha Serevi: Thanks for the info on OpenSocial, Tao. Should we all be paying attention to that, and drafting off them in some ways, I wonder?
• [10:59] Teravus Ousley: -votes are essentially 'vetos'
• [11:00] Teravus Ousley: and.. we'll always have -votes
• [11:00] Rex Cronon: bye everybody
• [11:00] Kopilo Hallard: bye
• [11:00] Rex Cronon: have fun
• [11:00] Kopilo Hallard: you to :)
• [11:01] Tao Takashi: well, I think OpenSocial could be useful for managing profile information as mySpace does
• [11:01] Tao Takashi: but that can always be added regardless of OGP
• [11:01] Tao Takashi: then again if profile information needs to be transferred why not use the OpenSocial structure directly
• [11:02] Kopilo Hallard: heh
• [11:02] Tao Takashi: (I guess because they don't use LLSD ;-) )
• [11:02] Kopilo Hallard: LLSD is a trip ;)
• [11:03] Tao Takashi: they use a thing called JSON ;-)
• [11:03] Kopilo Hallard: >_>
• [11:03] Kopilo Hallard: how trustworthy is opensocial though...
• [11:04] Kopilo Hallard: it's not like myspace profiles haven't been "hacked"
• [11:04] Tao Takashi: that's a myspace issue
• [11:05] Tao Takashi: and it's just a REST interface with JSON data going through, so if you use SSL I don't see the problem
• [11:05] Tao Takashi: normal web service stuff
• [11:05] Kopilo Hallard: *nods*
• [11:05] Tao Takashi: while the request is signed with the OAuth token
• [11:05] Tao Takashi: so not everybody can access it
• [11:06] Kopilo Hallard: makes sense
• [11:06] Teravus Ousley: ... another meeting to attend.
• [11:06] Tao Takashi: now make myspace be the AD and the other service the IM system and then use this call to retrieve profile information
• [11:06] Teravus Ousley: take care
• [11:06] Tao Takashi: if that does not work, the agent is not identified and either kicked or marked as such
• [11:06] Kopilo Hallard: tkae care
• [11:06] Tao Takashi: take care Teravus
• [11:07] Kopilo Hallard: *nods*
• [11:07] Kopilo Hallard: similar to hashing
• [11:07] Tao Takashi: and I am quite sure we can use a similar model here with IM
• [11:07] Kopilo Hallard: *nods*
• [11:07] Tao Takashi: of course you need to trust the IM service
• [11:07] Tao Takashi: but you need to trust it anyway ;-)