User:Which Linden/Office Hours/2008 Sep 4

• [11:11] Connected undefined:
• [11:11] Connected undefined:
• [11:11] Saijanai Kuhn: hey which
• [11:11] Which Linden: Hey.
• [11:11] Which Linden: Sorry I'm late
• [11:12] Raz Welles: Hello ^^
• [11:12] Armon Aeon: heya!
• [11:12] Which Linden:  :-)
• [11:12] Which Linden: What's up with your bad selves?
• [11:13] Saijanai Kuhn: finally got my license for WingIDE. SO now I'm an official OpenSource developer ;-)
• [11:13] Which Linden: nice
• [11:13] Armon Aeon: great..
• [11:13] Cenji Neutra: dealing with Mono woes! ;) (Mono runtime exceptions everywhere)
• [11:13] Raz Welles: Neglecting my Blender studies :P
• [11:13] Saijanai Kuhn: should be open to anyone who wants to contribute
• [11:13] Armon Aeon: I finally got my grid up... :)
• [11:13] Which Linden: still clings to emacs
• [11:13] Cenji Neutra: /emacs yay
• [11:14] Raz Welles: I tried to use emacs when I was poking through Lisp :O
• [11:14] Das Wade: Im not usre if i joined the right group
• [11:14] Saijanai Kuhn: shameless plug: you can get free license for Python IDE if you contribute to pyogp (license good for pyogp development only)
• [11:14] Xugu Madison: bah, vi :P
• [11:14] Raz Welles: I need to figure out how to remap the ctrl key to the caps lock xD
• [11:14] Which Linden: Now that's old-school
• [11:14] Cenji Neutra: Do you have an agenda Which?
• [11:14] Raz Welles: I use vi but I'm afraid to develop lisp inside vi :P
• [11:14] Saijanai Kuhn: [1]
• [11:14] Raz Welles: so I put it all down and I'm hiding in 3D modeling for now ^^
• [11:14] Which Linden: I don't have one, shall we decide on a topic?
• [11:15] Which Linden: Suggestions?
• [11:15] Cenji Neutra: Well, I'd like to talk about the Money API I just heard mentioned.
• [11:15] Cenji Neutra: (not for the whole hour)
• [11:16] Which Linden: Where'd you hear it mentioned? My earlier office hours?
• [11:16] Saijanai Kuhn: someone asked what kinds of things you talked about
• [11:16] Which Linden: Oh
• [11:16] Saijanai Kuhn: so I said secure communications like the money API
• [11:16] Raz Welles: haha er, I forgot which area of virtual worlds we discuss at this office hour ^^;;
• [11:17] Tammy Nowotny: money is the root of both evil and good
• [11:17] Das Wade: I joined the group because i was looking for information on the Login and Map Apis and any future ones
• [11:17] Cenji Neutra: Is there any new public API involving transactions on the horizon?
• [11:17] Saijanai Kuhn: ah, that would mostly be Whump's office hours for now
• [11:17] Which Linden: Here are the office hours about what such an API could look like: https://wiki.secondlife.com/wiki/User:Which_Linden/Office_Hours/2008_Jul_24
• [11:17] Saijanai Kuhn: OGP stuff
• [11:18] Cenji Neutra: We're still screen-scraping the SL logs web page every 30secs to get our transaction information.
• [11:18] Which Linden: But no, there are no current plans that I'm aware of to create such an L$ API
• [11:18] Which Linden: Gawd
• [11:18] Saijanai Kuhn: ah, thought Zero and you had both hinted at such. My bad
• [11:18] Armon Aeon: wow..
• [11:18] Conover's Flight-Helper: 6.3.3 (WEAR ME!): Flight-helper is ready and operational.
• [11:18] Which Linden: Actually -- I have a question for you about the transaction logs, Cenji
• [11:18] Cenji Neutra: Reason I ask, is because we're in the design stages for an inter-grid transaction API ourselves.
• [11:19] Tammy Nowotny: we don't even have alog for group transactions
• [11:19] Cenji Neutra: Sure.
• [11:19] Which Linden: What's the id number for each transaction?
• [11:19] Which Linden: Is it a counter, or a uuid?
• [11:19] Raz Welles: OpenLife is working on an economy module iirc
• [11:19] Cenji Neutra: A counter.
• [11:19] Which Linden: Bar
• [11:19] Cenji Neutra: Oh - you mean for the SL transactin IDs, righgt?
• [11:19] Which Linden: Yeah
• [11:20] Cenji Neutra: yep. a counter - hence there is obviousl a central 'next-id' somwhere in your system.
• [11:20] Which Linden: Internally we have a uuid, and I'm not really sure why this counter is being the public face.
• [11:20] Which Linden: I'd prefer to migrate to the uuid, but that would be tricky to transition to
• [11:20] Cenji Neutra: I'm guessing that'll be changed to UUID or some other semi-random numeric ID down the track.
• [11:20] Cenji Neutra: Yes.
• [11:21] Which Linden: I guess what we could do is, at some point, use the uuid for every transaction after a certain date
• [11:21] Cenji Neutra: In our system we're using UUIDs that are numeric only.
• [11:21] Which Linden: Numeric only?
• [11:21] Cenji Neutra: Just digits.
• [11:21] Which Linden: Not hex?
• [11:22] Which Linden: I guess I'm asking why. :-)
• [11:22] Cenji Neutra: Mainly as customers who need to quote is a 'confirmation' id in some cases (in help tickets etc) seem more comfortable with a number than some randomish looking giberish.
• [11:22] Cenji Neutra: It does make that longer or course.
• [11:23] Which Linden: Ok, that's cool
• [11:23] Saijanai Kuhn: oh, and this morning we had a chat about secure IM in an OGP universe: https://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/2008_September_04
• [11:23] Cenji Neutra: (*them) - though they have a time component (basedon high-bits of the unixtime) so we don't run our of space any time soon
• [11:23] Which Linden: One thing that could also be done is to use a substring of the uuid, since those are likely to be unique to the customer yet will be shorter
• [11:24] Cenji Neutra: yes
• [11:24] Which Linden: OK that was a digression
• [11:24] Cenji Neutra: I've considered that for our numeric IDs too (UNIDs a I call them)
• [11:25] Cenji Neutra: Thanks - question answered - no API in the works. Of course, I'd welcome being involved in a joint spec effort instead of doing it outselves and possibly having different LL API arrise in future :)
• [11:26] Which Linden: Who is it that's working on the inter-grid transaction API?
• [11:26] Which Linden: I too would rather have a joint effort
• [11:26] Cenji Neutra: Apez Corp (my company)
• [11:26] Xugu Madison: Inter-grid? Oh good grief rather anyone else than me.
• [11:26] Tammy Nowotny: has an apez server
• [11:26] Cenji Neutra: We have been working with a couple other parties - though not heavily at this stage.
• [11:27] Raz Welles: I was sent money via apez just the other day :P
• [11:27] Raz Welles: *to paypal
• [11:27] Cenji Neutra: The system will segregate 'realms' and only allow inter-grid transactions according to trust relationships setup by the prticipating grids.
• [11:27] Cenji Neutra: We'll only supply the service.
• [11:28] Cenji Neutra: thanks Raz for the business :)
• [11:28] Raz Welles: Hehe ^^ thanks for the service
• [11:28] Cenji Neutra: I'll IM you out-of-band Which - so we can move onto other topics.
• [11:28] Which Linden: OK!
• [11:29] Xugu Madison: Thinking of APIs,any chance of a "Give <inventory> to <avatar>" web service?
• [11:29] Which Linden: That would be rad
• [11:29] Saijanai Kuhn: Cenji are you familiar with this caps-based virtual worlds thesis? [2]
• [11:30] Cenji Neutra: I think I saw that link somewhere - but I didn't read it yet :) We use capabilities heavily (though not URL ones like LL) Thanks.
• [11:30] Saijanai Kuhn: seems to me that some of hte patterns discussed would be of value
• [11:31] Which Linden: For any web service along the lines of "give inventory", we would want a generalized way to ensure idempotency and confirmation in the face of network failures
• [11:32] Cenji Neutra: you mean like we have now (ducks)
• [11:32] Cenji Neutra: (sorry - that's what dealing with tens of "I didn't get xyz" every day does to me :) )
• [11:33] Which Linden: CHTTP was designed for this problem of course, but I think we didn't go far enough with it in that it demands too much of the client and too many resources on the server
• [11:33] Xugu Madison: So... "Create transaction to give inventory" and "Execute transaction" as separate steps. The first fails, nothing happens, and you can do the second repeatedly until it's confirmed
• [11:33] Which Linden: Yes
• [11:33] Which Linden: Exactly
• [11:33] Which Linden: The two-step process is much more appropriate for the sort of client-server relationship you have with the wild wooly grid
• [11:35] Which Linden: Well... I think I talked a bit about that model on the 24th
• [11:35] Cenji Neutra: So - what are you saying about CHTTP? Will it be used in future or be modified?
• [11:35] Which Linden: It will be used internally
• [11:35] Which Linden: And between trusted grids
• [11:35] Which Linden: Or what-have-you
• [11:35] Cenji Neutra: meaning - you're anticipating something else externally?
• [11:36] Cenji Neutra: Ah - so, between servers but not to the client.
• [11:37] Which Linden: Yeah -- I don't think you even want the semantics of CHTTP for the "Give Inventory" service
• [11:37] Which Linden: You want more control over your retries, whereas CTTP requires infinite retries
• [11:37] Which Linden: I guess the CHTTP client could just stop retrying
• [11:38] Saijanai Kuhn: for these kindso f transactions, the pattern in that thesis makes a great deal of sense. you purchase a key good for a specific inventory item, and unlock it and pass it on to an asset server associated with your AD for long-term storage
• [11:38] Tammy Nowotny: mm hmm
• [11:38] Armon Aeon: mmmmmm
• [11:39] Which Linden: nnnn
• [11:39] Which Linden:  :-P
• [11:39] Saijanai Kuhn: perfect harmony, too
• [11:40] Which Linden: What we're talking about is much closer to HTTPLR
• [11:41] Xugu Madison: HTTPLR?
• [11:41] Which Linden: [3]
• [11:41] Armon Aeon: aahhh... thanks
• [11:41] Xugu Madison: adds it to the heap of stuff to read
• [11:42] Which Linden: Yeah, we got some homework to do!
• [11:43] Arawn Spitteler: has a class to teach: Sorry to go so quickly
• [11:43] Which Linden: Overall I think it would be useful to decide how we're going to do this sort of reliable transactional operation with unreliable nontransactional clients, and just lay that down as the pattern for future web services
• [11:43] Tammy Nowotny: cyas Arawn
• [11:44] Which Linden: yeah, teach 'em well arawn
• [11:44] Xugu Madison: I like "Create transaction" and "Execute transaction" steps, but then I would, 'cos I've done it before :)
• [11:46] Cenji Neutra: So, basically, you call execute, and if you get no answer, you do it again (and again) since it doesn't matter if it was already executed
• [11:46] Which Linden: Yes
• [11:46] Which Linden: The only remaining matter is how long our servers will allow you to do that for
• [11:47] Which Linden: It would cost us a small amount to host the data required to make the execute idempotent, so after some point we will delete it
• [11:47] Cenji Neutra: After which what happens? They just return a fail as they don't know anything about the transaction cap you're passing?
• [11:47] Xugu Madison: That's what we do, anyway
• [11:47] Which Linden: Yeah, after that point it becomes as invalid as any random junk you make up
• [11:47] Cenji Neutra: That would just be the transaction UUID I suppose.
• [11:48] Tammy Nowotny: is there much danger of having the UUID for an old dead transaction being reused and creating havoc?
• [11:48] Xugu Madison: statistically highly unlikely if you generate UUIDs correctly
• [11:48] Cenji Neutra: I guess the danger is the same as getting a new UUID for an asets that already exists (hopefully small sue to the large space of UUIDs)
• [11:49] Tammy Nowotny: Thanks, Xugu
• [11:49] Which Linden: Yeah, good explanation
• [11:49] Raz Welles: Take care everyone, nice meeting you all ^^;; I have to run out so have a great day!
• [11:49] Xugu Madison: The big risk is from anyone who messes up UUID generation. Kinda reminds me of the debacle with Debian and RSA key generation, if anyone has the faintest clue what I'm on about
• [11:49] Which Linden: Totally
• [11:50] Armon Aeon: see you...:) Raz
• [11:51] Graph Weymann: I haven't been folowing this, but don't forget to consider whhat happens if a malicious party generates not-very-unique IDs
• [11:51] Graph Weymann: (that is, it should harm only them)
• [11:51] Which Linden: Yes
• [11:51] Which Linden: That's true, what if a malicious party generates urls with transaction ids from their own history, say?
• [11:52] Which Linden: Or from someone else's transaction log?
• [11:52] Cenji Neutra: Presumably the call to execute a transaction includes an authorization token or contect in addition to the bit that identifies the transaction to execute.
• [11:52] Which Linden: That's why we'd generally have a capability involved, which are not forgeable
• [11:53] Armon Aeon: good...
• [11:53] Saijanai Kuhn: that goes back to that secure key thing. a cap is only useful if it is unlocked with the key for the intended party
• [11:53] Which Linden: Unlocked? I don't folow?
• [11:53] Cenji Neutra: You mean like using public key crypto to encrypt cap data?
• [11:53] Saijanai Kuhn: right
• [11:53] Graph Weymann: The reason the capabilities have that property is that the random portio are specific to a server
• [11:54] Cenji Neutra: So only the party who can grant access to the resource actually knows how to decode (and construct) them?
• [11:54] Saijanai Kuhn: if y ou don't even know which server its headed for..
• [11:54] Graph Weymann: Therefore you can rely on that server to have an interest in uniqueness
• [11:55] Which Linden: In essence the capability is a token that tells our servers "yes, we authorized this person to perform this operation"
• [11:55] Cenji Neutra: Which: LL caps don't encode the action and resource in the cap itself, but are just a key to a lookup in a DB table, right?
• [11:55] Saijanai Kuhn: if the url itself is encrypted, you can't attempt to break into the server
• [11:55] Graph Weymann: no, no, it's a token which tells your servers "yes, you authorized *this request*". tere is no necessary client-person-identity involved
• [11:56] Which Linden: Cenji: yes, they are just a lookup key
• [11:56] Xugu Madison: If we're following a "create transaction", "execute transaction" model, would the transaction come back as a cap when created?
• [11:56] Xugu Madison: or am I way off course
• [11:57] Cenji Neutra: Not necessarily, but possibly. As the request might mean something like "give L$X to A from B on behalf of C" for example - and required B's auth to generate.
• [11:57] Which Linden: Xugu: possibly, it would make total sense
• [11:57] Saijanai Kuhn: this goes back to that dicussion this mornign about secure IM being passed through the AD
• [11:58] Saijanai Kuhn: the AD doesn't pass a cap, it passes an encrhpited cap that it doesn't know how to unlock
• [11:58] Saijanai Kuhn: so no man in the middle pssible
• [11:59] Which Linden: Oh so the capability url itself is encrypted so the relaying party can't see even that
• [11:59] Saijanai Kuhn: right
• [12:00] Saijanai Kuhn: for passing stuff that requires a higher security/trust than the AD has
• [12:00] Saijanai Kuhn: requires an out of band key already known by the client
• [12:00] Tammy Nowotny: face
• [12:01] Which Linden: Right
• [12:02] Which Linden: Wow, hilarious, right at the hour mark I get a ton of presence notifications from friends
• [12:02] Which Linden: I guess people are in pretty sharply-defined meetings
• [12:02] Tammy Nowotny: was a server down or did many folk log in at once?
• [12:02] Graph Weymann: btw, you can model "sealed boxes" n an (abstract or real) capability system without reference to encryption
• [12:03] Saijanai Kuhn: not sure how that works. Read that int he tehsis but kinda went past me
• [12:03] Graph Weymann: all I mean to say is, you don't have to think of encrtpyion (of a cap or of whatever) as a separate thing)
• [12:04] Which Linden: I guess I'll have to read the thesis to understand what you mean there
• [12:05] Xugu Madison: Talking of sharply defined meetings, it's now gone 8pm here, I'm giving up for the day, night all!
• [12:05] Which Linden: Yeah, thanks for showing up all
• [12:05] Which Linden: Good discussion, we got some reading to do before next time!
• [12:05] Which Linden: I should GTFO too