User:Zero Linden/Office Hours/2008 July 24

[8:22] Harleen Gretzky: Hi Tree
[8:22] Tree Kyomoon: hello!
[8:22] Harleen Gretzky: was beginning to think I missed the memo or something
[8:23] Tree Kyomoon: hey cool mini people on your head
[8:23] Harleen Gretzky: fairies :)
[8:23] Tree Kyomoon: not that theres anything wrong with that
[8:23] Harleen Gretzky: lol
[8:24] Tree Kyomoon: heh heh
[8:25] Tree Kyomoon: well...its a bit tumbleweedy in here
[8:25] Harleen Gretzky: oh?
[8:26] Tree Kyomoon: i mean, usually a few more folks show up by now
[8:26] Tree Kyomoon: mabey we'll have him all to ourselves!
[8:26] Tree Kyomoon: muhahahahah
[8:26] Harleen Gretzky: yeah, that's what I meant by missing the memo
[8:27] Tree Kyomoon: ah right
[8:27] Tree Kyomoon: so do you script much?
[8:28] Tree Kyomoon: these days I mean
[8:28] Harleen Gretzky: When I can, in the midsts of changing jobs in RL, so my SL is going to suffer
[8:29] Tree Kyomoon: do you do programming /IT for a living in RL?
[8:30] Harleen Gretzky: Network Administrator, used to program 10 years ago though
[8:31] Tree Kyomoon: Network admin...could be really busy or really slow I suppose
[8:32] Tree Kyomoon: but it would be similar to programming I guess because youd still get a lot of calls for support and requests from ludites
[8:32] Harleen Gretzky: yes, there are times, but I do a lot of VoIP work also
[8:33] Tree Kyomoon: do you work from home?
[8:33] Harleen Gretzky: yes
[8:33] Tree Kyomoon: me too
[8:33] Tree Kyomoon: saves gas
[8:34] Harleen Gretzky: technically, working now, lol
[8:34] Tree Kyomoon: heh heh yeah...me too actually
[8:34] Xugu Madison: Working from home because they've turned my office into a building site!
[8:34] Tree Kyomoon: I write off all my video game purchases
[8:35] Rex Cronon: hello everyody
[8:35] Tree Kyomoon: expanding Xugu?
[8:35] Harleen Gretzky: Hi Rex
[8:35] Tree Kyomoon: hey rex!
[8:35] Tree Kyomoon: hi saij!
[8:35] Prospero Linden: Yo
[8:35] Rex Cronon: hiii
[8:35] Xugu Madison: Tree, sort of. Another department being built next to us. Medical sciences, in fact. I believe I'll be left with a fantastic view of the morgue wall
[8:35] Tree Kyomoon: prospero! Hows the shakespeare in SL stuff going?
[8:36] Tree Kyomoon: eeek
[8:36] Prospero Linden: Tree : awesome!
[8:36] Prospero Linden: Twelfth night is done.
[8:36] Multi Gadget: v2.0.3b by Timeless Prototype, '/44 info'
[8:36] Prospero Linden: I'm going to direct a one-act modern play in August, and more Twelfth Night is coming (full miniproductions, eventually the full production)
[8:36] Xugu Madison: Prospero, excellent :)
[8:37] Tree Kyomoon: good to hear, im looking forward to seeing that full production a lot. I saw a couple of the short ones and I was really impressed
[8:37] Prospero Linden: Yeah, it's a lot of fun.
[8:37] Prospero Linden: When I moved to Nashville in 2001, I stopped doing theater... this has let me get back involved with it :D
[8:37] Tree Kyomoon: youre in nashville?
[8:37] Prospero Linden: Yeah -- I moved in 2001 because I started a faculty position at Vanderbitl
[8:37] Prospero Linden: Vanderbit
[8:37] Prospero Linden: Vanderbilt
[8:38] Prospero Linden: typing is hard
[8:38] Tree Kyomoon: did you see the gibson sim recently released in SL (I think last week) ?
[8:38] Tao Takashi: Hi Prospero
[8:38] Prospero Linden: I didn't -- I'll have to look for it.
[8:38] Prospero Linden: I think I heard about it :)
[8:38] Tao Takashi: Hi all :)
[8:38] Prospero Linden: Of course, when I hear "Gibson", the first thing I think is "Neuromancer"...
[8:38] Rex Cronon: hi tao
[8:38] Lillie Yifu: soem nice work there
[8:38] Tree Kyomoon: Gibson is getting into SL bigtime...a few islands under construction
[8:38] BigMike Bukowski: sorry i'm late was fixing a house for a renter.
[8:38] Dawn Day: Hello Everyone.
[8:39] Rex Cronon: hi dawn
[8:39] Prospero Linden: is a violinist, and is more familiar with music of centuries < 20 :)
[8:39] Dawn Day: Be gentle this is my first meeting.
[8:39] Prospero Linden: EVERYBODY GRIEF DAWN
[8:39] Dawn Day: Sorry I missed yesterdays.
[8:39] Tree Kyomoon: heh heh
[8:39] Dawn Day: laughs
[8:39] Lillie Yifu: I did some work for ibanez in sl
[8:40] Tree Kyomoon: oh cool...i miss my ibanez roadstar
[8:40] Saijanai Kuhn: FOr newbies, here's a list of recent office hours and related meetings: https://wiki.secondlife.com/wiki/Category:Grid_Interoperability_Chat_Logs
[8:40] Prospero Linden: One could just about spend all of one's time at interop meetings nowadays :)
[8:40] Dawn Day: I read the log for yesterdays meeting.
[8:40] Zero Linden: oy - tell me about it
[8:40] BigMike Bukowski: tell me about it lol
[8:40] Lillie Yifu: you mean everyone doesn't
[8:40] Saijanai Kuhn: yep, and 2 more to add to the schedule starting the 31st
[8:41] Prospero Linden: I don't ... I'm to busy rolling out software with bugs to the grid, and then rolling it back :)
[8:41] Harleen Gretzky: is humbled with Prospero's diversity
[8:41] BigMike Bukowski: well some of us have renters who need us :P
[8:41] Zero Linden: welcome all
[8:41] Zero Linden: wuz up?
[8:41] BigMike Bukowski: Hello fearless leader.
[8:41] Saijanai Kuhn: Good Morning Teacher
[8:41] Tree Kyomoon: wazzup!
[8:41] Zero Linden: welcome to my office hours
[8:41] Rex Cronon: hello zero
[8:41] Lillie Yifu: hihi zero
[8:42] Latif Khalifa: prospero, skip .23 number, its evil ;)
[8:42] Lillie Yifu: I hope we have your undivided attention. Bad things happen when you divide zero.
[8:42] Zero Linden: haven't mentioned in a while: These meetings are public, and the transcript is published to the wiki (thank's Tree!)
[8:42] Prospero Linden: Latif : the thing is, .22 was evil too...
[8:42] Tree Kyomoon: :)
[8:42] Dawn Day: So many familiar names, it is so good to put a face with them.
[8:42] Zero Linden: So - speak in freely, speak openly
[8:42] Prospero Linden: does mutter about Warehouse 23, though....
[8:42] Dawn Day: smiles
[8:42] Zero Linden: Agenda items?
[8:43] Zero Linden: Ideas?
[8:43] Zero Linden: Thoughts?
[8:43] Dawn Day: brb
[8:43] Zero Linden: Coffee Cake recepies?
[8:43] Saijanai Kuhn: what next for OGP?
[8:43] Prospero Linden: Well, if I was watching my mail right, there were a few regions deployed on Aditi yesterday for the OGP stuff.
[8:43] Tao Takashi: docs! :)
[8:43] Zero Linden: The beta is next
[8:43] Zero Linden: and docs
[8:43] Saijanai Kuhn: the beta is login and TP
[8:44] Zero Linden: (you'll find Tess, Infinity and I all heads down next week or so on docs)
[8:44] Tao Takashi: Sai: btw, now it's the case that you can't login to the beta anymore without being in that group, just hit this today
[8:44] Saijanai Kuhn: glances at the list of 500+ protocols that haven't been OGP-ized yet
[8:44] Dawn Day: back.
[8:44] Dawn Day: Sorry.
[8:44] Prospero Linden: winces
[8:44] Tree Kyomoon: mmm docs
[8:44] Tao Takashi: docs would be good to keep going with implementation :)
[8:44] Zero Linden: I think the next candidates for OGP'izing are Avatar appearance, attachments, inventory, IM, profiles
[8:44] Zero Linden: anyone want to express a preference for ordering those?
[8:45] Tao Takashi: I would like IM or inventory so I can do something useful with pyogp already
[8:45] Prospero Linden: How "just protocol" is this, and how much rethink is done?
[8:45] Dawn Day: I have not been able to find the beta grid to log onto.
[8:45] Prospero Linden: 'Cause... with profiles, it might be worth thinking about "social networking" type things and whether more complicated stuff would be good for friends, etc.
[8:45] Saijanai Kuhn: here's the thing. I'm willing to bet that a good portion of SL wants to play tourist, even if they can't take things with them
[8:46] BigMike Bukowski: IM, Inventory, Appearance, Attachments, Profile.. I'd say
[8:46] Zero Linden: For example, take the region dialog.....
[8:46] Dawn Day: I agree with Mike.
[8:46] Zero Linden: why define a message with all those values, and the messages to alter those values.... and the messages to handle owner access to the info vs. visitor access?
[8:46] Tao Takashi: so profile could actually be an opensocial like profile
[8:46] Lillie Yifu: the beta grid is reachable by turning on the grid menu on your log in screen and selecting aditti
[8:47] Dawn Day: Thank you Lillie.
[8:47] Zero Linden: Instead - why not just, when the user chooses World > Region/Estate just ask the region for a URL of a web page for this user
[8:47] Lillie Yifu: ctrl-alt-G PC
[8:47] Zero Linden: the region can supply a static page for most visitors and a form for the owner
[8:47] BigMike Bukowski: I like that zero.
[8:47] Tao Takashi: thanks, Prospero, Lillie
[8:48] Prospero Linden: [1]
[8:48] Prospero Linden: Of course, you need the special client to do the OGP stuff
[8:48] Zha Ewry: Just define a way to get the results into the right spot?
[8:48] Lillie Yifu: cmd-opt-G mac
[8:48] Tao Takashi: but of course many times you also need some more machine readable form of representation
[8:48] Zero Linden: Well, Zha - we don't really - all we need to do is define the OGP resource: region/get_properties_page
[8:48] Zero Linden: which should return a URL that in tern is a web page
[8:49] Dawn Day: Welcome Being.
[8:49] Xugu Madison: Is OGPing inventory desirable? I mean, you get into a massive mess with licensing, that way, don't you?
[8:49] Dawn Day: smiles
[8:49] Zha Ewry: Hmmm.
[8:49] Zero Linden: if it is a form for the owner
[8:49] Zero Linden: any user changes back to the region
[8:49] Zha Ewry: If we give them a clean path, sure
[8:49] Zero Linden: the only hitch in this plan
[8:49] Zero Linden: are things like the texture picture
[8:50] Zero Linden: *picker
[8:50] Zero Linden: where we need to integrate some viewer action with a dialog
[8:50] Tao Takashi: well, the only thing might be that you cannot use a regular browser component in your client if caps are used
[8:50] Lillie Yifu: casts another vote for peer to peer serving of textures
[8:50] Zero Linden: but this can be done via standard javascript perhaps...
[8:50] Zha Ewry: Actuallu, you really don't care where it comes from.. The regoin, or a web server the service provider wants to use for the task
[8:50] Zero Linden: Tao, why?
[8:50] Tao Takashi: where do you post data back to?
[8:51] Tao Takashi: ok, and then I post changes back
[8:51] Zero Linden: that URL could be caps - there is nothing wrong with GET and POST to the same cap
[8:51] Zha Ewry: Nothing at all
[8:51] Tao Takashi: Hm... maybe
[8:51] Zero Linden: or that URL could be, well, it could set cookies, etc....
[8:52] Zero Linden: though I think there wouldn't need to be
[8:52] Tao Takashi: and this is not caps but cookies
[8:52] Zha Ewry: /This is a text meeting, whoever istalking...
[8:52] Tao Takashi: which is what makes it hard for me right now to implement caps in my agentdomain with Plone/Zope
[8:53] Tao Takashi: as I have to disable all builtin security to make it work basically. I had an idea on how to prevent this, though. Need to experiment with it
[8:53] Zero Linden: well- perhaps we should make a cookie or session based caps gateway....
[8:53] Zero Linden: :-)
[8:54] Tao Takashi: well, it would be sufficient eventually if we say that some header needs to be passed as well
[8:54] Dahlia Trimble: Hi :)
[8:55] Tao Takashi: another problem is that if we want use web standards (and I think we should) most of them are not made for using caps.
[8:55] Dawn Day: Hello Dahlia.
[8:55] Rex Cronon: hi
[8:55] Dawn Day: smiles
[8:55] Tao Takashi: so they want URL endpoints
[8:55] Zha Ewry: A cap is a URL endpoint
[8:55] Zero Linden: but, er, a cap is a URL endpoint?
[8:55] Tao Takashi: yes, but you get it from the caps server
[8:55] Zha Ewry: What it isn't is a public, static one
[8:56] Tao Takashi: Zha: Right, but that's what most standards assume. GIve me URL endpoint for service X
[8:56] Saijanai Kuhn: I think that goes away from the point of using CAPs
[8:56] Zero Linden: So - the difference between caps, and say Flickr API, is that rather than the client being able to construct the endpoint names
[8:57] Zero Linden: but understanding the structure of the external URL namespace
[8:57] Tao Takashi: well, in the caps case you start with names like place_avatar and ask for a URL for them
[8:57] Zero Linden: the client has to ask the service (via the inital contact) for the URLs to the services, since those URLs might be specific to their authorization level
[8:58] Tao Takashi: so maybe we do not even need URL endpoints in the service discovery then because the service already should define the available caps
[8:58] Zero Linden: Other than that, the client uses the cap the same way as the constructed URL name
[8:58] Saijanai Kuhn: but the caps might be cmposed on-the-fly for a given avatar
[8:59] Tao Takashi: Saijanai: well, you don't have to care as you just ask for "place_avatar" and get back a whatever constructed URL
[9:00] Zero Linden: On the server side, you have to add the logic to the seed cap (the initial contact URL, or any intermediate one, if you want to layer them), to both construct the
internal URL (like the client was doing in Flickr API), and then run that constructed URL through the cap's granting service
[9:00] Zero Linden: so we've moved the construction of the URL for a service space from the client to the server,
[9:00] Zha Ewry: You can do that last bit, a number of ways
[9:00] Zero Linden: and hidden it from the client - replacing it with a queried at run time structure with well known resource names
[9:01] Tao Takashi: Zero: and this is my problem with Zope/Plone because endpoints are already protected based on logged in user. Now I would somehow need to throw this out to do it via
the grant service
[9:01] Zha Ewry: (You can just tuck away the valid caps and validate them at invocation time)
[9:01] Tao Takashi: btw, aren't the cap server or the seed cap service then SPOFs?
[9:01] Zero Linden: Why not run the Zope/Plone server instance NOT on the public interface at all - and remove all protection
[9:02] Zero Linden: and only let the caps proxy interface be public
[9:02] Tao Takashi: Zero: somehow I feel uneasy doing this ;-)
[9:02] Zero Linden: that is essentially what we do at Linden
[9:02] Tao Takashi: a little configuration mistake and it might be public
[9:02] Zero Linden: These servers are not on the public interface
[9:02] Tao Takashi: except you also have a firewall of course
[9:02] Zero Linden: well - then
[9:02] Zero Linden: create a user for the caps proxy
[9:02] Zero Linden: and only offer those services to the caps proxy!
[9:03] Zero Linden: let your caps proxy keep a cookie!
[9:03] Tao Takashi: the thing is: all the mechanics inside the app server are then useless..
[9:03] Zero Linden: actually
[9:03] Zero Linden: why not use the normal mechanics
[9:03] Zero Linden: and let the caps proxy store the session cookie for each cap as well as the internal URL?
[9:04] Tao Takashi: that all sounds quite complicated ;-) I will think about this a bit more
[9:04] Tao Takashi: one idea was to add the auth information to the URL
[9:04] Tao Takashi: like /somepath/resource?auth=cdhjcsjshscjhbscjhcsb
[9:04] Zha Ewry: One thing, which is tricky, Zero, is a *lot* of the current http serving frameworks, don't make it terribly easy to get at all the stuff you might want without gettign
pretty entangled in thier guts. You
[9:04] Zero Linden: well yes - that is the normal way of caps - the private URL contains all the identifying information - and it is trust worthy
[9:04] Tao Takashi: my experiment is somehow like trying to convert an existing web app to being an agent domain
[9:05] Tao Takashi: well, this would be my public URL then
[9:05] Tao Takashi: basically moving the header into the url
[9:05] Saijanai Kuhn: I cold see how that would be a pain. POST has a specific use which we are overloading with the CAP structure
[9:05] Tao Takashi: right, POST would be a problem here..
[9:05] Zha Ewry: Not really, Saij
[9:05] Zero Linden: Tao - actually PHP has direct support for that application style
[9:05] Zha Ewry: Post is often abused in similar ways
[9:06] Zero Linden: POST? why? you can POST or GET to a cap...
[9:06] Tao Takashi: I could use /++auth++/dccdbsjchbscjhsbjsbh/somepath/resource
[9:06] Zero Linden: what we do is things like:
[9:06] Tao Takashi: but having query parameters as part of the URL for a post?
[9:06] Zero Linden: /agent/123456-xxxx-yyyy..../somepath/resource
[9:06] Tao Takashi: I can use the thing above and add a traversal adapter to Zope which does handling of the auth info like that
[9:06] Zha Ewry: I think the problem *may* be that some frameworks, are not terribly open to letting you into the path/header processing steps
[9:06] Zero Linden: all our HTTP server frameworks
[9:07] Zero Linden: can be told to extract that ID and pass it in a context map to the final function handler
[9:07] Tao Takashi: the main problem is that using caps is something most frameworks have not envisioned ;-)
[9:07] Goldie Katsu: sighs at her lagging computer and overlapping meetings
[9:07] Zha Ewry: its pretty straighforward with the current OpenSim http server
[9:07] Tao Takashi: another problem with Zope might be handling of passwords
[9:07] Lillie Yifu: we may have hammer nail priority inversion then Tao
[9:07] Zha Ewry: But.. it does require looking into paths, early in the procesing
[9:07] Saijanai Kuhn: Zha, that's what I meant to say. POST wasn't part of the issue,
[9:07] Tao Takashi: we only store them encrypted and they are not $1$+md5 I think
[9:08] Tao Takashi: so no idea yet how to match existing passwords
[9:08] Tao Takashi: probably that's not really possible
[9:08] Zha Ewry: if your tool doesn't want to expose some of that, it's going to break on lots and lots of common, but not dead mainstream use cases
[9:08] Tao Takashi: except by setting up a new system with some auth plugin which uses this scheme
[9:08] Saijanai Kuhn: I just went to BASe Http class in Python, and created a handler for CAPs that didn't use path info in the usual way
[9:09] Tao Takashi: Well, I will explore this further soon
[9:09] Tao Takashi: as soon as I have docs on how the login process works now :)
[9:09] Tao Takashi: or some code which implements it
[9:10] Tao Takashi: I guess the interop4 branch does
[9:10] Zero Linden: It is true that the core of any web server app framework is it's URL traversal mechanism
[9:10] Zero Linden: and that is exactly the thing that needs to be more than just file system traversal for caps to be easily implementable
[9:10] Zero Linden: though - even say apache will support
[9:10] Tao Takashi: it's not so much the traversal it's more the hook into the auth system I think
[9:11] Goldie Katsu: I hate to ask a totally stupid qustion, but I've missed how the auth and CAP get tied together.
[9:11] Zero Linden: you can always put the identifing info in the query args of the private url:
[9:11] Zha Ewry: Right, you need to be able to look at the path, and manage the state as you are parsing things. its not really that unsusual
[9:11] Zero Linden: /somepath/someresource?agentid=123456-xxxx-yyyy-....
[9:11] Zero Linden: and I think every system I know of supports access to those things very easily
[9:12] Zero Linden: and really
[9:12] Tao Takashi: sure, that's not the problem
[9:12] Zero Linden: /agent/123456-...../somepath/resource
[9:12] Zero Linden: is no different than
[9:12] Zero Linden: /somepath/resrouce?agent=1234546....
[9:12] Tao Takashi: yep, but I would use some auth info instead of the agent id
[9:12] Zha Ewry: There is, no assumption, Zero, on the shapoe of the path, that a caps granter gives, other than it follow the overall structure?
[9:13] Zero Linden: uhm, there are 2 "no assumptions"
[9:13] Tao Takashi: I wonder if OAuth would work with caps. need to look into it again
[9:13] Zero Linden: the caps granter doesn't care a wit what the shape of the private URLs look like (the two above are both private)
[9:13] Zero Linden: the user of a cap should make (almost) no assumptions about the shape of the cap (public) URL
[9:13] Zha Ewry: nods
[9:14] Zero Linden: (the 'almost' is that the client should be sure it doesn't reference localhost)
[9:14] Zha Ewry: chuckle
[9:14] Zero Linden: Tao - exactly
[9:14] Zero Linden: PHP, for example, has an option where the session id gets added to the URLs rather than as a cookie
[9:15] Zero Linden: Right - so Tao, you could just be sure to append "?auth=xxxxxx" to the end of all your private URLs
[9:15] Zero Linden: and then direct the application machinery to key off that query parameter rather than the cookie
[9:16] Tao Takashi: that's my plan. maybe writing some plugin for the auth system which does that
[9:16] Tao Takashi: and another one which stores passwords in the formats defined in the spec
[9:16] Zha Ewry: The nice thing here, is that, the invoker just has to invoke the cap, without caring why the service shaped the cap the way ti did
[9:16] Goldie Katsu: and if I pass the CAP URL with auth="xxxx" to another user can the access the CAP?
[9:17] Tao Takashi: Well, the same would be true for putting this URL in the service discovery part
[9:17] Zero Linden: Goldie / Zha - remember that the user of the cap never sees the private URL, hence doesn't even KNOW the shape of the cap
[9:17] Zero Linden: and never sees the auth=xxxxxx part
[9:17] Zha Ewry: right
[9:17] Zero Linden: Now, if the you pass the cap URL to another user, then yes, they can access *that* function
[9:17] Zero Linden: since on the server side it maps to something with that auth=xxxxx
[9:18] Zero Linden: what is nice here is that they can't extract the auth=xxxx (since the client doesn't see it)
[9:18] Zero Linden: and so, can't get full access to your account because you leaked a cap to, say, your profile page
[9:18] Tao Takashi: except if you leak the seed cap ;-)
[9:18] Goldie Katsu: But if I have say a cap that allow edit of the land I could pass it off to other people - without the land owner approving.
[9:19] Zero Linden: of course - or leak your password in the first place
[9:19] Tao Takashi: yep
[9:19] Zero Linden: Caps allow a finer grain of delegation of functions ---
[9:19] Zero Linden: password, or cookie based generally require you to give all or nothing
[9:20] Zha Ewry: Its one reason to keep cap grrants short term
[9:20] Tao Takashi: wonders what will happen if this gets bigger and working and the web scene looks at it and wonders what caps are ;-)
[9:20] Goldie Katsu: Could I transfer a no transfer object by passing the cap for it to another user?
[9:20] Tao Takashi: well, what the auth header is normally is here the seed cap, I don't really see that much difference
[9:20] Zero Linden: Goldie - if we designed a cap for the transfer, then yes
[9:21] Tree Kyomoon: for some reason I thought only the auth server could pass caps
[9:21] Zero Linden: well wait
[9:21] Zero Linden: NO
[9:21] Zero Linden: because the server would never give you such a cap
[9:21] Tree Kyomoon: yes, users cant pass caps to each other
[9:21] Zero Linden: one of the points of caps is that it isn't possible for the client to subvert what they were issued for
[9:21] Tree Kyomoon: right?
[9:21] Goldie Katsu: How is that enforced?
[9:21] Zero Linden: because while you can pass the cap, you don't have access to the private URL - you can modify it to mean something else
[9:21] Tao Takashi: can't
[9:22] Lillie Yifu: I thinka better way of saying is that you could not do that unless the server gave out the cap
[9:22] Zha Ewry: the private URL is TLS secured, isn't it?
[9:22] Zero Linden: The private URL stays on the server side and never gets passed to the client
[9:22] Lillie Yifu: not that hte server would never do it, merely that the server would have to do it.
[9:22] Goldie Katsu: If client A says "I need cap get chair x" wont invoking the cap that is returned get chair x?
[9:22] Goldie Katsu: It doesn't get passed to client...
[9:22] Tree Kyomoon: wouldnt the private url require the authentication of the person using it to match the persons id or soemthing?
[9:23] Goldie Katsu: How does the client invoke the cap then? I thought the cap got passed back to the client.
[9:23] Tao Takashi: btw, Zha: is your new patch public already? Would like to have a look (and maybe also get it to run) :)
[9:23] Zero Linden: So - here's a particular example - say you've got to items: BeachBall and ExpensiveHair
[9:23] Zha Ewry: Its almost there. If you'd like a preview, IM me
[9:23] Zero Linden: imagine that BeachBall is full perms and ExpensiveHair is no-transfer
[9:24] Zero Linden: if you ask the server for a cap to transfer the BeachBall to me, the servier will generate a priavte URL of (say)
[9:24] Zero Linden: /inventory/transfer?item=BeachBall&from=GoldieKatsu&to=ZeroLinden
[9:24] Zero Linden: but you see the public URL: /cap/825163516
[9:25] Zero Linden: so you can invoke that cap (by doing a POST to it, say)
[9:25] Zero Linden: and internally, the server gets the longer private URL and does the operation
[9:25] Zero Linden: BUT - you have no way to change the pirvate URL side
[9:25] Zero Linden: you can't change it to:
[9:25] Goldie Katsu: ah I'm thinking of a different use case.
[9:26] Zero Linden: /inventory/transfer?item=ExpensiveHair&from=GoldieKatsu&to=ZeroLidnen
[9:26] Zero Linden: and if you ask the server to give you a cap for that transfer
[9:26] Zero Linden: it'll say "nope, you no get such a cap --- it's non-transfer"
[9:27] Goldie Katsu: Say I say i ask for attach expensive hair /inventory/attach?item=expensive hair and get back /cap/234159948
[9:27] Goldie Katsu: can I give /cap/234159948 to another hacked lcient and have that avatar attach expensive hair
[9:27] Zero Linden: AH
[9:28] Zero Linden: no - you can't because the private side of the cap carries all the context with it --- you can't get a cap to attach an object to the presenter of the cap
[9:28] Lillie Yifu: at which point the server should say
[9:28] Lillie Yifu: "sorry that is the cap for someone else to attach hair."
[9:28] Zero Linden: you can only get a cap to attach an object to the requestor of the cap
[9:28] Goldie Katsu: ah so it would includ from=GoldieKatsu
[9:28] Goldie Katsu: so the full context is there.
[9:29] Zero Linden: Goldie - right - or in this case perhaps on=GolideKatsu
[9:29] Melanie Milland: would that mean someone else can make your hair come atached?
[9:29] Lillie Yifu: one thing this cap system would make possible would be to have objects owned by someone else
[9:29] Zero Linden: If you gave that away - yes
[9:29] Lillie Yifu: but in the inventory or posession of someone else.
[9:29] Lillie Yifu: WHich is nice
[9:29] Zero Linden: one reason that caps are over HTTPS is that you don't want them stollen
[9:30] Zha Ewry: the TLS sessions is important there
[9:30] Zero Linden: So - while giving someone a cap to change my appearance might be odd.....
[9:30] Goldie Katsu: are CAPS defined further in other docs than the OGP doc?
[9:30] Lillie Yifu: Not at all Zero, it would not be uncommon in the least
[9:30] Zero Linden: giving someone a cap to manage a particular parcel I own might be lovely
[9:31] Zero Linden: The OGP caps description is VERY leaglistic
[9:31] Zero Linden: Tao, actually has a good write up of caps
[9:31] Lillie Yifu: simple example, strip club, you give the manager right s to chagne your avies apperance, they give you caps to clothes and skins that only work in the club.
[9:31] Goldie Katsu: I just don't remember the context being complete being specified there.
[9:31] Goldie Katsu: (But I could have missed it and will be re-reading)
[9:31] Zero Linden: and Tess, Infinity, Whump and I have talked about the need for a descriptive text to go along with the spec
[9:32] Tao Takashi: [2]
[9:32] Zero Linden: No, from the spec point of view - all it needs to say is "the private URL needs to contain enough information for the action to be performed"
[9:32] Zha Ewry: Some examples, and possibly a few public endpoints with testable examples woudl be very nice
[9:32] Zero Linden: or some such
[9:32] Zero Linden: I
[9:33] Zero Linden: I'll see if I can turn the BeachBall example into some text
[9:33] Tao Takashi: and here is a description in slides: [3]
[9:33] Zero Linden: sorry to end abruptly
[9:33] Zero Linden: but I must head out....
[9:33] Tao Takashi: not sure it makes sense without me talking about it.. caps are hard to explain, that's what I learned
[9:33] Dawn Day: Ok Zero
[9:33] G2 Proto: no prob great info Zero!
[9:33] Tree Kyomoon: thanks zero I will post thigs
[9:33] Tree Kyomoon: this
[9:33] Zero Linden: thanks all for coming
[9:33] Tao Takashi: thanks, Zero!
[9:33] Goldie Katsu: A comment on the "enough information" to define the security implications would be good.
[9:33] Zero Linden: see ya next week
[9:33] G2 Proto: cya
[9:33] Goldie Katsu: See ya
[9:33] Saijanai Kuhn: laters zero

User:Zero Linden/Office Hours/2008 July 24

Navigation menu

Search