User:Zero Linden/Office Hours/2007 Aug 02

Transcript of Zero Linden's office hours:

[7:35]	Adam Xinpeng:	Hehe
[7:35]	Zha Ewry:	Morning Zero
[7:35]	Zero Linden:	hello
[7:35]	Adam Xinpeng:	Hey Zero
[7:37]	Zero Linden:	Lots of new faces, I see
[7:37]	Zero Linden:	and, is that an OpenSim shirt?
[7:37]	Adam Xinpeng:	Heh
[7:37]	Ming Chen:	maybe
[7:37]	Wright Juran:	opensim came out in force today
[7:37]	Adam Xinpeng:	Hehe
[7:38]	Adam Xinpeng drops a pin
[7:38]	Adam Xinpeng:	Heh.
[7:38]	Tree Kyomoon:	heh
[7:38]	Zero Linden:	Okay -
[7:39]	Zero Linden:	So - did everyone see the topic for next Thursday?
[7:39]	Adam Xinpeng:	I think Wright had some questions about CAPS.
[7:39]	Zero Linden:	Babbage and MONO!
[7:39]	Alpha Zaius:	hows work on the liberation front?
[7:39]	Adam Xinpeng checks
[7:39]	Zha Ewry nods
[7:39]	Zha Ewry:	Mono
[7:39]	Alpha Zaius:	omg omg omg
[7:39]	Zha Ewry:	Mono!
[7:39]	Alpha Zaius:	Im so going to that
[7:39]	Adam Xinpeng:	Awesome, we should bring Tedd along who's our LSO->CIL guy\
[7:39]	Zero Linden:	Warning - I expect sell out, capacity crowd
[7:39]	Adam Xinpeng:	Heh yeah
[7:39]	Rex Cronon:	only the topic, i was thinking will be in usage by then:)
[7:39]	Zero Linden:	This one has been anticipated almost from the start of these office hours
[7:40]	Wright Juran:	yeah, ref Caps , what are the diferences between Caps and message over http, (are they both handled by the seed request )
[7:40]	Zero Linden:	Ah caps....
[7:40]	Zero Linden:	okay - give me a minute, I think I have diagrams
[7:41]	Alpha Zaius:	Shoot. I just spilled caps on my k eyboard
[7:42]	Zero Linden:	okay - uploading images
[7:42]	Alpha Zaius:	I think I hear a cricket somewhere
[7:43]	Zero Linden:	okay - here we go
[7:43]	Zero Linden:	these are a little outdated, but mostly correct
[7:44]	Zero Linden:	So - here's the capability concept as it is used by the viewer
[7:44]	Zero Linden:	this might be rehash for some of you
[7:44]	Zero Linden:	everyone see the slide?
[7:44]	Adam Xinpeng:	Yep
[7:44]	Rex Cronon:	yes
[7:44]	Zero Linden:	So this is what we ant to achieve
[7:44]	Zha Ewry:	wotth the .pys? Yeah.
[7:45]	Adam Xinpeng:	py = Python, which is what LL's backbone system is coded in
[7:45]	Zero Linden:	we want (1) the simulator to give a URL to the viewer for some function (say map layer data)
[7:45]	Zero Linden:	and the viewer to just do a normal HTTP operation on that URL (2) to get the data directly from who ever has it
[7:45]	Zero Linden:	This has several problems
[7:45]	Adam Xinpeng:	Can we seperate out which server responds?
[7:46]	Zero Linden:	So, yes, in the concept case here, what we are trying to effect, the red arrow could point anywhere in the Internet, it is a URL
[7:46]	Zero Linden:	a real, honest URL
[7:46]	Zero Linden:	But the problems with this are two:
[7:47]	Zero Linden:	1) the thing with the data, in this case the data server, has to be public on the internet, which means that
[7:47]	Zero Linden:	2) It has to make an authorization decision on each access
[7:47]	Zero Linden:	which in turn implies a whole host of baddness:
[7:47]	Zero Linden:	1) the communication has to be authenticated
[7:47]	Zero Linden:	2) the data server has to know how to authenticate
[7:47]	PierreJoseph Proudhon:	fucking tortoise
[7:48]	Zero Linden:	3) all the URLs on that server have to be carefully vetted
[7:48]	Adam Xinpeng:	Use SSL and the secure session ID as a encryption seed?
[7:48]	Zero Linden:	since they are on the public interent
[7:48]	Adam Xinpeng:	(since the session ID is a nice shared secret)
[7:48]	Zero Linden:	4) if you want to offer internal services as well, you need a second server, or at least a second port
[7:48]	Zero Linden:	Adam - yes, there are solutions, but these are the base problems
[7:48]	Zero Linden:	So
[7:48]	Adam Xinpeng:	I think you actually left off a 5)
[7:49]	Adam Xinpeng:	5) It's a public server, bad clients are going to mash it into dust.
[7:49]	Ahab Schmo:	Any server is vulnerable to that
[7:49]	Zero Linden:	I'm pretty sure there is a 6,7, 8 too, acutally, essentially, it isn't a good design pattern for this kind of use
[7:49]	Zero Linden:	So
[7:49]	Adam Xinpeng:	Yeah, but putting it behind a firewall and having distributed access does help.
[7:49]	Zero Linden:	this is what we do
[7:49]	Wright Juran:	why was it decided to mix inventory and Asset upload Caps calls, wouldn't it have been better to keep them separate so Asset uploads could have been handled directly by the asset servers
[7:49]	Wright Juran:	, as it is, uploading assets and creating inventory items are mixed together in the Caps requests , NewAgentInventory handles both inventory creation and asset uploading with no nice split between the two
[7:50]	Zero Linden:	When the simulator wants to give the viewer access to some service, first, it asks the caps module to "grant" a capability to the URL
[7:50]	Zero Linden:	in otherwords, it passes the effective, or private, URL to caps.py, which passes back a public URL
[7:50]	Orzga Aabye:	Caps means capabilities?
[7:50]	Zero Linden:	This public URL contains no information about the effective service at all - it looks like
[7:51]	Adam Xinpeng:	Orzga: yes.
[7:51]	Orzga Aabye:	tks
[7:51]	Zero Linden:	http://sim123:12040/caps/eb9b8ed4-3672-4e80-a1c0-cab500601b4f
[7:51]	Zero Linden:	it is just a big random UUID
[7:51]	Zero Linden:	oops, that should have been https://
[7:52]	Zero Linden:	Then the simulator gives THAT to the viewer
[7:52]	Zero Linden:	so, this is the Authorization step - it is done by the sim, which already has validated the connection, and "knows" what that viewer should and shouldn't be able to do
[7:53]	Tree Kyomoon:	so can userdata persist as in a session using this?
[7:53]	Zero Linden:	When the viewer goes to use the URL - it doesn't even realize that it hasn't been handed a direct URL to the service (whcih is quite elegant in my opinion - and makes debugging really easy)
[7:53]	Zha Ewry:	So, this reduces the amount that the sim has/does trust the client?
[7:53]	Zero Linden:	No, there is no real session data
[7:53]	Zero Linden:	but hold that
[7:53]	Zero Linden:	for a sec
[7:53]	Zero Linden:	so here is the use
[7:53]	Zero Linden:	1) the viewer uses the URL
[7:54]	Zero Linden:	2) it really gets handled by proxy.py, which uses the UUID to look up the effective URL from caps.py
[7:54]	Zero Linden:	3) then it proxies the request to that URL, accessing the service
[7:54]	Zero Linden:	Notice that in this case, the service doesn't need to be on the public internet, and odesn't need to do any authorization
[7:55]	Zero Linden:	it just thinks "ho hum, oh you GOT to this URL, then SURE I'll do it for ya...."
[7:55]	Zha Ewry:	tho you introduce an extra place for things to either get re-directed, and... fail, sure. Not that you have much of a choice
[7:55]	Adam Xinpeng:	Hrrm, not quite.
[7:55]	Adam Xinpeng:	We do the same thing, but we skip a step
[7:55]	Adam Xinpeng:	We encode authentication and method call data into the caps.
[7:55]	Zero Linden:	This is sweet because there are 100s of such services -- and it is much safer not to make each one have to do authorization (let alone authentication)
[7:56]	Zero Linden:	So - yes, relating to session data
[7:56]	Rex Cronon:	based on those diagrams it is not possible for a user to have access to his/hers invetory if the user isn't using the viewer
[7:56]	Zero Linden:	it is common for us to have the granting party (the sim), encode arguments into the effective URL - whcih caps.py keeps
[7:56]	Zero Linden:	it is a form of communication from the granter to the service provider
[7:57]	Zero Linden:	and means there is only one point of holding state - the caps store
[7:57]	Adam Xinpeng:	Question: when you open the grid to third party sims - are you sure you want the sim communicating with the grid at all?
[7:58]	Tree Kyomoon:	caps store...akin to a cookie or shared object?
[7:58]	Dogen Coldstream:	How long does it have to hold that state? I mean, how long is the URL good for?
[7:58]	Adam Xinpeng:	Why not simply have things like inventory get routed through the client?
[7:58]	Zero Linden:	so, for example, if the simulator grants a cap. for uploading an image, then the private URL contains info like, what type of upload to expect, which avatar is doing the upload, etc.... becuase that is information you don't want to trust from the viewer
[7:58]	Zero Linden:	Tree - the caps store, which is nothring more than a map between those UUIDs and the private URLs, is like session data
[7:59]	Zero Linden:	only it is very simple,
[7:59]	Orzga Aabye:	is the private URL one-time use?
[7:59]	Zero Linden:	and unlike session data, we don't need some way to give access to it to the services, whcih might very well be on other hosts.
[7:59]	Adam Xinpeng:	It's a per-session use.
[7:59]	Adam Xinpeng:	The moment the av relogs, the caps for that user get reset
[7:59]	Zero Linden:	because the data is all in the private URL
[8:00]	Zero Linden:	Orzga - we have both kinds
[8:00]	Zero Linden:	one-shot capabilities, and per-session capabilities
[8:00]	Adam Xinpeng:	Are the one-shots in the protocol yet?
[8:00]	Orzga Aabye:	so the cap serer talks to the target URL first, to setup the URL ..
[8:00]	Adam Xinpeng:	(I havnt seen any)
[8:01]	Zero Linden:	yes - all the asset upload caps are of the form: There is a cap that is of the form "I'd like to upload a foo...."
[8:01]	Zero Linden:	and then the response contains a cap that says "Here, use this cap to upload a single foo"
[8:01]	Adam Xinpeng:	I think that's the one Wright had a question on earlier
[8:01]	Zero Linden:	the later is one-shot
[8:02]	Zero Linden:	This is a very common design pattern with capabilities
[8:02]	Adam Xinpeng:	Hrrm.
[8:02]	Zero Linden:	you give a capability that is basically access to the authentication service, and then the responses to that cap are one-shot caps that authorize the holder to do the operation once
[8:02]	Adam Xinpeng:	I do kind of have some security concerns with how this works though -- the caps rely on the UUID not being guessed right?
[8:02]	Adam Xinpeng:	There's no extra authentication on the method call?
[8:02]	Zero Linden:	Adam - yes
[8:03]	Zero Linden:	No
[8:03]	Zero Linden:	but the UUIDs are unguessable
[8:03]	Zero Linden:	really
[8:03]	Adam Xinpeng:	Not if you have a timing attack or something similar
[8:03]	Adam Xinpeng:	remember all the problems netscape had with those and it's early SSL implementation?
[8:03]	Zero Linden:	Yes, but we've taken some care here
[8:04]	Orzga Aabye:	the method call _is_ mac'ed somehow to prevent modification thought? right?
[8:04]	Zha Ewry:	Unguessable, in the sense that you can assign a 1 in X chance of them being guessed in the lifetime of the cap, where X is very large?
[8:04]	Adam Xinpeng:	Heh, just strikes me as a bad idea - something that could be intercepted.
[8:04]	Zero Linden:	and remember that we use UUIDs for everything under the sun - so we are generating zillions of them all the time
[8:04]	Adam Xinpeng:	IE: SL is sending these over UDP unencrypted as part of the view connect right?
[8:04]	Rex Cronon:	messages from viewer to sim pass through different node on the internet, if somebody hacks one of the nodes they can find the UUID
[8:04]	Adam Xinpeng:	Just need someone on the same network to grab em.
[8:04]	Zero Linden:	that is why all communication here is HTTPS
[8:04]	Zero Linden:	so that it can't be intercepted
[8:04]	Adam Xinpeng:	Ah right the seed capability.
[8:04]	Adam Xinpeng:	Still. Hrrm.
[8:05]	Zero Linden:	Yes, we are very very careful to only pass caps over encrypted channels, and only use them with HTTPS in the wild
[8:05]	Rex Cronon:	https can be intercepted
[8:05]	Adam Xinpeng:	But not decoded.
[8:05]	Zero Linden:	Rex - references?
[8:05]	Adam Xinpeng:	THe whole session is encrypted - breaking SSL these days is fairly tough.
[8:05]	Zha Ewry:	For one shots, the lifetime of the cap is short, so this sould be pretty easy. For longer lasting ones, you do have to worry about the hacker making multiple attacks
[8:05]	Adam Xinpeng:	Takes about 40 days to decrypt a SSL session using a cluster
[8:05]	Adam Xinpeng:	That's well outside the expiry of these caps.
[8:05]	Zero Linden:	As in trying to guess a UUID?
[8:05]	Zha Ewry:	Rex, do you have refs to people getting at SSL content. Not the stream, but the underlying content
[8:06]	Adam Xinpeng:	And you can always up the bitlength
[8:06]	Jarod Godel hides his quantum computer
[8:06]	Rex Cronon:	no i don't
[8:06]	Zha Ewry grins at Jarod
[8:06]	Adam Xinpeng:	Zha: It does happen on the lower end - 64 bit keys are essentially breakable these days.
[8:06]	Adam Xinpeng:	Let me try find a link on it
[8:06]	Zha Ewry:	Right, but I assume we're talkign well beyond 64 bit
[8:06]	Zero Linden:	Adam - I forget if we've set it at 1024 or 2048.... but we set it high
[8:06]	Jarod Godel:	isn't 256 standard for ssl?
[8:06]	Zha Ewry:	Zero, have you actually picked a bit size.?
[8:06]	Zero Linden:	yeah
[8:06]	Adam Xinpeng:	Jarod: unfortunately not.
[8:07]	Rex Cronon:	but if u use jarods quantum computer, decrypting would be quite easy:)
[8:07]	Adam Xinpeng:	Standard is still somewhere between 64 and 256 - usually 128
[8:07]	Orzga Aabye:	.. but were you talking man-in-middle .. that would be what i though "intercepted' meant.
[8:07]	Zero Linden:	But again, these caps are eiither one-shot or only life-of the login session
[8:07]	Dogen Coldstream:	I'm having trouble picturing a man-in-the-middle attack in this case
[8:07]	Adam Xinpeng:	Hrrm.
[8:07]	Adam Xinpeng:	Zero: this does raise a question though.
[8:08]	Adam Xinpeng:	SSL certificates are expensive - is LL planning to become a recognised CA?
[8:08]	Zha Ewry:	Man in the middle here, implies breaking the SSL session
[8:08]	Adam Xinpeng:	Even at $15/cert for the cheap ones - times a hundred sims that adds up.
[8:08]	Angela Heartsdale:	What is going on here?
[8:08]	Zero Linden:	good point - in fact the caps work required distributing a linden root CA cert with the viewer
[8:08]	Orzga Aabye:	agreed to all, MIM is prob. not part of the attack model here .. (just guessing)
[8:08]	Jarod Godel:	sl could always just self-sign
[8:08]	Zero Linden:	so that we could generate certs for the sims
[8:08]	Rex Cronon:	tecno talk
[8:08]	Zero Linden:	Jarod - can't use self-sign here
[8:08]	Jarod Godel:	they are writing the server and client, so authentication could be done in-house
[8:08]	Adam Xinpeng:	Self sign is worthless
[8:09]	Adam Xinpeng:	Anyone who self signs is fooling themselves.
[8:09]	Jarod Godel fools himself
[8:09]	Adam Xinpeng:	It doesnt stop man in the middle at all - since the man in the middle can impersonate the self signer.
[8:09]	Zero Linden:	becuase then the viewer would have to trust any web site it got to
[8:09]	Orzga Aabye:	(hidinc certs under coffee table)
[8:09]	Zero Linden:	and DNS attack could make sim123.lindenlab.com point elsewhere
[8:09]	Orzga Aabye:	/hiding/
[8:09]	Zero Linden:	So, for all these reasons, we didn't go with a self-signed cert
[8:10]	Zha Ewry:	The DNS attack is what is killer here, in terms of spoofing, and.. eventually, you really do want a trustable cert chain
[8:10]	Adam Xinpeng:	Hehe
[8:10]	Zero Linden:	since we distribtue the viewer, we put our own root cert in it
[8:10]	Adam Xinpeng adds that to his todo - setup a openmetaverse CA.
[8:10]	Adam Xinpeng:	Hrrm.
[8:11]	Adam Xinpeng:	Well - just going back 30 minutes to an earlier question Wright raised
[8:11]	Adam Xinpeng:	Wright pointed out that things like the NewAgentInventory CAPS invoke both the inventory and asset server
[8:11]	Zero Linden:	So, in summary, the main weaknesses in using caps are 1) good UUID generation and 2) life of the capability vis-a-vis cracking time of the SSL session
[8:11]	Adam Xinpeng:	which means we cant put inventory caps going straight to the inventory server - the sim or another proxy has to be involved.
[8:11]	Zero Linden:	but BOTH of these things are controalable (or fixable) at a single point in the code
[8:12]	Adam Xinpeng:	Is it possible to get those kinds of caps broken in half - one for each the inventory and asset parts?
[8:12]	Zero Linden:	this is a much more robust design than putting authentication and authorization checks at every service - which would be in 100s of places on dozens of servers
[8:13]	Zha Ewry:	Zero, I know this is premature.. but have you looked at what happens when you have multiple domains of capabiikty issuers? I'd imagine it should betractable...
[8:13]	Jarod Godel:	I came in late...are you gjys saying that we're basically going to start tunneling communications between server and client through ssl, ala ssh?
[8:13]	Jarod Godel:	*guys
[8:13]	Adam Xinpeng:	Jarod: they already are.
[8:13]	Adam Xinpeng:	That's what CAPS does
[8:13]	Jarod Godel:	oh, ok.
[8:13]	Zero Linden:	Not sure I'm following you - itsn't it already two steps?
[8:14]	Adam Xinpeng:	No
[8:14]	Adam Xinpeng:	It happens in a single cap.
[8:14]	Zero Linden:	Jarod have been since Janurary
[8:14]	Adam Xinpeng:	Which means we cant point those cap URLs directly at the inventory or asset servers.
[8:14]	Adam Xinpeng:	We have to use the sim to speak with inventory/asset directly
[8:14]	Zero Linden:	There is a cap that is for the service "I'd like to upload something new to my inventory" -- point that one at the inventory server
[8:14]	Zero Linden:	and then it response with "okay, here, use this cap to upload the data"
[8:14]	Adam Xinpeng:	It includes the asset data too I believe as a payload -- Wright?
[8:15]	Zero Linden:	No, we don't include the asset data until the second cap
[8:15]	Zero Linden:	because in our system, we are routing that through (gasp) CGIs running off an apache server
[8:15]	Tree Kyomoon doesnt know if this would solve my http request use case but I could run some tests
[8:15]	Wright Juran:	NewAgentInventory is a call that expects url back saying where it can upload the asset data, which is fine, but the response it requires back from the Asset data upload call, is all about what inventory item was created related to the uploaded data (so if that url was on the asset server it would need to contact the inventory server to create the item so it could return the required data
[8:16]	Zero Linden:	Wright - that is easy
[8:16]	Zero Linden:	so, when the first call creates the inventory item, embedd that item id in the private cap to the asset system
[8:16]	Jarod Godel:	I may ask this badly, so I apologize in adavnce... IIRC, when people crack wep keys, they do it by sniffing packets and using those as a means of finding similarities in the packets...the root of all decryption (I believe). Given that evrything in-world is accessible unencrypted, is there any concern that breaking this encryption will be easier because people will know what names and patterns to look for?
[8:16]	Zero Linden:	then the asset system picks that URL arg off, and uses it to respond with
[8:17]	Rup Etchegaray:	habla alguien español por aca?
[8:17]	Jarod Godel:	or am i just completely off base? (may very well be!)
[8:17]	Zero Linden:	Jarod - WEP's use of encryption has several significan flaws that made that kind of attack much much easier
[8:17]	Zha Ewry:	Shouldn't be Jarod.. The caps never really live in world.. Only between the sims and clients... And.. the content is a couple of layers in
[8:17]	Adam Xinpeng:	Jarod: not in this particular case - the CAPS dont tend to contain authentication information or other known data. Each request is unique.
[8:17]	Jarod Godel:	Ah! Ok.
[8:17]	Zero Linden:	SSL has continued to be show to be more robust
[8:17]	Jarod Godel:	thanks
[8:18]	Adam Xinpeng:	Heh, the SL UDP protocol is horrendously insecure at the moment still though.
[8:18]	Dogen Coldstream:	Jarod: I think you are talking about known clear-text attacks. I'm not aware of any against ssl
[8:18]	Neas Bade:	WEP was really fundamentally flawed in design
[8:18]	Adam Xinpeng:	You can still do stuff like abandon peoples land using a few targetted packets on the UDP circuits.
[8:18]	Jarod Godel:	Dogen, cool, cool! I may also be confusung what little I know of MD5 with ssl.
[8:18]	Zero Linden:	Well, let's be honest here, all the communications between viewer and sim are encoded in XML, and using our LLSD schema, so there is plenty of "known text"
[8:18]	Adam Xinpeng:	(although you need to sit on the same network as the user and sniff a secure session ID)
[8:19]	Zero Linden:	but again, SSL is far better designed than WEP was
[8:19]	Zero Linden:	Sorry, Rup, I don't speak Spanish
[8:20]	Rup Etchegaray:	well, thanks anyway
[8:20]	Zero Linden:	Wright - is that clear now how you pass along information from one server to the next
[8:20]	Wright Juran:	Zero, yeah that is a way around it, just seems that it would have been easier to have the inventory item details sent as the reply to the first NewAgentInventory call (along with the url for uploading the data) seems a better split of the tasks
[8:20]	Zero Linden:	No - we didn't want to give the agent a valid inventory ID until we were certain there was a valid asset behind it
[8:20]	Wright Juran:	ahh
[8:20]	Zero Linden:	if the asset up load fails, then the asset uploading service calls back to the inventory service to delete the newly created inventory item
[8:21]	Adam Xinpeng:	Flip the order?
[8:21]	Adam Xinpeng:	Upload to asset server, THEN create inventory?
[8:21]	Zero Linden:	no - we don't want to incur the cost of accepting your 10MB BMP image until we've taken your L$10!
[8:21]	Jarod Godel:	haha
[8:21]	Adam Xinpeng:	Heh yeah but that's clientside too.
[8:22]	Zero Linden:	no, we do the L$ deduction and check as part of the first step
[8:22]	Adam Xinpeng:	Heh you can switch it off at the client./
[8:22]	Adam Xinpeng:	Been a known issue for a couple of months
[8:22]	Zha Ewry giggles MB a linden :-)
[8:22]	Rex Cronon:	but, i think there is already a way to bypass the 10$L fee for uploading
[8:22]	Wright Juran:	don't get them doing that, would be bad for us as it would then be hard coded in the client
[8:22]	Zero Linden:	Hmmm... well, don't know about that bug..... but there is no reason it should be a bug....
[8:22]	Adam Xinpeng:	Heh
[8:23]	Jarod Godel:	Rex, there is???
[8:23]	Zero Linden:	All of this brings up a good deisgn point
[8:23]	Rex Cronon:	ask qarl linden
[8:23]	Jarod Godel:	i will
[8:23]	Adam Xinpeng:	Zero: why not charge for the one-time cap?
[8:23]	Zero Linden:	While caps offers tremendous flexibility in where a service is handled
[8:23]	Adam Xinpeng:	IE: pay L$10, get a cap
[8:24]	Coffee Mug whispers: Ahh! Fresh Hot Coffee
[8:24]	Zero Linden:	It does require some baking of the sequence of events into both client and server ---
[8:24]	Rex Cronon:	adam seems to know about it too
[8:24]	Zero Linden:	-- not that that isn't normal for most protocols
[8:24]	Zero Linden:	but the nature of caps leads one to think of more flexible approaches
[8:24]	Jarod Godel:	more stateless approaches?
[8:24]	Zero Linden:	for example, you can think of caps as a sort of continuation-passing style of programming
[8:25]	Zero Linden:	(stop giving me those funny looks!!!)
[8:25]	Orzga Aabye:	(i'll try.)
[8:25]	Zha Ewry:	A continuation without a fully public stack?
[8:25]	Zero Linden:	And so, one could imagine meta-protocol over caps where once you've started an operation
[8:26]	Zero Linden:	the viewer would be prepared to handle an arbitrary sequence of "okay great, but, now follow THIS cap for the next step"
[8:26]	Zero Linden:	Zha - there are experimental systems where the entire continuation stack is cryptographcially encoded into the URL!
[8:26]	Zha Ewry:	Right, but not here...
[8:27]	Zha Ewry:	And.. If you go to the stream of caps.. you need to be dead careful about idempotency and checking for lost steps.
[8:27]	Zha Ewry:	Doable, but important
[8:27]	Jarod Godel:	This is a stark reminder to of just what huge *lie* web addresses and URI's really are. :)\
[8:28]	Orzga Aabye:	& then caps are not transferable...
[8:28]	Dogen Coldstream:	Ah, for the cimpler days, when a URI actually pointed to a file on a filesystem somewhere
[8:28]	Zha Ewry:	Zero, I'm also wondering, just how you would describe the "Client/Server contract" for a stream of rediectrable caps requests. In terms of ways that capture the idempotnacy.
[8:28]	Zero Linden is not going to touch Jarod's statement with a 10ft pole
[8:29]	Jarod Godel:	If you did you steps of caps that you're suggesting, you'd essentially be dealing with...what...a virtual object system?
[8:29]	Zero Linden:	Zha - we have been very interested in idempotency and HTTP, especially when it comes to POST
[8:29]	Jarod Godel:	Treating http communications as a kind of shared memory space?
[8:29]	Zha Ewry:	Well, it's POST that has to be especially careful, as you get state change on it, or can. And when you do, you need to be extra careful
[8:30]	Zero Linden:	Jarod - if you know my personal background - you'd see that thinking of the web as a giant virtual machine is in my sights...
[8:30]	Zero Linden:	Please see http://wiki.secondlife.com/wiki/Chttp
[8:30]	Zero Linden:	which is our design for dealing with this issue
[8:30]	Adam Xinpeng:	We had a look at that
[8:30]	Adam Xinpeng:	Is that being planned for running CAPS over?
[8:30]	Jarod Godel:	Zero, yeah...I can see that. You're probably going to love what Bug Labs is coming out with (from that I hear).
[8:31]	Zero Linden:	Adam - at present we are developing it for some internal pathways
[8:32]	Zero Linden:	but, in general, any POST over CAPs could make use of this
[8:32]	Zha Ewry:	There are some *interesting* issues with the image of a virtual machine in which most instructions are idempotent.. That one is going to require some thinking before the question even can be possed properly.
[8:32]	Adam Xinpeng:	Hrrm, might be fun to support. Heh.
[8:32]	Jarod Godel:	So...with CAPS, or at least cttp, you're basically embedding AJAX into HTTP, so it automatically fires off a callback upon completion.
[8:32]	Zero Linden:	one of the things I like about CAPS is that it is an orthoganal building block -
[8:32]	Jarod Godel:	like sticking a <script>callBack();</script> at the end of a web page
[8:32]	Tree Kyomoon:	I had a look at that as well...seems like it would solve some of our problems at work but Id be interested to know more about how it works
[8:33]	Zero Linden:	as far as the communication between the user of the cap (the viewer) and the service is concerned, the cap needn't even be there
[8:33]	Wyn Galbraith belatedly goodmornings everyone.
[8:34]	Tree Kyomoon:	is cHTTP good for communications that HAVE to be sequential programmatically?
[8:34]	Zero Linden:	a similar idea to our cHTTP is the POST Once Exactly (or POE)
[8:34]	Adam Xinpeng:	I think it's more orientated towards aysnchronous requests
[8:34]	Zero Linden:	http://www.mnot.net/drafts/draft-nottingham-http-poe-00.txt
[8:34]	Tree Kyomoon:	yeah thats kind of what I was thinking Adam
[8:34]	Adam Xinpeng:	Have lots going at once, confirm reciept/respond as required.
[8:34]	Zha Ewry:	POE has some hard issues in flaky environments
[8:35]	Zha Ewry:	You end up with some fun retry costs
[8:35]	Jarod Godel:	Yeah, I'm kind of wondering how much bandwidth chttp, httpr, etc. is going to eat up.
[8:36]	Zero Linden:	We've recently looked at POE vis-a-vis cHTTP and decided we like our cHTTP approach
[8:36]	Jarod Godel:	at what point do you switch from http* to just an open socket connection?
[8:36]	Zero Linden:	it is somewhat lighter weight in the common cases.
[8:36]	Zha Ewry:	In general, Jarod, the protocls, vs. the content... the protocal is a wash.
[8:36]	Zha Ewry:	Unless you're movbing tiny stuff all the time.. you never notice the protocol
[8:37]	Zero Linden:	well friends, another hour has passed
[8:37]	Zero Linden:	and I'm must flee
[8:37]	Adam Xinpeng:	Heh
[8:37]	Zero Linden:	thanks all for coming
[8:37]	Jarod Godel:	l8r, zero
[8:37]	Zero Linden:	and I'll have it all up in the wiki
[8:37]	Rex Cronon:	bye zero
[8:37]	Wyn Galbraith:	Thanks Zero.
[8:38]	Adam Xinpeng:	Seeya Zero
[8:38]	Zero Linden:	(got all of July up yesterday)
[8:38]	Zha Ewry:	Great session, Zero.
[8:38]	Zero Linden:	till next week!
[8:38]	Orzga Aabye:	thks to all .. this has been cool
[8:38]	Wyn Galbraith:	Always an education ;)
[8:38]	Zha Ewry:	Really good stuff
[8:38]	Saijanai Kuhn:	take care Zero
[8:38]	Zha Ewry:	and some i nteresting things to think about
[8:38]	Dogen Coldstream:	Thank you, Zero