User:Which Linden/Office Hours/2008 Jul 24

• [11:05] Which Linden: Hey there!
• [11:07] Tao Takashi: Hi!
• [11:07] Tao Takashi: looks lonely here today
• [11:08] Which Linden: Yeah, sometimes it's crowded
• [11:08] Which Linden: I think the attendance is dependent on the contentiousness of Zero's office hours
• [11:09] Tao Takashi: well, I know this from my Data Portability office hours :)
• [11:10] Tao Takashi: which I stopped now though because of lack of time
• [11:10] Which Linden: Oh that's cool, I never knew you had office hours
• [11:10] Tao Takashi: well, for the DP group
• [11:10] Tao Takashi: which led to some comments on the public google group of it
• [11:11] Tao Takashi: like "we at the NYC tech scene thought you were serious people but now with that Second Life thing everybody just laughs"
• [11:11] Tao Takashi: or something like that
• [11:11] Which Linden:  :-(
• [11:12] Tao Takashi: but somehow that web scene seems to be some Kindergarten anyway
• [11:12] Which Linden: Ha ha ha
• [11:12] Which Linden: So, hey,what do you think of this topic: a public web API for transferring L$
• [11:13] Which Linden: Interested? Bored?
• [11:13] Tao Takashi: "This has become a running inside-joke among the NYC tech community to immediately dismisses the seriousness of the DataPortability group. "
• [11:14] Tao Takashi: which dismisses the seriousness of the NYC tech community ;-)
• [11:14] Tao Takashi: topic sounds good :)
• [11:14] Squirrel Wood: topic? "How to store nuts properly for winter" ?
• [11:14] Which Linden: Squirrel, you look *bizarre* prior to scult texture download
• [11:14] Squirrel Wood: I know
• [11:15] Which Linden:  :-)
• [11:15] Squirrel Wood: 300+ sculpties :p
• [11:16] Which Linden: OK, so the initial problem we'd like to solve with such a web API is replicating llGiveMoney
• [11:16] Which Linden: replicating the semantics, that is, obv not the actual api
• [11:16] Tao Takashi: [1] ?
• [11:17] Which Linden: Yeah
• [11:17] Tao Takashi: ok, done then. next topic!
• [11:17] Which Linden:  :-)
• [11:17] Which Linden: So, you have to verify that you are you
• [11:17] Which Linden: Let's gloss over authentication and assume it happens somehow
• [11:18] Honza Noyes: hello all
• [11:18] Tao Takashi: might be OAuth
• [11:18] Which Linden: Hi Honza
• [11:18] Which Linden: that's authorization, Tao, subtly different
• [11:18] Tao Takashi: right, you need to authenticate with that service first
• [11:18] Which Linden: Yeah
• [11:18] Tao Takashi: so in principle the idea is that LL is da bank?
• [11:19] Tao Takashi: and you have some API to shuffle money from account A to B?
• [11:19] Which Linden: Yup
• [11:19] Tao Takashi: and of course upload and download money via paypal etc.
• [11:19] Which Linden: Where A is an account you own
• [11:19] Which Linden: Ah... other payment systems are a different problem
• [11:19] Latha Serevi: Like many new arrivals, I popped in due to Sai's mention on Groupies. If there are any URL's of background info, please re-say them. Otherwise I'll sit tight & listen re L$ interfaces.
• [11:20] Which Linden: Now, you'll want to be able to check whether your transaction completed or not
• [11:20] Honza Noyes: I am sorry I am needed somwhere else. nice to meet you
• [11:20] Tao Takashi: well, you need to put money on your account somehow but I guess this will be some web page as it is now
• [11:20] Which Linden: Latha, we just started, there's no background
• [11:21] Which Linden: I think that it would be best if the transaction was implemented as a two-step process
• [11:21] Which Linden: And I'll explain why once I list the steps
• [11:21] Zha Ewry: sits back and listens
• [11:21] Which Linden: Step 1) describe the transaction you wish to perform to a web service
• [11:22] Which Linden: let's say this is a POST
• [11:22] Which Linden: and the body of teh POST says "I am agent A and I want to give 2 L$ to Agent B"
• [11:22] Which Linden: The web service returns to you a token that represents this transaction
• [11:22] Which Linden: A continuation, if you will
• [11:23] Which Linden: (It could be a capability url, who knows, haven't gotten that far)
• [11:23] Zha Ewry: Lambdas
• [11:23] Which Linden: At this point the transaction hasn't happened yet
• [11:23] Which Linden: Step 2) is that you invoke this continuation and the return value is the success or failure of the transaction
• [11:24] Which Linden: If it's a capability you just POST to it I guess
• [11:24] Which Linden: The important thing is that step 2 is idempotent
• [11:24] Which Linden: So if you fail to receive a response you can simply retry until you get one
• [11:25] Which Linden: So those are the two steps
• [11:26] Which Linden: Step 1 is useful because it allows LL to have control over any unique values associated with the transaction, preventing abuse by malicious parties
• [11:26] Which Linden: Step 2's idempotency is important because only the client can truly say whether it has gotten the result it needs
• [11:27] Which Linden: Thoughts?
• [11:27] Lillie Yifu: hmmm
• [11:28] Lillie Yifu: kk let me step through thi. Outcomes are
• [11:28] Lillie Yifu: A sees sent, Be sees received. Restul, ok
• [11:29] Lillie Yifu: A sees sent, b sees not received
• [11:29] Lillie Yifu: result, no OK
• [11:29] Lillie Yifu: A does not see sent, B sees received. Result OK
• [11:29] Which Linden: Hmmmm..... my steps were purely from the point of view of A
• [11:29] Lillie Yifu: for B, but not for whoever is holding the linden as the bnak
• [11:29] Lillie Yifu: I think all three have to be happy.
• [11:30] Zha Ewry: Which, Idempotent, as per, c-http? Or a deeper idempotent?
• [11:30] Which Linden: Just naturally idempotent
• [11:30] Which Linden: And atomic
• [11:31] Which Linden: CHTTP is only between trusted entities, which in this scenario the client isdefinitely not
• [11:31] Zha Ewry: No, can't trust clients ;-)
• [11:31] Lillie Yifu: every escort learns that...
• [11:31] Tammy Nowotny: nods
• [11:32] Zha Ewry: So, idempotent, across the existence of the invokable resource
• [11:32] Tammy Nowotny: LOL
• [11:32] Which Linden: Yep. One question that springs to mind is what timeframe we're talkign about
• [11:33] Which Linden: Like, if you get this token and then invoke it a year later, what happens?
• [11:33] Latha Serevi: Seems fine for A (states are "not done", "uncertain", and "done", and A knows to keep trying while "uncertain". I guess Lillie is suggesting that B, and the bank, both need to be able to get out of the "uncertain" state before we're completely satisfied.
• [11:34] Which Linden: Latha: I think the bank knows the state
• [11:34] Lillie Yifu: bank does not know if the clients know
• [11:34] Lillie Yifu: it isn't certain until it can clear the token
• [11:34] Lillie Yifu: and say that this transaction can't be run again.
• [11:35] Which Linden: Oh... yeah you're right
• [11:35] Which Linden: We had to deal with this for CHTTP and our solution was to just declare an upper limit
• [11:36] Which Linden: 15 days or something -- if you're retrying for even 1/10th of that, you should get on the phone
• [11:36] Latha Serevi: Perhaps there can be a clear and useful definition of "done" and "everybody aware of status" as separate goals to be satisfied?
• [11:36] Which Linden: Yes, I think that's a useful distinction to make
• [11:36] Zha Ewry: chuckles at Which
• [11:36] Zha Ewry: Hard for computers to get on the phone, but yes
• [11:37] Which Linden: I guess what I mean is that by then it becomes a bug
• [11:37] Tao Takashi: nowadays with Skype...
• [11:37] Zha Ewry: if (timeoute exceeded ) (post complaint via skype)
• [11:38] Which Linden:  :-)
• [11:38] Which Linden: We could even go so far as to include a hard expiration in step 1
• [11:38] Which Linden: I mean, communicate an expiration date to teh client along with the token
• [11:39] Which Linden: Then it's not implicit, as it is with CHTTP
• [11:39] Zha Ewry: Right, make it explicit "This should complete within, X, or it's expired"
• [11:39] Which Linden: It then becomes the responsibility of the client to make sure that happens
• [11:40] Tammy Nowotny: do you want different timeout times depending on why itdoesn't go thru (e.g., on whether or not the other sever is up or down at the moment)
• [11:40] Which Linden: No, we don't know that in advance, Tammy
• [11:41] Which Linden: We have to specify the timeout in the very beginning
• [11:41] Tammy Nowotny: nods... I think I see. Thanks!
• [11:41] Which Linden: So, what should happen if you try to use a token afterr it has expired?
• [11:42] Which Linden: I guess it must just reject you with an "expired or unknown" message
• [11:42] Which Linden: ("or unknown" because we'll presumably handle expiry by simply deleting it from our databases)
• [11:44] Which Linden: We have two essential ways to implement the token
• [11:44] Which Linden: One way is to store something on our servers, like a capability
• [11:45] Zha Ewry: Unkown, seems more likely, as the token vecomes invalid
• [11:45] Which Linden: Another way is that the token is simply a description of the transaction, encrypted/signed by us so that we can verify its provenance later
• [11:46] Which Linden: In the latter case, all we'd do is stick the expiry in the token itself, and check it upon receipt
• [11:46] Which Linden: In that situation, we'd know whether or not it was expired or just unknown
• [11:46] Which Linden: (unknown would be : fails decryption/signature verification)
• [11:47] Zha Ewry: Is that unkown, or "invalid" which?
• [11:48] Which Linden: Er, yeah, invalid
• [11:48] Which Linden: Same thing, really
• [11:49] Which Linden: So....um.... I guess that didn't inspire much discussion
• [11:50] Latha Serevi: (this is sort of in the "defining success" thread) Lillie, you seemed to have some ideas about how to make sure every participant was on the same page. Does my notion of "bank decides when we're done" and "we have a mechanism of making sure all parties are aware of the done-or-not status" sound like what you were looking for? This sounds like a description of some properties that Which's protocol should satisfy for various test cases, or something like that. And then we could talk about whether "B knows the result" is something we might want to wait around for, or not.
• [11:50] Orion Raymaker: sorry afk
• [11:51] Zha Ewry: You approach byzantine agreeent in those...
• [11:51] Tammy Nowotny: what if tokens have expiry dates, but they are sent out with datyes very far in the future like web cookies often are)?
• [11:52] Which Linden: Like 30 years far in the future?
• [11:52] Zha Ewry: That causes some fun challanges for keeping them live
• [11:52] Tammy Nowotny: yep!
• [11:52] Which Linden: Latha: yeah, whether B knows teh result or not is explicitly sidestepped
• [11:52] Zha Ewry: Hmm.
• [11:53] Which Linden: Do we care if B knows teh result?
• [11:53] Zha Ewry: Which? Can you provide, in the reply to 1, a URL to query, to check the result later? And does that help?
• [11:53] Which Linden: Sure, that can be part of the token
• [11:53] Zha Ewry: I'm not at all sure it helps, just musing out loud
• [11:54] Which Linden: Or... the token itself can be used to determine the result of the query -- why not just use that?
• [11:55] Zha Ewry: wonders if you'll get tripped up in having
• [11:55] Zha Ewry: to keep the token around for queryt, fter the idempotent invocation is complete
• [11:55] Zha Ewry: No, because, the token has to be valid for repeated calls anyway
• [11:55] Which Linden: Yeah
• [11:55] Zha Ewry: to allow retry
• [11:55] Zha Ewry: shakes her head
• [11:55] Zha Ewry: so... yeah, that's fine.
• [11:56] Which Linden: The token always has to exist until the expiration date, regardless of whether it is used or not
• [11:56] Which Linden: So....A could give B the token for a confirmation
• [11:56] Which Linden: Or we could assume some other mechanism (e.g. transaction history) as a way of letting B know
• [11:57] Which Linden: Either way it becomes another two-party agreement between the entity notifying B, and B
• [12:00] Which Linden: I should probably head out -- getting to be that time again
• [12:00] Tao Takashi: Which: see, it got crowded
• [12:00] Tammy Nowotny: TY for having us Which
• [12:00] Which Linden: Thanks for contributing to the discussion!
• [12:00] Tao Takashi: just talk about money and it gets crowded :)
• [12:00] Which Linden: Ha ha
• [12:01] Dahlia Trimble: money? :D
• [12:01] Tammy Nowotny: I had the Loading... money bug the whole time, for whatever that's worth... ironically
• [12:01] Which Linden: I should add the caveat that I'm not working on any public APi like we've discussed, that would be another team's work
• [12:01] Which Linden: Tammy :-(
• [12:01] Tao Takashi: Tammy: That happens when your computer cannot skype Linden Lab ;-)
• [12:01] Which Linden: I'd like to refactor the viewer/simulator path fro L$ because it's so dumb right now
• [12:02] Which Linden: Like I think you get the Loading... forever if it drops one packet
• [12:02] Which Linden: Anyhow, great talking with y'all and I'll see you next week!
• [12:02] Saijanai Kuhn: something you could put into pyogp for testing purposes maybe
• [12:02] Tao Takashi: thanks for hosting, Which!
• [12:02] Tammy Nowotny: muy Skype works great for listening, sounds bad when I speak
• [12:02] Blackie Dagger: bye Which