View source

*[12:34pm] Saijanai: I can type again
*[12:35pm] MrTopf: and somehow all these discussions seem to go in circles.
*[12:35pm] MrTopf: was there anything noteworthy in one of the last OHs with Zero?
*[12:35pm] Saijanai: anyway I've been trying to understand how pyogp works and finally starting to., I think
*[12:36pm] Saijanai: don't recall. Whump annnced ogp draft 3 at his OH
*[12:37pm] MrTopf: yeah, I saw that on the list
*[12:37pm] MrTopf: and quickly looked at it and made a comment
*[12:37pm] MrTopf: I also wish I'd have more time to write some more up about trust, IM services and service discovery
*[12:38pm] MrTopf: but basically regarding IM I think one step migth be the AD announcing their preferred (and trusted) IM services
*[12:38pm] MrTopf: and each user might also have an discoverable preferred IM service (which might be the same as it's AD's ones)
*[12:38pm] MrTopf: and the AD could have some API which says "yes, this is indeed user X"
*[12:38pm] Saijanai: there was an irc discussion about CA that you might want to look at: https://wiki.secondlife.com/wiki/User:Infinity_Linden/Gridnauts_2080913
*[12:39pm] Saijanai: infinity was part of the CA group apparently
*[12:39pm] Saijanai: *[11:30am] infinity__: i was Bell Canada's rep to the X.509 committee for a while
*[12:39pm] MrTopf: I am very suspicious about anything regarding certs
*[12:39pm] MrTopf: Infinity was quite a lot in the past it seems
*[12:40pm] Saijanai: he and zero apparently get along
*[12:40pm] MrTopf: seems so
*[12:41pm] Saijanai: anyway, I understand a little more about the pyogp now. Got 2 minor bits working that wil help
*[12:41pm] MrTopf: great that they managed to get Draft 3 out of the door.. structure looks better than before
*[12:41pm] Saijanai: yes
*[12:41pm] MrTopf: ah, that's great
*[12:42pm] Saijanai: i created a text control that can accept sys.stdio output so you can redirect logging to it (as many different text controls as you want)
*[12:42pm] MrTopf: cool, is the code available somewhere?
*[12:42pm] MrTopf: (or will be after my vacation)
*[12:42pm] Saijanai: so you can log errors or prtin formatted packet info into two different parts
*[12:42pm] MrTopf: sounds like a good thing for a proxy
*[12:42pm] Saijanai: hang on its quite trivial thought it took a while to find an example
*[12:42pm] MrTopf: yeah, I think you mentioned this last week
*[12:43pm] Saijanai: the other is a decorator that takes methods and puts them into a list, so that they can b called sequentially, one at a time, or all at once
*[12:44pm] Saijanai: this would replace, say, the example login code so that you could run it from a command line, or from an idle or timer event from a wx window
*[12:45pm] MrTopf: sounds goof
*[12:45pm] MrTopf: good
*[12:46pm] Saijanai: http://pastebin.com/m44a5bf4e
*[12:46pm] MrTopf: btw, regarding the IM discussion I think the avi is simply online if it's logged in to the IM service
*[12:47pm] Saijanai: so you'd break the login code into pieces and decorate each piec
*[12:47pm] MrTopf: so being online is local to the IM service. But there might still be a general presence API
*[12:47pm] Saijanai: well, if the IM is an "official" virtual world API, you might want to allow login ONLY through the AD
*[12:48pm] MrTopf: the IM service could choose to let only properly authenticated agents in
*[12:48pm] MrTopf: thus the API in the AD which can say "yes this is user X"
*[12:48pm] Saijanai: sure, but what happens if you login separately, than login via the ad..
*[12:49pm] MrTopf: you mean it should be denied then?
*[12:49pm] MrTopf: or allowed?
*[12:49pm] MrTopf: the API might still be valid then
*[12:49pm] Saijanai: I guess that's the point.
*[12:49pm] MrTopf: I think it should be allowed
*[12:49pm] MrTopf: because why not?
*[12:49pm] barth13 joined the chat room.
*[12:49pm] MrTopf: but the IM service could of course check if the agent is online on his AD
*[12:49pm] MrTopf: Hi barth13
*[12:50pm] barth13: Hi MrTopf
*[12:50pm] barth13: and all
*[12:50pm] MrTopf: so a "real" virtual world IM service could deny agents which are not online on their AD
*[12:50pm] Saijanai: confusion? The AD authenticates the agent for the services it deals with. If the agent can contact that service directly...
*[12:51pm] Saijanai: seems to me that if someone is online through the AD then they can get connections to the IM through the ad also.
*[12:51pm] MrTopf: that's what I am saying, the AD does not need to authenticate it for every service IMHO
*[12:51pm] Saijanai: if they're using an IRC plugin they can do it any way they want
*[12:52pm] MrTopf: the IRC plugin in some viewer can log the agent in some IM service and that service can then check if it's the right person
*[12:52pm] Saijanai: I guess it goes back to confusion. If the AD authenticates for the Agent, ten is it wise to allow multiple authentication methods
*[12:53pm] MrTopf: reminds me of OAuth, because then you can once establish a relationship between two services without giving the password around
*[12:53pm] MrTopf: I wonder though how you handle global groups
*[12:53pm] MrTopf: like groups spanning ADs
*[12:53pm] barth13: If youare talking about what i think you are talking about - I had this same discussion wirh Dale Innis.
*[12:53pm] MrTopf: maybe you just have some very simple AD (like running your own) and your groups are mostly separate from this AD
*[12:53pm] suzyq joined the chat room.
*[12:53pm] Saijanai: I don't know enough about security to know how this ight work, but I have a funny feeling there's a "gotcha" if you allow login without the AD
*[12:53pm] MrTopf: so then it makes sense to have external IM services
*[12:54pm] MrTopf: barth13: I guess it's pretty clear what we are talking about
*[12:54pm] Saijanai: sure, IM services, but if the AD does the login at all, it should always do the login (I think)
*[12:54pm] barth13: yessiree
*[12:54pm] Saijanai: suzyq what do you know about securty and multiple login ponts?
*[12:55pm] barth13: my point then was - nobody knows if barth13 is Bartholomew Kleiber or an evil twin from some parallel universe.
*[12:55pm] MrTopf: I guess it comes back to trust
*[12:55pm] MrTopf: the IM service needs to trust the AD it has to deal with
*[12:55pm] barth13: And come to think of it I am the evil twin.
*[12:55pm] suzyq: Saijanai: "multiple login points"?
*[12:55pm] MrTopf: if it accepts agents from that AD regardless of whether they login at the AD or IM service
*[12:55pm] Saijanai: well specifically an IM service that accepts login via AD OR without the AD
*[12:56pm] suzyq: seems like the regions would have to decide if they "trust" that IM service
*[12:56pm] MrTopf: I think it doesn't matter too much if you login at the AD or IM service except the thing that in the latter case you'd have to login twice
*[12:56pm] suzyq: some use cases that would be fine for... others no
*[12:56pm] MrTopf: what have the regions to do with that?
*[12:56pm] MrTopf: for group chat I mean
*[12:57pm] Saijanai: I was thinking more in terms of confusion. You login with the IM separately and then login with the AD. What happens to the irc?
*[12:57pm] suzyq: regions get to decide what services they trust (pontificating of a graphics nerd, so beware)
*[12:57pm] MrTopf: but for group chat I'd think that the agent domain is the one which needs to trust
*[12:57pm] suzyq: ok, i can go with that.
*[12:57pm] MrTopf: actually I think it's more the IM service which needs to trust the AD and the user needs to trust the IM service she chooses
*[12:58pm] Saijanai: well, you can establish private channels with known recipients without the AD being able to monitor the conversation
*[12:58pm] Saijanai: just pass an encrypted CAP
*[12:58pm] MrTopf: depends on firewalls
*[12:58pm] MrTopf: would be like IRC DCC
*[12:58pm] Saijanai: the AD can't do a man in the middle attack on it
*[12:59pm] MrTopf: but it would already know that user X talked to user Y I guess
*[12:59pm] MrTopf: but maybe we should look at person-2-person chat separately from group chat
*[12:59pm] MrTopf: barth13: what was the conclusion of your talk with Dale?
*[1:00pm] Saijanai: well, a corporate sim could request a private IM sessoin via the AD and th AD wouldn't know anything except that there was a request
*[1:00pm] barth13: Dale felt there was no use case for this
*[1:00pm] MrTopf: for what?
*[1:00pm] MrTopf: for separate IM services?
*[1:00pm] barth13: while I think you can pretty much abstract IRC as a generic group chat
*[1:01pm] MrTopf: I think putting it behind some AD wall would be a mistake.. I really would like to keep the main AD stuff as simple and lean as possible and mostly make it delegate.. This will also help in the future to exchange things and foster experimentation
*[1:01pm] barth13: my point was you can hav a loose coupling of OGP ids to IRC ids.
*[1:01pm] barth13: so your group chat becomes basically an IRC channel
*[1:02pm] MrTopf: well, an IRC nick could be "mrtopf@myagentdomain.com" where "mrtopf" might be my login handle and some API on the AD could give the IM service the full name, whether I am online etc.
*[1:02pm] MrTopf: if I allowed the IM service to access it
*[1:02pm] MrTopf: if not I might be marked as "unkown state" or not allowed at all
*[1:02pm] barth13: this way you can utilize IRC 'as is' for group chats in OGP grids.
*[1:02pm] MrTopf: well, Gareth was also talking about it. But I would actually keep this open what to use.. just provide the right hooks
*[1:03pm] Saijanai: Changes behavior for group IM though, I think
*[1:03pm] MrTopf: this probably means looking at least at Jabber and IRC on how they would be used and get the APIs right
*[1:03pm] suzyq: agent-2-agent should have the agentd involved.... maybe group doesnt?
*[1:03pm] barth13: yes,Gareth, I felt you are pretty much on the same road.
*[1:03pm] MrTopf: agent2agent might also have 2 ADs involved
*[1:03pm] suzyq: yes
*[1:04pm] Saijanai: agentID gets used for group IM to identify the source, I believe
*[1:04pm] MrTopf: well, each agent might have some URL endpoint on which you can send it messages
*[1:04pm] 
suzyq

stabs the "firstname lastname" monster between the eyes
*[1:04pm] MrTopf: the firstname lastname thing is killing me
*[1:04pm] MrTopf: esp. with my agentdomain implementation I had to redo most forms
*[1:04pm] Saijanai: what is the problem?
*[1:05pm] MrTopf: no user management usually works like that
*[1:05pm] MrTopf: like in Plone you always just have username but not firstname lastname
*[1:05pm] suzyq: the rest of the web doesnt work like that
*[1:05pm] MrTopf: yep
*[1:05pm] Saijanai: at least they didnt use middle as well
*[1:05pm] MrTopf: and I also wonder how you write agent names with AD part down
*[1:05pm] MrTopf: "Tao Takashi@secondlife.com" will not really work because of the space
*[1:05pm] barth13: couldnt thsi be escaped? by firstname fanyescapethingy lastname?
*[1:05pm] MrTopf: using "_" is also strange and would not allow _ being part of a name
*[1:06pm] barth13: no, you have to have a special escape sequence
*[1:06pm] MrTopf: I think the best would be to use something like "tao@secondlife.com" and have some alias for the real name
*[1:06pm] suzyq: i like that
*[1:06pm] barth13: yup
*[1:06pm] MrTopf: and I would also be against some UUID as first part
*[1:06pm] MrTopf: that's not rememberable
*[1:07pm] MrTopf: and I would like this part to be rememberable
*[1:07pm] MrTopf: having distinct login names on each AD might also not be that problematic
*[1:07pm] MrTopf: every social network has that
*[1:07pm] barth13: then again fn/ln could be mapped against that
*[1:07pm] MrTopf: and for mapping it to social networks it also makes it easier
*[1:07pm] barth13: but anywho the simpler the better
*[1:08pm] MrTopf: you could even use this name as email address then if the AD provides something like that
*[1:08pm] suzyq: well, if an agentd wants to use UUIDs@foobar.com, they can... but they wont be very popular
*[1:08pm] MrTopf: it might also be used as Jabber name
*[1:08pm] MrTopf: yep, this can be kept open as long as they use unique names
*[1:08pm] barth13: if there wasnt such a thing as OAuth I would vote for having a list of accouts in your user properties.
*[1:08pm] Saijanai: are all characters allowed for names in SL?
*[1:08pm] MrTopf: probably it's not unicode
*[1:08pm] MrTopf: but who knows, maybe it is
*[1:08pm] barth13: only not-evil characters
*[1:08pm] barth13: sry
*[1:09pm] MrTopf: as there are Japanese people.. but I am not sure if they can use their characters
*[1:09pm] Saijanai: I haven't seen anyone with a non-ASCII name, even from the Japanese portals
*[1:09pm] MrTopf: then I guess not
*[1:09pm] MrTopf: it also would make it hard to put somebody like this on a list where you have to type the name
*[1:09pm] MrTopf: or in chat
*[1:09pm] MrTopf: at least for me
*[1:10pm] Saijanai: though, for non-latin countries, limiting the names toASCII would be rather bigotted
*[1:10pm] MrTopf: barth13: I think each profile should have a list of accounts the user wants to let other people know about. maybe with a per user setting.
*[1:10pm] MrTopf: but more the service URL endpoints not the accounts
*[1:10pm] MrTopf: I still need to think about how OAuth actually can be used here
*[1:10pm] barth13: k? cool! i thought this could be taken care of by some social netword.
*[1:11pm] MrTopf: well, I think we should use the same requirements email addresses use
*[1:11pm] barth13: yes, agreed
*[1:11pm] Saijanai: aren't those changing?
*[1:11pm] Saijanai: I know domains can (or will) use non-ASCII
*[1:11pm] MrTopf: no idea, I haven't followed that
*[1:11pm] MrTopf: yes, domains can be use at least umlauts
*[1:12pm] MrTopf: so I would follow the internet standards here, however they change
*[1:12pm] Saijanai: was thinking more like unicode
*[1:12pm] MrTopf: makes it easy in the protocol spec, just reference it
*[1:14pm] barth13: this very same discussion in IRC could be identical to a group chat in OGP
*[1:14pm] barth13: that's what I would go for
*[1:15pm] MrTopf: esp. if the IM service would also let me in from a normal IRC client
*[1:15pm] barth13: right
*[1:15pm] barth13: that was my discussion with Dale
*[1:16pm] MrTopf: I think the main problem we have to deal with are the design decisions made early on by LL
*[1:16pm] Saijanai: I guess it dpends on whethr or not we can keep current SL group IM behavior
*[1:16pm] barth13: I was maybe a bit extreme when I said the the viewer could have a built in IRC client.
*[1:16pm] MrTopf: if they would have choosen to use IRC we wouldn't be discussing much now
*[1:16pm] barth13: right
*[1:16pm] barth13: on both accounts
*[1:16pm] Saijanai: but, would people use it the same way
*[1:17pm] barth13: I also asked if it was evil to question the current design
*[1:17pm] MrTopf: what is the group IM behaviour?
*[1:17pm] MrTopf: I am in a group and chat with other people in the group?
*[1:17pm] Saijanai: good questoin. I guess that you get notified when a session first starts after you login...
*[1:17pm] Saijanai: or rather that new messages are sent
*[1:18pm] MrTopf: I guess some client can do all that.. keep the tab closed as long as nothing happens, then open it if some message arrives
*[1:18pm] MrTopf: and if you close it again, maybe simply leave the chat group
*[1:19pm] Saijanai: but, does this mean leave it forever? Part of the issue is that group memebership means you can always receive group notices and are always a member
*[1:19pm] Saijanai: perhaps the underlying assumption can be split in some way
*[1:19pm] Saijanai: mebership = always get notices AND always eligible to join group chat
*[1:19pm] MrTopf: being a member means being listed in some member list?
*[1:20pm] MrTopf: well, being eligible is a whitelist
*[1:20pm] Saijanai: for SL group IM
*[1:20pm] MrTopf: and with notices you mean those announcement thingies?
*[1:20pm] Saijanai: right
*[1:21pm] barth13: always get notices = mailing list, rest = IRC
*[1:21pm] barth13: from an old school point of view
*[1:21pm] MrTopf: I wonder if those two group principles need to go together
*[1:21pm] MrTopf: sometimes I just might want to get notices but no group chat
*[1:21pm] MrTopf: or the other way round
*[1:21pm] barth13: right
*[1:21pm] MrTopf: there can be also some group membership protocol like described on the openid site
*[1:22pm] MrTopf: then both, IRC service and the notification service could use it
*[1:22pm] barth13: but this could be resolved 'under the hood'
*[1:22pm] barth13: with standard web technologies.
*[1:22pm] barth13: no use case of Group IM is unsolvable with what is already there.
*[1:22pm] MrTopf: we maybe should start by listing all things which can be done in a group these days
*[1:22pm] MrTopf: and then regroup it to services which make sense
*[1:22pm] MrTopf: there is too much in an SL group anyway
*[1:23pm] Saijanai: well they are part of the ImprovedInstantMessage
*[1:23pm] Saijanai: https://wiki.secondlife.com/wiki/ImprovedInstantMessage
*[1:23pm] MrTopf: well, that does not mean IIM needs to be part of OGP as long as all the functionality is kept in whatever technology
*[1:24pm] barth13: cool, thx, Sai
*[1:24pm] Saijanai: sure but those are the behaviors that currently exist
*[1:24pm] MrTopf: I guess we agree that this IIM can be really improved or at least simplified
*[1:24pm] Saijanai: ummmm... I sure hope so!
*[1:24pm] MrTopf: just split it into separate protocols instead of putting everything into one
*[1:25pm] Saijanai: there are overlappng issues though, like receiving notifications vs receving messages vs reciving money vs recieving items
*[1:25pm] MrTopf: so regarding OAuth the Service Provider is the AD and the Consumer is the IM Service. The Consumer wants to call some API on the provider side and needs some authorization to do so.. this can be exchanged by an OAuth token
*[1:25pm] Saijanai: or invitations for TP
*[1:26pm] MrTopf: so the user logs into both services and agrees that the IM service is allowed to use the identification service of the AD (for his account)
*[1:26pm] MrTopf: but invitations for TP can be done by a simple webservice
*[1:26pm] MrTopf: and money should be refactored out anyway
*[1:27pm] barth13: right
*[1:27pm] Saijanai: well some groups share revenue
*[1:27pm] barth13: but there is an XEP that XMPP can hadle protected ressources, too: http://www.xmpp.org/extensions/xep-0235.html
*[1:27pm] MrTopf: that are not chat groups then.. as said, I think the whole group concept needs to be partitioned
*[1:27pm] Saijanai: no doubt
*[1:27pm] barth13: yes, I heavily agree
*[1:27pm] MrTopf: for the user it still might look like one group but under the hood I think it should be different web services
*[1:28pm] MrTopf: and we can use this openid group protocol for just the group list
*[1:28pm] MrTopf: and every webservice could check this group registry to do it's stuff
*[1:28pm] Saijanai: might make sense. My proposal is to get group IM working in the AD to give gridnauts a community, and then play with laternate ways of doing it
*[1:28pm] Saijanai: alternate*
*[1:28pm] barth13: Sai: yes
*[1:28pm] MrTopf: I would be happy with a mailing list as an OGP community
*[1:29pm] Saijanai: this is a virtual world system though
*[1:29pm] Saijanai: we might as well use t from teh start that way
*[1:29pm] MrTopf: sure, but IMHO OHs are not that efficient
*[1:29pm] Saijanai: was referring to group chat, actually
*[1:29pm] MrTopf: and chats tend to go in circles or offtopic
*[1:29pm] barth13: again: if we solve the problem to get this discussion plus mailing list plus group chat in one channel ... what other prove would we need?
*[1:29pm] MrTopf: and are hard to read up upon if you missed some or if you are new to the project
*[1:29pm] Saijanai: sure, but this is for sense of community
*[1:30pm] barth13: you can also post an IRC chat log.
*[1:30pm] barth13: like this.
*[1:30pm] MrTopf: yes, but it's hard to read
*[1:30pm] Saijanai: barth13 I don't know. But Ithink that is why we need current gruop IM working. SO people can discuss possible behaviors with the behavior in front of them
*[1:30pm] MrTopf: better would be to post a summary of thoughts
*[1:30pm] MrTopf: or use the mailinglist directly to discuss it (but Rob is against this )
*[1:31pm] barth13: maybe we can make us the test/peer group.
*[1:31pm] barth13: If it works for usm, it might work for others.
*[1:31pm] barth13: -m
*[1:32pm] Saijanai: well, that's the thing. Designing a new group IM behavior willl be very hard (I think).SO in the meantime, I think it easier to get group IM workign as it is. And go from there
*[1:32pm] Saijanai: and from a pyogp perspective, since we eventually want to support all legacy protocols...
*[1:32pm] barth13: its even easier to take IRC and drop from group chat what you dont need.
*[1:32pm] barth13: then we would be already there.
*[1:33pm] Saijanai: well, how to handle inventory, group notifications, etc. Is it easier to use IRC or the current system with an eye to redesigning the current system
*[1:33pm] barth13: inventory??
*[1:33pm] Saijanai: inventory is passed via IIM
*[1:34pm] barth13: =mail
*[1:34pm] barth13: ok, here is the proposal:
*[1:34pm] barth13: we add simple mail, IRC, and XMPP.
*[1:35pm] barth13: and we can map all Group chat behaviour as is under the hood.
*[1:35pm] Saijanai: my counter proposal: get group IM working as is, and then see what issues pop up
*[1:35pm] barth13: how about scaling?
*[1:35pm] barth13: that was the major issue before.
*[1:36pm] Saijanai: well for now, scaling with 100 people in gridnauts isn't an issue. We can test it with pyogp and 10,000 bots if need be
*[1:36pm] barth13: but we dont need to
*[1:36pm] Saijanai: and we can see exactly WHEN and why the scaling issue pops up
*[1:36pm] barth13: if we go with well known technologies.
*[1:37pm] barth13: ist this our job? to re-invent this?
*[1:37pm] barth13: -t
*[1:37pm] barth13: how long will this take?
*[1:37pm] barth13: months?
*[1:37pm] Saijanai: so you're thinking that it will b faster to take a dozen different systems, combine them together without having a workign system in teh same problem space?
*[1:37pm] barth13: who will host the infrastructure?
*[1:37pm] barth13: yes.
*[1:37pm] barth13: Thats what I think.
*[1:38pm] barth13: But that's just me.
*[1:38pm] barth13: Esp. because you can do IRC from a cell phone.
*[1:38pm] Saijanai: s opposed to setting up a chat IM server in Aditi to handle OGP through the AD and enable the current viewers and get gorup IM workign int eh pyogp
*[1:38pm] barth13: I could be sitting in a car having this conversation.
*[1:39pm] barth13: well this is not excluded, Sai.
*[1:39pm] barth13: you can do that still.
*[1:39pm] Saijanai: I have no doubt that setting up SOME kind of group IM would be trivial. I'm talking about a group IM that behaves just like SL group IM
*[1:39pm] barth13: does it have to bahave EXACTLY like now in SL?
*[1:39pm] Saijanai: or we have to understand why it can't
*[1:40pm] barth13: would you sacrrifice months of your man work to it?
*[1:40pm] barth13: if there is a simple solution right at hand?
*[1:40pm] Saijanai: I dont' think its months
*[1:40pm] Saijanai: I think its days to get it half-assed working
*[1:40pm] barth13: It think its week to test
*[1:40pm] barth13: and months to scale
*[1:41pm] barth13: weeks*
*[1:41pm] Saijanai: well, that's my point. A few days or a week or two to get the current SL group IM funneled through the AD to estalbish community and a working example of our target behavior, ten we can start experimenting
*[1:41pm] MrTopf: sorry, I was sidetracked as we have visitors here
*[1:41pm] MrTopf: in general though we can add everything on top
*[1:42pm] barth13: np
*[1:42pm] MrTopf: even if it's not in OGP
*[1:42pm] MrTopf: but I also have to leave now..
*[1:42pm] Saijanai: well, that goes back to the idea of protocols int he OGP as opposed to external
*[1:42pm] MrTopf: cya tomorrow or so
*[1:42pm] barth13: Sai: I absolutely agree on some prototpye
*[1:42pm] barth13: however we do it
*[1:43pm] Saijanai: anything going from client to AD, AD to simulator and simulator to cleint is an OGP issue
*[1:43pm] barth13: sure
*[1:43pm] barth13: mrtopf: cu
*[1:43pm] Saijanai: I also think you don't understand the limitations of the SL viewer GUI
*[1:43pm] Saijanai: later mrtopf
*[1:43pm] barth13: as OGP we dont have to take these limitations into account
*[1:43pm] Saijanai: pyogp can do anything.
*[1:44pm] Saijanai: the SL viewer is strongly limited
*[1:44pm] barth13: the SL viewer is irrelevant for this evolution IMHO
*[1:44pm] barth13: we want to make things better
*[1:45pm] Saijanai: well, until we can get a full framerate 3D viewer into pyogp, its going to be the preferred cliaent for most people
*[1:45pm] barth13: yes, for some time being
*[1:45pm] barth13: I talked to the Lindens in RL last week
*[1:45pm] barth13: they hired an external agency to revamp the viewer.
*[1:45pm] barth13: the viewer is not carved in stone.
*[1:46pm] barth13: think XENKI
*[1:46pm] Saijanai: sure and good to hear
*[1:46pm] Saijanai: xenki?
*[1:46pm] barth13: think AjaxLife
*[1:46pm] Saijanai: well, they have the SLim
*[1:46pm] barth13: http://www.adamfrisby.com/blog/2008/07/introducing-xenki-source-now-availible/
*[1:46pm] Saijanai: is that what you think of
*[1:46pm] barth13: http://www.web3d-blog.de/?p=204
*[1:46pm] barth13: no
*[1:47pm] barth13: I just think of an appropriate next generation SL viewer
*[1:47pm] barth13: I dont know how it looks like
*[1:47pm] Saijanai: xenki is very much windows only, I think
*[1:47pm] barth13: we just have to provide the functionality, the framework to make it cool
*[1:47pm] barth13: doesnt matter
*[1:48pm] Saijanai: well, for testing purposes, seeing how I own a mac...
*[1:48pm] barth13: again - I am not in favour of a specific viewer not even the LL one.
*[1:48pm] barth13: thats my point.
*[1:49pm] Saijanai: anyway, my own belief isthat getting the current group IM working via the AD is almost trivial, even if it doesn't scale. ANd should be the priority. Deciding how to emulate that behavior via existing protocols is a much harder project
*[1:49pm] barth13: we nees to get the protocol right.
*[1:49pm] barth13: I feel different but - of course - I respect that, Sai.
*[1:50pm] Saijanai: welll, I'm speaking with bias. I worked for quite a hile to understand how to get group IM working in the pythong scripts I wrote, and never quite managed to. I missed some trivial peice
*[1:50pm] barth13: we should start with your approach
*[1:50pm] barth13: k, I see
*[1:51pm] Saijanai: well, I never thought it wouldn't be modified dratically or completely chucked.
*[1:52pm] Saijanai: I just suspect it is the eaisest way to get a working model into the OGP, even if everyone knkows its only a temporary solution
*[1:52pm] Saijanai: for example, if we get a multi-Agent domain group IM thing going, how do we have communications between different ADs?
*[1:53pm] Saijanai: Is that proctical? DO we need to create a new system, or can we use the existing system? What happens to scaling at that poitn?
*[1:53pm] barth13: maybe we do both ...?
*[1:54pm] barth13: this is research to some point.
*[1:54pm] Saijanai: sure, eventually, I'mpositive we wil need to drop group IM as it is.
*[1:55pm] barth13: probably.
*[1:55pm] Saijanai: The easiest thing right now would be to create a protocol for the AD to establish one permanent group IM connection with the IM server. Nowthing else would need to be changed I think
*[1:56pm] pogan0 joined the chat room.
*[1:56pm] Saijanai: rather than chaning IM connections each time an agent moves from sim to sim, the client just keeps that one connection
*[1:56pm] pogan0: helo
*[1:56pm] Saijanai: hey pogan0
*[1:56pm] Saijanai: so you can teleport now?
*[1:57pm] pogan0: yes i have new client
*[1:57pm] Saijanai: great
*[1:57pm] pogan0: come to see whats goin on
*[1:57pm] Saijanai: we were talking about group IM for a while
*[1:58pm] Saijanai: how will it change? Can we use things like IRC to get the same behavior as the custom group IM service?
*[1:58pm] barth13: well, you just said: rather than chaning IM connections each time an agent moves from sim to sim, the client just keeps that one connection
*[1:58pm] MrTopf left the chat room. (No route to host)
*[1:58pm] barth13: I fully agree
*[1:58pm] barth13: since this is local chat
*[1:59pm] barth13: for group chat you keep the IRC channel
*[1:59pm] Saijanai: barth13 right, but I think that is the only change (and its probalby quite complicated even so) that needs to be made to get teh current group IM server working with OGP
*[1:59pm] pogan0: yes IM and irc on chanel is good idea
*[1:59pm] Saijanai: pogan0: there are many problems though
*[1:59pm] Saijanai: group IM does many things: https://wiki.secondlife.com/wiki/ImprovedInstantMessage
*[1:59pm] barth13: there is also a diticntion between SIM wide group chat and global group chat
*[2:00pm] barth13: AFAIK nobody has that on the list
*[2:00pm] Saijanai: well, I don't think ther eis sim-wide chat. That is via an entirely different system. The one with channels that scripts can listen to
*[2:00pm] barth13: see my comment here: https://wiki.secondlife.com/wiki/User:Dale_Innis/Group_IM_in_OGP#Group_Definition
*[2:01pm] barth13: there *could* be local (sim wiede) groups. Why not?
*[2:01pm] barth13: sry AD wide groups.
*[2:02pm] barth13: well or RD wide groups. As Zha suggested we should say wide.
*[2:02pm] barth13: lol
*[2:02pm] Saijanai: Sim-wide was what I was objecting to
*[2:02pm] barth13: x d wide groups
*[2:02pm] Saijanai: RD and AD groups are worth pursuing I think
*[2:02pm] barth13: I am sorry, my bad
*[2:02pm] barth13: yes, you are absolutely rihgt
*[2:03pm] Saijanai: The setup that OGP allows, you can have connections established with a region domain BEFORE the avatar is fully rezzed. Its not in the protocol, but the overall design allows it
*[2:04pm] Saijanai: so when you ask the AD to connect to a new region, part of hte connection process coudl be to obtain connections to region-wide group IM
*[2:04pm] barth13: ok
*[2:05pm] barth13: my point was that Group IM is not even a sufficient term as long as nobody says in what domain a group is defined.
*[2:05pm] Saijanai: but I think that the same solution would work for both AD-wide and region-wide group IM
*[2:05pm] Saijanai: for universal IM, something new might be needed
*[2:05pm] barth13: yes, but not for global groups
*[2:05pm] Saijanai: right
*[2:05pm] barth13: right
*[2:05pm] Saijanai: because then you have (maybe) AD to AD communication
*[2:05pm] barth13: and the standard riight now is global
*[2:06pm] Saijanai: well, OUR standard is really region-wide (in SL)
*[2:06pm] barth13: so the group im standard 'as is' is not sufficient by default
*[2:06pm] barth13: is it? no.
*[2:07pm] Saijanai: correct. But, for social reasons, it would be Very Good to have a consistent behavior for all OGP groups
*[2:07pm] Saijanai: SL is the only region
*[2:07pm] barth13: then I wouldnt receive your 'get your ass to the AWGroupies meeting'
*[2:07pm] barth13: (thanks for them!)
*[2:07pm] barth13: lol
*[2:07pm] barth13: yes
*[2:07pm] Saijanai: you are welcomed
*[2:08pm] Saijanai: so I think the easiest thing to do is to mod the IM server to deal wth the AD as the only connection point for group IM and to mod the SL client to never switch group IM connections when it crosses sims
*[2:08pm] barth13: so .. as I stated in Dales Wiki entry, we should first define the domain of groups.
*[2:09pm] Saijanai: I think that should be trivial. If the server never sends group IM messages via the sim CAP, the client will never post group IM
*[2:09pm] Saijanai: so we just make it so the AD EQG cap sends group IM
*[2:10pm] barth13: we dont need 'global' groups then?
*[2:10pm] Saijanai: that's the harder one. BUt we don't have 2 workign ADs yet
*[2:10pm] Saijanai: Tao's AD doesn't handle TP yet
*[2:10pm] barth13: well - we should have them, right?
*[2:11pm] Saijanai: right. Was just looking at the simplest case right now. Getting current group IM working in the AD
*[2:11pm] barth13: global groups are trivial in IRC *ducks
*[2:11pm] Saijanai: that could be the model (at least the connection poitn) for any region-wide group IM system
*[2:11pm] barth13: current group IM is global
*[2:11pm] Saijanai: maybe we go there with IRC and then move it back
*[2:12pm] Saijanai: current group IM is region (only one region)
*[2:12pm] barth13: everyone expects ONE AWGroup
*[2:12pm] barth13: no, Sai
*[2:12pm] Saijanai: well, I see what you are saying, but how it works under the hood, is a region-only group
*[2:12pm] barth13: I want to get your 'get your butt down here' messages everywhere
*[2:12pm] barth13: I dont care
*[2:12pm] barth13: its about user experience, and what makse sense
*[2:12pm] Saijanai: right, I'm talking about first implementation though
*[2:13pm] Saijanai: we get a region-only group IM working (any and all SL groups)
*[2:13pm] barth13: if I miss the meeting because I was in the wrong region?
*[2:13pm] Saijanai: THEN we start working on mutliple AD groups
*[2:13pm] barth13: my point is - we dont need to.
*[2:13pm] barth13: But I understand your point of view now.
*[2:13pm] Saijanai: well if you login through the AD, then oh I see. My bad
*[2:14pm] Saijanai: current group setup is all AD* not region
*[2:14pm] Saijanai: there's no difference realy
*[2:14pm] Saijanai: universe = region = ad... *right now*
*[2:14pm] barth13: true
*[2:14pm] barth13: but in my future universe ...
*[2:14pm] barth13: ... its very different.
*[2:15pm] Saijanai: oh, I agree. We need to split into at least 3 possible divisions
*[2:15pm] Saijanai: but, I'm thinking that getting current group IM workign int he AD will give us a way of discussing how things can be refactored
*[2:15pm] barth13: 3 like ...?
*[2:16pm] Saijanai: universe/RD/AD
*[2:16pm] barth13: ah ok
*[2:16pm] barth13: yes
*[2:16pm] Saijanai: we can get RD and AD working easily right now just by using the AD EQG cap to handle all group IM data
*[2:17pm] Saijanai: later on, we might need to estalbish more logical connection poitns for each type, but for now...
*[2:18pm] barth13: and we can get global AND rd and ad working easily by mapping this onto IRC, mabe through ad.
*[2:18pm] Saijanai: sure, but how do we split up the services?
*[2:18pm] barth13: but maybe we can come from both approaches.
*[2:19pm] Saijanai: abslutelyly. My goal with the current IM is to make it quick and dirty , and to get pyogp useful as a gorup IM client outside OGP
*[2:19pm] barth13: global_group, adname_group, rd_group as channel names
*[2:19pm] Saijanai: if we can get peole using it, we can get more people wanting to participate in workign on it too
*[2:20pm] barth13: the fun thing would be - you could IRC into OGP
*[2:20pm] barth13: I could be in SL and you in your IRC client
*[2:20pm] Saijanai: sure, and various people have bots that allow group IM <> IRC right now
*[2:20pm] barth13: wouldnt make a diifference
*[2:20pm] barth13: really? didnt know that.
*[2:20pm] Saijanai: lots of possibilities
*[2:20pm] barth13: yes
*[2:21pm] barth13: cool
*[2:21pm] Saijanai: talk to Thrxis. I think he has a GPL or freebsd source available
*[2:21pm] Saijanai: Thraxis
*[2:22pm] barth13: k
*[2:23pm] Saijanai: not online right now, but pretty sure he had it working
*[2:23pm] Saijanai: anyway, I must run. Good chatting
*[2:23pm] barth13: well in my vision we dont need it
*[2:24pm] You are now known as Saij_AFK.
*[2:24pm] barth13: yes
*[2:24pm] Saij_AFK: laters
*[2:24pm] barth13: thank you Sai!
*[2:24pm] barth13: laters
*[2:24pm] barth13: bye
*[2:33pm] tess joined the chat room.
*[2:35pm] barth13 left the chat room. ("ChatZilla 0.9.83 *[Firefox 3.0.1/2008070208]")
*[4:54pm] Saij_AFK: hey tess