User:Which Linden/Office Hours/2008 Jul 3

• [11:01] Which Linden: Yello
• [11:01] Siddhartha Fonda: hi Which, i was just admiring your giant bamboo stalks here, and well now i guess i get to admire your av too lol
• [11:02] Which Linden: Two parts of the same set. :-)
• [11:03] Which Linden: So how has the permissions discussion been going, Sai?
• [11:03] Saijanai Kuhn: hey mostly afk
• [11:03] Which Linden: KK
• [11:05] Which Linden: Hello folks
• [11:05] Morgaine Dinova: Hi Which :-)
• [11:05] TheBlack Box: Hi :)
• [11:06] Which Linden: Nice name, Box
• [11:06] TheBlack Box: ditto ;)
• [11:06] TheBlack Box: Which Topic if i may ask ?
• [11:06] TheBlack Box: AWG again ?
• [11:06] Which Linden: Well, I thought it might be interesting to talk about inter-grid transactions
• [11:07] Morgaine Dinova: No, Which runs his own tech topics
• [11:07] Morgaine Dinova: Using pronouns loosely
• [11:08] Which Linden: My daily work is rarely of interest to this group so I'm game for AWG-style topics usually.
• [11:08] Which Linden: But the topic of how to do transactions across grids -- that is pretty much my game
• [11:08] Olish Yalin: Hello !
• [11:09] Morgaine Dinova: And not just transactions in the financial sense, but more generally, everything that's atomic
• [11:09] Which Linden: Yeah
• [11:09] JB Kraft: hi folks
• [11:09] Which Linden: For example -- if I give an inventory item to you, and you're hosted in a different agent domain -- is that a transaction?
• [11:10] Morgaine Dinova: If it's meant to be atomic (which almost everything at that level will be), then yeap, definitely
• [11:11] Which Linden: Yeah, though that doesn't acutally have to be atomic, it can be merely idempotent, but it is also a very special case.
• [11:11] Which Linden: Most transactions would be of the form "exchange this thing of value for this other thing of value"
• [11:11] Which Linden: BTW, anyone who is not familiar with the terms atomic or idempotent?
• [11:11] Siddhartha Fonda: i know atomic but not idempotent
• [11:12] Lazarus Longstaff: raises a hand wrt idempotent
• [11:12] Freija Yoshikawa: Which: I dont know "Idempotent" but I am aware of Atomic
• [11:12] Latif Khalifa: is it same as "durable" in db world ACID?
• [11:12] Morgaine Dinova: Almost every RL action is a transaction, we've got use to a world where when you've done something, it's got done. :-)
• [11:12] Alaya Kumaki: im not use to both
• [11:13] Nite Zelmanov: idempotent means you can do the same operation multiple times and it will have the same effect as just doing it once
• [11:13] Nite Zelmanov: freedom to repeat
• [11:13] Lazarus Longstaff: ahhhh
• [11:13] Siddhartha Fonda: is that within a given timeframe?
• [11:13] Nite Zelmanov: at least, that's from memory. Generally I should look these things up in case I make a fool of myself ;)
• [11:13] Freija Yoshikawa: so basically, every "action/reaction" is same
• [11:13] Which Linden: Thanks nite, was typing up almost the same thing myself
• [11:14] Tao Takashi: Hi
• [11:14] TheBlack Box: so ... transfering of money and assets from grid to grid ?
• [11:14] Which Linden: But Siddhartha brings up an interesting point -- whether if you repeat the action like a month later if it's OK that it does something different
• [11:14] Tao Takashi: Hi
• [11:14] Which Linden: I think the answer is no, that's not truly iempotent
• [11:14] Nite Zelmanov: "Give L$20 to Freija" is probably not idempotent. It could result in lots more than L$20 xfered if repeated. "Give L$20 to Feija stamped #3879122" can be repeated again and again and Freija only gets L$20
• [11:14] Tao Takashi: oh, I said that already :)
• [11:14] Freija Yoshikawa: Which: I would think a consistency would be beneficial...
• [11:15] Lazarus Longstaff: one would think a TTL on idempotent actions might be of necessity
• [11:15] Tao Takashi: too many chats
• [11:15] Morgaine Dinova: RL actions aren't generally idempotent, but generally are atomic.
• [11:15] Which Linden: But OK, we don't have to concern ourselves with those details about the meaning of the word
• [11:16] Which Linden: TAnd as for atomic, that basically just means that something happens all at once or not at all
• [11:16] Morgaine Dinova: Yep
• [11:16] Which Linden: The most basica atomic action is flipping a bit from 1 to 0 -- it's never at 0.5 or -1 in between
• [11:16] Siddhartha Fonda: well given that transaction involves a bi-directional transfer, presumably the term for one-way is something different, but i may be splitting hairs
• [11:17] Morgaine Dinova: Well, that's actually more like the defn of "atomic transaction" (slightly redundant term). "Atomic" simply means individible, even in this case.
• [11:17] Freija Yoshikawa: Siddharta: what is going where for te operation?
• [11:17] Which Linden: You're right of course Morgaine
• [11:18] Morgaine Dinova: So ... transactions across the interop interface .... tricky. :P
• [11:18] Siddhartha Fonda: i was referring back to which's original question of if someone simply gives an object to another person in another agent domain, is that a "transaction"
• [11:18] Which Linden: Oh, yeah, well, that's a good question.
• [11:18] Which Linden: In a sense you could model that as "You buy this from me for 0 L$"
• [11:19] Which Linden: That *sounds* more transaction-y
• [11:19] Latif Khalifa: so chttp is designed to ensure transaction atomicity on the protocol level?
• [11:19] Morgaine Dinova: I think that's the wrong question, as it becomes a question of words. How about: "What are the properties required of a transfer of objects/assets from one party to another?"
• [11:19] Which Linden: Well let's leave CHTTP aside for now, but no, it only guarantees idempotency
• [11:20] Which Linden: First of all, actually, I'd liketo explore when cross-grid transactions even are necessary
• [11:20] Morgaine Dinova: Use cases
• [11:20] Nite Zelmanov: Yes, Which. Which domains and what for
• [11:21] Which Linden: For example, if you right-click buy this object, and the ownership bit changes but the object stays right here in the simulator....that's kinda not cross-grid
• [11:21] Freija Yoshikawa: Morgane: use cases? I use myself from LLSL to talk with the other me on OSgrid.org ... does the "common region" arbitrate the LLSL <-> OSgrid.org Services Interaction ?
• [11:21] Which Linden: Er, in my example above, assuming the two ownersof the object are in different agent domains
• [11:22] Morgaine Dinova: Use case 1: "when agent A gives agent B in a different grid an item, and if the item is not replicable, then the item must disappear from access by A and appear for access by B". That's a pure atomic transaction.
• [11:22] Siddhartha Fonda: in general i would think yes they would become necessary at some point as grid interoperability evolves, but i'm still fresh on all this stuff lol
• [11:22] Freija Yoshikawa: Siddharta: Im somewhat fresh at it as well
• [11:23] Which Linden: OK, so a couple assumptions -- anything involving an agent's L$ balance or inventory involves the agent domain
• [11:23] Which Linden: ...involves contacting the agent domain's servers
• [11:24] Which Linden: Whereas anything that involves changes in a running region only involves the host region domain, and not necessarily the agent domain of either party.
• [11:25] Which Linden: OK, this "buy this object" example is not such a good one
• [11:25] Latha Serevi: Morgain, use case 1 is a bit on the complex side, especially the "not replicable" part. For instance, we could forbid that altogether, and have the only inter-grid movement be "I move my own object from grid A to grid B", and wouldn't lose all that much. Inter-agent transfers would be in the context of a single grid always in this simplified approach.
• [11:25] Morgaine Dinova: Which: but replicable transfers do not involve an inter-grid transaction, only at the destination. The destination requires a transaction because the item transferred either is, or is not, in its inventory. No such requirement at source.
• [11:26] Freija Yoshikawa: okay... so "objects" are either "inventory" which needs agent domain, or "region" hosting, no agent domain?...
• [11:26] Morgaine Dinova: Latha: it's hardly on the complex side .... it's almost the primary and simplest use case :-)
• [11:27] Latha Serevi: Disagree, M. "Copy without delete" is much less stressful
• [11:27] Which Linden: OK, I might have a cleaner way to think about this
• [11:27] Which Linden: Let's say that each Domain (Agent or Region) controls a set of Resources
• [11:28] Morgaine Dinova: Latha: no, because with "copy but don't delete" you're requiring all the heavyweight machinery of a transaction, and then not using it at the source end.
• [11:28] Which Linden: And there are two operations you can perform on a Resource in one of those Domains
• [11:28] Latha Serevi: (BTW, regarding agent domains, does an agent only belong to one? not clear on the assumptions being used; if as an agent I have objects accepted as "existing" in two distinct grids, what's going on in my agent domain"?)
• [11:28] Which Linden: ok, hold on, let's see if my formulation clears anyting up
• [11:29] Which Linden: Operation 1) Remove
• [11:30] Which Linden: Operation 2) Reserve
• [11:30] Which Linden: And there's a third operation, Create
• [11:31] Which Linden: Each of these operations is idempotent and atomic
• [11:31] Morgaine Dinova: Which: and presumably, your "Reserve" is similar to the escrow operation, ie. the object becomes unavailable to either party, subject to timeout on failure.
• [11:32] Which Linden: Yes, exactly Morgaine
• [11:32] Which Linden: Which I guess means there needs to be an Unreserve
• [11:32] Which Linden: So, three operations
• [11:32] Morgaine Dinova: As part of GC, if nothing else
• [11:32] Lazarus Longstaff: +create
• [11:32] Freija Yoshikawa: Obtain/Release + Create/Delete ?
• [11:32] Which Linden: Sure if you want to say it that way
• [11:32] Freija Yoshikawa: Locking and Existence
• [11:33] Which Linden: Yup
• [11:33] Which Linden: So..... these are operations that can be performed on the domain itself or on something under the domain's control
• [11:34] Morgaine Dinova: Which: not really ... I think they're inter-domain operations.
• [11:34] Freija Yoshikawa: Both AV's that have any object handed from one to the other are going to have a common region always right? regardless of "grid" ?
• [11:34] Tammy Nowotny: what do you do if someone sets up a rogue domain whch doesn't obey the rules?
• [11:35] Which Linden: Morgaine: I mean that one domain can ask the other to do one of these operations
• [11:35] Morgaine Dinova: Aha
• [11:35] Lazarus Longstaff: hopefully we have a sufficiently robust ruleset such that it will identify rogues and specify appropriate response
• [11:35] Which Linden: Tammy: interesting topic to discuss, some other time though
• [11:36] Tammy Nowotny: sorry about that
• [11:36] Which Linden: Let's just see if these rulesets work
• [11:36] Which Linden: So, given these operations and definitions of resources, you could assemble whatever transactions you want
• [11:37] Which Linden: (and yes, for those of you familiar with The Escrow, I'm just rephrasing its operation in the context of inter-domain use)
• [11:38] Which Linden: (Well, not "just", I think I've learned a lot since a6 months ago)
• [11:38] Latha Serevi: Sounds fine, but leaves two big parts to be determined -- how the transactions are handled atomically/idempotently, and what the transaction should accomplish in terms of objects in domains, for a given use case.
• [11:38] Lazarus Longstaff: +1 Which
• [11:39] Freija Yoshikawa: Escrow queue on the region hosting with confirmation of transfer to ea
• [11:39] Freija Yoshikawa: each AV from AgentDomain server ?
• [11:39] Morgaine Dinova: The transaction machinery would be built from those primitives. What I think Which is asking is, is that a sufficient set?
• [11:40] Freija Yoshikawa: Morgaine: mixing layers of the cake to me
• [11:40] Latha Serevi: Sufficient but not interesting.
• [11:40] Which Linden: Hm, ok, example time
• [11:40] Morgaine Dinova: Freija: only the bottom layer defined so far
• [11:40] Which Linden: Right, so let's say our transaction of interest involves two Resources: an object specified by a url (no comment on whether the object is in a region or not), and L$ 10 from Agent A
• [11:40] Lazarus Longstaff: is interesting really a requirement?
• [11:41] Which Linden: Hah yeah transaction systems are boooring
• [11:41] Latha Serevi: No, just means we should move on to the next step!
• [11:41] Lazarus Longstaff:  ;)
• [11:41] Which Linden: We'll get there
• [11:41] Tammy Nowotny: (wait till we have multiple currencies)
• [11:41] Tammy Nowotny: (but that is for another meeting, no doubt)
• [11:41] Morgaine Dinova: Hehe. The boring foundation has to be laid first :-)
• [11:42] Morgaine Dinova: Tammy: we're not talking about financial transactions, specifically
• [11:42] Which Linden: So you want to run that transaction as a Reserve on both the object and the L$, a Delete of both, and then a Create of each on the destination
• [11:42] Freija Yoshikawa: Tammy: Virtual Worlds Exchange market ? ... LLSL$ / OSgrid.org $ / USD / Yen / .... other ? :)
• [11:43] Tammy Nowotny: exacrly, Frieda
• [11:43] Freija Yoshikawa: Which I would escrow at target creation and then do the delete
• [11:43] Morgaine Dinova: Which: not in that order, no. The item in escrow is a template for its creation in the remote domain, after all.
• [11:44] Which Linden: I guess it doesn't matter if you assume the Escrow can maintain the entire Resource's description withint itself
• [11:44] Which Linden: But yeah
• [11:44] Which Linden: Sure, you Create before you Delete
• [11:44] Which Linden: After all, the Resource is Reserved
• [11:45] Which Linden: So.... we're positing the existence of an entity that can be trusted to carry out these operations in sequence without forgetting any of them or doing them misordered
• [11:45] Which Linden: That entity being The Escrow
• [11:46] Freija Yoshikawa: Which: the other option is to code it in as trigger/response-next-trigger/response2 chaining
• [11:46] Which Linden: Freija: yes, this would be transmitting a closure of the transaction to all participants.
• [11:47] Morgaine Dinova: Which: there's an interesting area of difficulty just there: escrow code on A has access rights to query for asset info in A, but the equivalent code in B doesn't have the rights to query A's repository for creating, by default.
• [11:47] Freija Yoshikawa: Which: I just remember how that works for CPU<->Bridge/PCI or CPU<->Z3 interops...
• [11:48] Which Linden: Are we reasy to posit that this four-operation system, plus some means of executing them in proper sequence, solves the use cases we care about?
• [11:48] Morgaine Dinova: No :-)
• [11:48] Which Linden: Hah
• [11:49] Morgaine Dinova: It's got to be implementable in a reasonable way first ... that's why I raised that small difficulty
• [11:49] Which Linden: Ah but you were assuming something about the setup
• [11:49] Morgaine Dinova: By d=what means does B get access to the info it requires for instantiating an item coming from A?
• [11:49] Morgaine Dinova: s/d=//
• [11:49] Which Linden: The whole thing could work if B doesn't have to Create on A
• [11:50] Saijanai Kuhn: BTW, with login setup the way it is, you can have grop IM and inventory management not associated with any region
• [11:50] Latha Serevi: I'm happy to say yes and move on. I'm more interested in defining what "having" an object in grid A means.
• [11:50] Morgaine Dinova: No, just B creating on B ... but needing the info from A to do so.
• [11:50] Which Linden: If, for example, some third party that has full permissions on both grids, can do all the operations
• [11:50] Which Linden: Right so the third party tells B what the info is
• [11:50] Morgaine Dinova: Uh oh ... party C ?
• [11:50] Freija Yoshikawa: Which: new use case...
• [11:52] Which Linden: Yeah, positing the existence of a full-perms party C sucks
• [11:52] Saijanai Kuhn: But probably essential in the case of non-grid transactions
• [11:52] Which Linden: No, wait it doesn't suck
• [11:52] Which Linden: Yeah
• [11:52] Freija Yoshikawa: AV "1" from Grid A and "2" from Grid B are on "Grid C" and are both "visitor" pathing of AgentDomain includes or Excludes the hosting grid services ?
• [11:53] Which Linden: I don't know what you just said
• [11:53] Latha Serevi: nor I
• [11:53] Which Linden:  :-)
• [11:53] Freija Yoshikawa: sorry...
• [11:53] Freija Yoshikawa: I'll rephrase
• [11:53] Saijanai Kuhn: Frija Agent Domain hosts avatar at all times
• [11:53] Which Linden: Patrty C is not necessarily a Grid
• [11:53] Latha Serevi: is still wishing for a defn of what resources might be involved in "having" an object on a grid
• [11:53] Lazarus Longstaff: in fact, it is not of a necesity
• [11:53] Morgaine Dinova: I think I understood that: it comes down to the reverse access that I was talking about in my objection
• [11:54] Latif Khalifa: Latha, wondering about that myself
• [11:54] Freija Yoshikawa: If I visit "Deepgrid" using my AV from OSgrid.org and meet someone from LLSL also visiting Deepgrid... does the interaction use the local grid systems for what we "hand to each other" or not ?
• [11:55] Freija Yoshikawa: local grid being "deepgrid" in that context
• [11:55] Which Linden: OK, let's check that out
• [11:56] Which Linden: So, what are the Agent Domains (AD) in this context? LL and OSgrid?
• [11:56] Freija Yoshikawa: yes
• [11:56] Which Linden: And the Region Domain (RD) is deepgrid?
• [11:56] Freija Yoshikawa: yes
• [11:56] Morgaine Dinova: The design pattern here has the item being transferred from A to B, but that's not the whole story, because the metadata for the item may exist on C.
• [11:56] Which Linden: Yes, ok, Morgaine, that's a good weakness to point out
• [11:56] Lazarus Longstaff: Morgaine, as I understand it, it *has* to
• [11:56] Morgaine Dinova: So query paths are not necessarily the same as transaction paths.
• [11:57] Freija Yoshikawa: Morgaine: also breaks atomicity of transactions adding indirection
• [11:57] Freija Yoshikawa: my thought would be for the region to inform both "origination" AD's for the AV's and link direct
• [11:57] Morgaine Dinova: Freija: transaction don't transfer metadata, only data
• [11:57] Which Linden: Well you could get around it by just saying that, if you want to access object O that's owned by avatar A, then you contact A's AD, even if object O happens to be sitting on the ground in Region G
• [11:58] Which Linden: Then it becomes AD A's problem
• [11:58] Freija Yoshikawa: Which: simplifies it back to "AD"<->"AD" interlock
• [11:59] Which Linden: That's actually pretty clean, since then AD A can authenticate itself to G and verify that it's cool with this Reserve actio
• [11:59] Which Linden: (or whatever action)
• [11:59] Morgaine Dinova: Yep. The pattern of metadata query paths is determined by the metadata location, and not by the transaction paths.
• [11:59] Latha Serevi: I like the possibility of having all objects be based in their owner's AD, and be "guesting" in the RD when rezzed somehow. does this break any fondly held assumptions about what happens to no-copy objects when they're rezzed? I hope not.
• [11:59] Latif Khalifa: Morgaine, by metadata you mean "assets" as used in current sl architecture?
• [11:59] Morgaine Dinova: Damn metadata could be anywhere
• [12:00] Which Linden: I'm confused as well, Morgaine
• [12:00] Morgaine Dinova: Latif: I mean the information required for reconstructing the object being transferred in a place that knows nothing about it.
• [12:00] Freija Yoshikawa: I think I have this straight
• [12:00] Which Linden: Also, could you explain what you mean by "query paths"?
• [12:00] Freija Yoshikawa: there seems to be a minimum use case set here
• [12:00] Latha Serevi: Is Morgaine making the distinction between the object and, say, the inventory listing, or a list of currently-rezzed-objects in a region?
• [12:01] Morgaine Dinova: Which: query paths are the links along which information about the object are obtained.
• [12:01] Morgaine Dinova: Which are not necessarily the same thing as the A->B transaction path
• [12:01] Which Linden: Ah; so in that case the query path for object O is AD A/RD G/egion G
• [12:02] Freija Yoshikawa: in effect there is ever going to be 2 ends for any path I see
• [12:02] Morgaine Dinova: Um
• [12:03] Freija Yoshikawa: AgentDomain / RegionDomain or AgentDomain/AgentDomain
• [12:03] Morgaine Dinova: Freija: each of those represents a class of domain, not a single instance
• [12:03] Which Linden: Just gonna throw this out there: one Resource could be "the owner field of this object".
• [12:03] Freija Yoshikawa: Morgaine: Im aware of that
• [12:04] Which Linden: OK, I think I'm getting beat -- shall we continue next time?
• [12:05] Lazarus Longstaff: :D
• [12:05] Lazarus Longstaff: Thanks for having us Which
• [12:05] Tammy Nowotny: very interesting discussion. TY Which
• [12:05] Lazarus Longstaff: we appreciate you taking the time to share and dicuss your ideas :)
• [12:05] Freija Yoshikawa: Which: Domo Arigatou Gozaimasu
• [12:05] Lazarus Longstaff: waves
• [12:06] Saijanai Kuhn: so here's an interesting thing. If you're in a non-trusted region, and giev Item A to another avie, the avie's Agent Domain has to be "trusted" as well. Because otherwise that Agent DOmain could spoof a request from a trusted region
• [12:06] Which Linden: Well thanks for the discussion, this is helping clarify things
• [12:06] Morgaine Dinova: Maybe we could factor the issue out, by making the transaction service have no interest in the details, and only transfer UUIDs --- it's the remote party's job to make a UUID into something more substantial
• [12:06] Which Linden: Hah I knew there some mega-long chat lines you all were working on
• [12:06] Which Linden:  :-)
• [12:06] Morgaine Dinova: You bring it out in us Which :-)
• [12:07] Which Linden: Ha ha ha
• [12:07] Which Linden: Truly a joy as always, thanks again
• [12:07] Freija Yoshikawa: Which: the only thing I had in mind before coming here was for Zero's office hours about groups...
• [12:07] Which Linden: And, btw, there's no rush to come to a resolution on these matters
• [12:07] Saijanai Kuhn: thanks which. You putting the transcript up or shall I/
• [12:07] Which Linden: I shall do it!
• [12:07] Morgaine Dinova: Thanks Which, love how we can avoid the politics in your OH's :-)