User:Which Linden/Office Hours/2008 Jul 10

From Second Life Wiki
Jump to: navigation, search
  • [11:05] Which Linden: salutations!
  • [11:05] Lor Gynoid: Hi Which
  • [11:05] Oz Larg: Hi Which
  • [11:05] Tegg Bode: Hi
  • [11:06] Oz Larg: No need now for a Which hunt...
  • [11:06] FWord Utorid: i suppose i shouldn't mention that we are having asparagus for dinner
  • [11:06] Which Linden: holds nose
  • [11:06] FWord Utorid: it could be a cousin
  • [11:06] Which Linden: Ha ha ha, so how's everyone doing?
  • [11:06] FWord Utorid: great camoflauge which ;)
  • [11:06] Tegg Bode: Thx JayR
  • [11:06] Oz Larg: Life is good here, U?
  • [11:07] Lor Gynoid: Beware of pandas is probably a comment you've gotten very tired of...
  • [11:07] JayR Cela:  :_)
  • [11:07] Tegg Bode: Where is Which gone, when did he go?
  • [11:07] Which Linden: Seems like the week just flew by
  • [11:07] Lor Gynoid: On his plant stand?
  • [11:08] Which Linden: Whoa, Gynoid is an interesting last name
  • [11:08] FWord Utorid: sai fell asleep at the wheel of the spammobile today
  • [11:08] JayR Cela: lol
  • [11:08] Which Linden: Shall we continue the discussion from last week?
  • [11:08] JayR Cela: Sai is my hero
  • [11:08] Lor Gynoid: I know what it means, unlike a number of people with male avatars with that name. :)
  • [11:08] Aimee Trescothick: lol
  • [11:09] FWord Utorid: i don't remember last week, so let's just do a re-run
  • [11:09] Which Linden: Heh heh yeah
  • [11:09] Which Linden: Oh, wait, what's up with the grouch marx masks?
  • [11:09] Lor Gynoid: was amazed by Macho Gynoid... (made up name)
  • [11:09] Oz Larg: Tegg infected us
  • [11:09] FWord Utorid: it's not significant, we were just bored.
  • [11:09] Tegg Bode: We were just bored
  • [11:09] Which Linden: snapshotted!
  • [11:10] Lor Gynoid: We got groucy. :)
  • [11:10] Lor Gynoid: grouchy*
  • [11:10] Which Linden: OK, well last week didn't get as far as I wanted, I usppose I should have planned for that
  • [11:11] Which Linden: I proposed a set of idempotent operations: Reserve, Unreserve, Create, Delete
  • [11:11] JayR Cela: gave you 2nd annual SL Content Creator & Developers Mo-Town Dance Party.
  • [11:11] Which Linden: That would be used to implement cross-grid transactions
  • [11:13] Which Linden: The idea I was getting at was that in order to implement the mechanics of cross-Domain transactions, a Domain would simply have to implement those operations for a suite of resource types
  • [11:14] Which Linden: I.e. if you wanted to be able to sell objects, you'd write them up for objects
  • [11:14] Which Linden: We've sidestepped two issues thus far, though
  • [11:14] JayR Cela: ok IBM has done it SUN has done it / now I am concearned with protecting the things I have created
  • [11:14] Which Linden: That's one of them : trust
  • [11:14] Lor Gynoid: Naming issues?
  • [11:15] Which Linden: Hmm... naming issues are kind of a generic problem -- I've been assuming those were worked out
  • [11:15] Which Linden: I'd like to contiue to do so -- naming is a huuuuuge potential rathole
  • [11:15] Lor Gynoid: OK
  • [11:15] Which Linden: I'll let Zero deal with that. :-)
  • [11:15] FWord Utorid: lol
  • [11:16] Which Linden: Crap, can't remember teh second
  • [11:16] FWord Utorid: which, could you put into context these idempotent operations? are they something the sim would run. then maybe you will remember
  • [11:17] Which Linden: Oh, yes, the distinction between region Domains and Agent Domains -- and the fact taht an Agent can own something in a RD
  • [11:17] Lor Gynoid: Implied agreements between the resource provider and the resource user?
  • [11:18] JayR Cela: ya know what I give most of my creations for no charge / but I do sell a few of them / what sort of issues are we going to have to deal with here in inter-op VW cross transversing
  • [11:18] JayR Cela: how can we protect our stuff from being stolden
  • [11:18] Lor Gynoid: Can you have both trusted and non-trusted resource providers and resource users?
  • [11:19] Which Linden: FWord: the way I'm envisioning things, is each Domain has a way of having web services get called on it -- in the case of a Region domain these services could be implemented by the sim itself
  • [11:19] JayR Cela: looks to me that LL is stabbing themselves in the foot
  • [11:19] FWord Utorid: ok
  • [11:20] Which Linden: I'm sort of thinking of them as function calls against the Domain itself, even if you're actually only interacting with a singular host within teh Domain
  • [11:20] Which Linden: So: trust
  • [11:21] JayR Cela: ok thats way to complicated
  • [11:21] Which Linden: There's a couple of levels of trust that will be necessary
  • [11:21] Which Linden: Well, desireable
  • [11:21] Which Linden: I think
  • [11:21] Which Linden: throws out caveats like rose petals
  • [11:21] Which Linden: The most basic level is between domains
  • [11:21] Which Linden: and the transaction coordinator
  • [11:22] JayR Cela: keep it simple / when you create something / the creator / devolper / should be shown a list of selections / to authorize her or his permissions
  • [11:22] Which Linden: The coordinator authenticates itself somehow, and the Domain decides to do one of the operations based on whether said domain is on a list of approved partners or whatever
  • [11:22] JayR Cela: to other people
  • [11:23] Which Linden: JayR: we haven't gotten down to the level of residents yet
  • [11:23] Which Linden: We're just talking about the abstract, programmer-level "how do I write a domain" thing
  • [11:23] FWord Utorid: ok. so essentially, http communication as the background for information interchange between these region domains
  • [11:24] FWord Utorid: -region +general
  • [11:24] Which Linden: I've been assuming the semantics of http, but we're not bound to it
  • [11:24] FWord Utorid: ok. so ll will have a server which one can request information from with something like a soap or other http function calling mechanism
  • [11:25] Which Linden: Right
  • [11:25] FWord Utorid: and each opensim would have similar
  • [11:25] SignpostMarv Martin: I had this odd idea for a deferred set of POST actions, where one grid's services makes a request for an asset, gets a 202 Accepted response from the other grid's services while the grid makes up it's mind whether or not to send the asset over
  • [11:25] Which Linden: OK, that is one way of how the details of an operation could be implemented
  • [11:26] Which Linden: So, in this world I'm describing, you talk to a transaction coordinator and tell it everything about your transaaction
  • [11:26] SignpostMarv Martin: "I CAN HAS ASSET ? KTHXBAI" :-P
  • [11:26] Which Linden: And it goes to all the relevant domains and performs the operations
  • [11:26] Which Linden:  :-)
  • [11:26] FWord Utorid: ok. so would there be multiple nodes of these coordinators, or a centralized one
  • [11:27] Which Linden: Irreleveant
  • [11:27] SignpostMarv Martin: ^the 202 Accepted header allows for deferred transfer of assets, as I'd imagine you could DOS a grid with asset requests
  • [11:27] Which Linden: Or - Fword - do you mean is there One True Coordinator or many?
  • [11:28] Which Linden: I think that the answer is going to be "many"
  • [11:28] FWord Utorid: yes, that's what i was asking, if there would be many
  • [11:28] Which Linden: It's just a piece of software
  • [11:28] FWord Utorid: ok. so the structure of the service is defined, you had four kinds of messages
  • [11:29] Which Linden: Right so a transaction initiator (e.g. a resident) sends a description to the coordinator, which then gets translated into a series of CRUD operations on various domains
  • [11:29] Which Linden: So -- what can cause teh transaction to fail?
  • [11:29] JayR Cela: everything should remain simple / so many times I meet new folks that can not grasp how to do things
  • [11:29] Yohan Pintens: giant rats eating through the ethernet cables?
  • [11:30] Which Linden: One obvious way is if the transaction happens to involve a domain that teh coordinator knows to be evil
  • [11:30] JayR Cela: and i end up wasting way to much time trying to teach them simple stuff
  • [11:30] FWord Utorid: well, you would need to have multiple transaction coordinators like you'd said previously, and some means of determining which node is the owner of a request, and which nodes would be redundant
  • [11:31] JayR Cela: as a result i do not voulenteer mt time any longer
  • [11:31] Which Linden: Sure, JayR, the idea is that these transactions will be as simple as transactions today are, or simpler, we're just talking about teh under-the-hood behavior
  • [11:31] Which Linden: FWord: you mean for scaling purposes?
  • [11:32] Siddhartha Fonda: can the requested reseource on the other end vanish before the retrieval request from the coordinator?
  • [11:32] FWord Utorid: well, you were asking what would cause it to fail, and i think a lack of redundancy would be the primary cause
  • [11:32] FWord Utorid: the other issue i could see would be the intermediaries miscommunicating... but that was just a side observation... ok so perhaps these are llsd or another form of xml, and what they are going to be doing is authorizing requests for materials?
  • [11:32] Which Linden: Sorry I meant "fail" as in "consciously aborted", not "accidentally died in packets"
  • [11:33] Which Linden: Siddhartha: yep, good one
  • [11:33] FWord Utorid: ok. so basically, it's an authorization request for prims scripts textures or other data, and it can be denied
  • [11:33] Which Linden: Yep
  • [11:33] Which Linden: Both ends can cause teh transaction to be aborted
  • [11:33] JayR Cela: i think the biggest concearn right now is IBM and SUN MICRO / Sun just had a major shakeup here in SL
  • [11:34] FWord Utorid: ok. and would the authorization request be like caps, where the raw informational data is sent over the udp, but the access requests are http?
  • [11:34] JayR Cela: hey UDP is dead
  • [11:34] Which Linden: The coordinator can say "I don't trust this guy to deliver the resources", and the Domain can say "I don't trust this coordinator to successfully complete the transaction"
  • [11:34] JayR Cela: why you keep using this outdated technoligy
  • [11:34] JayR Cela: get rid of it
  • [11:35] Which Linden: FWord: I don't think it works that way.
  • [11:35] SignpostMarv Martin: I would imagine the resources would either be assets (files) or a manifest of assets ( objects/ attachments), right ?
  • [11:35] Siddhartha Fonda: thinks JayR joined the wrong discussion lol
  • [11:35] FWord Utorid: which, so far all of what you are suggesting makes perfect sense, regardless of what pipeline gets used
  • [11:35] Yohan Pintens: caps or udp are both just transports for the packets
  • [11:36] Siddhartha Fonda: or if the resource on the other end was like, one only as opposed to copy, concurrent requests come in, the 2nd one fails, that type of thing,
  • [11:36] Siddhartha Fonda: i guess is concurrency type stuff, not sure if that's what you're looking for here Which
  • [11:36] Which Linden: SignpostMarv: yes, that's one kind of resource, though other kinds of resources are : L$, group slots, parcel access grants, etc
  • [11:36] SignpostMarv Martin: hrm
  • [11:36] SignpostMarv Martin: there's a question
  • [11:36] Siddhartha Fonda: ok cool i was thinking in terms of objects only, not the other types of resources, so... hmm...
  • [11:36] SignpostMarv Martin: would an asset be delivered from the grid the agent is connected to, or directly from the original grid to the agent's viewer ?
  • [11:37] Which Linden: Siddhartha: yeah those are also ways it can abort, these are good to mention
  • [11:38] Which Linden: SignpostMarv: I think that gets into the other problem I mentioned at the beginning
  • [11:38] Which Linden: to continue with ways a txn can be aborted
  • [11:39] Which Linden: Another way is if we allow the Domains to inspect the transaction
  • [11:39] Which Linden: and decide whetehr that's acceptable
  • [11:39] SignpostMarv Martin: "original grid > current grid > viewer" would boost storage requirements for a grid operator (and effectively turn them into a proxy cache),
  • [11:39] Lor Gynoid: The mechanism as described would seem to be usable to support things like locally cached copies of regions or assets, I guess.
  • [11:40] SignpostMarv Martin: whereas "original grid > viewer" would boost bandwidth requirements for a grid operator
  • [11:40] Which Linden: E.g. a domain should validate that when the coordinator asks it to Reserve an object, that the transaction involves some sort of payment to the object's owner that is equal to or greater than the sale price
  • [11:40] FWord Utorid: signpostmarv, objects would have to be present in the sim for the shared experience and the physics interactions
  • [11:40] SignpostMarv Martin: physics shells != objects
  • [11:40] FWord Utorid: shared experience :P
  • [11:41] JayR Cela: ok then effectively you put everyone out of business
  • [11:41] FWord Utorid: plus scripting :P
  • [11:41] Which Linden: Well we generally assume that teh viewer is not a reliable entity
  • [11:41] FWord Utorid: the sky is not falling
  • [11:41] Siddhartha Fonda: intriguing
  • [11:41] SignpostMarv Martin: textures wouldn't have to be present in the sim
  • [11:41] FWord Utorid: the would have to be distributed to the users of the sim
  • [11:41] Which Linden: So you wouldn't want the viewer to be a canonical source of anything
  • [11:41] Siddhartha Fonda: so the money xfer from requestor happens during reserve
  • [11:41] SignpostMarv Martin: a texture would just be an asset reference, but it wouldn't need to be housed on the current grid in order for the viewer to see it on the current grid
  • [11:42] Which Linden: Siddhartha: no, actually, it's just that the coordinator sends along a description that says "this is what I will do"
  • [11:42] FWord Utorid: signpostmarv, sure, just like google doesn't have to host all of the images for sites it indexes.
  • [11:42] Siddhartha Fonda: oh ok
  • [11:43] JayR Cela: FWord that seems to be a reasonable approach
  • [11:43] SignpostMarv Martin: an attachment doesn't need to be present in the grid either
  • [11:43] Which Linden: And teh domain will trust it to carry out those actions. It's like when you write a check, it's a promise that the check holder can then withdraw the money at a later date
  • [11:43] Siddhartha Fonda: gotcha
  • [11:43] SignpostMarv Martin: "this agent's avatar is wearing an object on this point, the object manifest is this, and the assets can be found here"
  • [11:44] Which Linden: Just like you don't accept checks from Da Pimpin' Bank O' Which, neither should a Domain accept checks from untrustworthy entities
  • [11:44] FWord Utorid: hmm... finance level, materials level, information level
  • [11:44] JayR Cela: OK / Wich / how you going to determine whom is trustworty ?
  • [11:45] Oz Larg: what is the criteria for trust?
  • [11:45] Which Linden: I don't have an algorithmic solution to that, JayR, though I'm sure some exist
  • [11:45] JayR Cela: who makes that decision ?
  • [11:45] SignpostMarv Martin: I don't suppose anyone is familiar with OpenID ? :-P
  • [11:45] Which Linden: At the most basic level you assume out-of-band communication
  • [11:45] FWord Utorid: there will probably be a signup and review process, and there would need to be contractual terminology involved.
  • [11:46] Which Linden: Yeah, like that
  • [11:46] Siddhartha Fonda: not yet, but i tend to like anything with "Open" at the front of the name marv lol
  • [11:46] Which Linden: OpenID describes authentication only, not trust
  • [11:46] Lor Gynoid: Usually if you want to transfer a critical resource like L$ you go though a trusted third party, who only hands over the L$ when the goods are confirmed delivered?
  • [11:46] SignpostMarv Martin: well,
  • [11:46] Which Linden: Exaactly, Lor
  • [11:46] SignpostMarv Martin: it does have "Allow Once", "Allow Always", "Deny"
  • [11:46] FWord Utorid: the question comes down to, who gets keys to parts of the asset server, and what part can they have keys to, and how will the locks work
  • [11:46] Which Linden: But how do you find out who's most trustworthy?
  • [11:47] FWord Utorid: you could measure commodities by their proposed or perceived value
  • [11:47] FWord Utorid: some items in-world are sold at a high price, others at a low price, others are freebies
  • [11:47] Which Linden: You could also measure the track record
  • [11:47] SignpostMarv Martin: well I would imagine that Agni would probably not trust any L$ or script actions from anyone (default empty whitelist),
  • [11:48] Which Linden: Since one's trustworthiness depends on how many times one does what one says, it's pretty simple to audit that actually
  • [11:48] SignpostMarv Martin: but would trust incoming texture actions (default empty blacklist)
  • [11:48] Which Linden: The asset server is kind of orthogonal
  • [11:48] Which Linden: It's an implementation detail of our Domain
  • [11:48] FWord Utorid: hmm... doing what one says is subject to interpretation
  • [11:48] Lor Gynoid: Trust normally works on the basis of reputation. Or, indemnity.
  • [11:48] SignpostMarv Martin: whereas IBM would probably trust only actions from Agni and IBM domains
  • [11:49] SignpostMarv Martin: I've had discussions with Will Norris about trust protocols before
  • [11:49] Which Linden: The coordinator could send along a measure of how much it trusts each of the participants
  • [11:49] Lor Gynoid: Loosing trusted status can be very expensive to someone.
  • [11:49] FWord Utorid: there are some fundamental issues which one could consider... like, a system with limited data storage could not conceivably cart off the asset server
  • [11:50] SignpostMarv Martin: the basic gist was "automating a level of trust is oxymoronic, but still doable"
  • [11:50] Which Linden: And then a Domain can refuse to participate in a transaction where, say, the level of trustworthiness never dips below .8
  • [11:50] Which Linden: er, got that backwards, you know what I meant
  • [11:50] FWord Utorid: so in a sense you could conceive of 'trusting' that there is only so much a person could 'steal' with a shopping cart, versus those with armored cars
  • [11:50] Which Linden: Yeah, I don't think that the trust stuff can or should be automated
  • [11:50] Which Linden: completely
  • [11:51] SignpostMarv Martin: it's easier to disapear with a shopping cart than it is with an armored car :-P
  • [11:51] Which Linden: Fword: yeah totally, it's an "acceptable risk"
  • [11:51] SignpostMarv Martin: hrm
  • [11:51] SignpostMarv Martin: automated trust
  • [11:51] SignpostMarv Martin: Spam
  • [11:51] Which Linden: The foundation of our entire economy, really
  • [11:51] SignpostMarv Martin: how do anti-spam programs decide what is Spam,
  • [11:52] SignpostMarv Martin: e.g. how do they decide whether or not a resource or request is trustworthy and should be honoured
  • [11:52] Nikita13 Bellic: ertrtjrjthfggggggghruthurfhghfjtuygufjgtrfygjstystresrsgtjdfhgrjkghfkjhhhhvnyufdyhgryfugyerusyguhdfsjhvfjbgrygtfshdgrsguktrgfsjghutruydhgjfhtuygurhskgjhfgshuhfshhtrgtughfhdskghskvhfsvgscnsehgjsfcgrycgsfdkghsgdgrdskgffvsnvkhrgsyvsukghyuvgyusgvyrrnveygvnynuuygrnkusngtfersytkauqiuynxkaxnfehcneygvvvergntycugt
  • [11:52] FWord Utorid: which, there's something else to be considered beyond mere commodities exchanges and identities, messages themselves could need to go from one grid to another
  • [11:52] Oz Larg: white lists?
  • [11:52] Lor Gynoid: Anti-spam works best with multiple sources of feedback from spamees.
  • [11:52] Which Linden: FWord: you mean IM?
  • [11:53] SignpostMarv Martin: deferred assets transfers would allow for requests to be analysed en-masse
  • [11:53] FWord Utorid: well, both IM and group IM, as well as local chat, if you are on the edge of a cross-grid region border
  • [11:53] JayR Cela: and that list needs to be updated hourly
  • [11:53] JayR Cela: or at least dailey
  • [11:53] Which Linden: or real-time
  • [11:53] SignpostMarv Martin: so you could decide whether to "trust" the requesting thing based on the asset requests it makes
  • [11:54] Which Linden: FWord: hmm... IM isn't generally considered transactional, and I'd prefer it stays that way, honeslty
  • [11:54] JayR Cela: and in doing so we create further delays to the http transmissions
  • [11:54] SignpostMarv Martin: if a bunch of unrelated assets are requested that are part of objects, and those assets are only referenced in those objects, but all of the assets in those objects weren't requested,
  • [11:54] FWord Utorid: one potential measure of trust or misuse could be volumetric... if a system is requesting large numbers of assets disproportional to it's perceived client size...
  • [11:55] SignpostMarv Martin: *and* the agent doesn't have global permissions to nab those assets,
  • [11:55] FWord Utorid: which,with regards to IM, i am just thinking... if i go to another grid, am I offline in SL...
  • [11:55] SignpostMarv Martin: then the request should probably be viewed with suspicion
  • [11:55] Which Linden: FWord: well no, cause your IM would be handled by the Agent Domain
  • [11:55] Saijanai Kuhn: wakes up and looks at the time. Darned ADHD meds
  • [11:55] Which Linden: and by "another grid" I assume you mean another Region Domain
  • [11:56] Which Linden: Hey Sai, glad you could join us
  • [11:56] FWord Utorid: yeah. so it sounds like i wouldn't need to be concerned about the piping of those IMs.
  • [11:56] Which Linden: Don't think so
  • [11:56] Which Linden: in the long run, anyway
  • [11:57] FWord Utorid: one thing i was thinking also, avatars should be alive all the time, even if they aren't connected
  • [11:57] SignpostMarv Martin: hrm
  • [11:57] JayR Cela: lol / i want my Atari 800 :_)))))))
  • [11:57] JayR Cela: was simple then
  • [11:57] Aimee Trescothick: if my avatar was alive all the time it would be doing at least 50% better than me
  • [11:58] Which Linden: I don't see why that would be useful
  • [11:58] FWord Utorid: it's a case to be made for another time, sorry. ;)
  • [11:58] Saijanai Kuhn: FWord, I think the plan is for the AD to handle things like IM notficiation, inventory and the like as though it were the avie when the avie is not logged in
  • [11:59] Which Linden: Well I'd be interested to hear it another time
  • [11:59] Lor Gynoid: Your avatar is/may always be capable of recieving IMs...
  • [11:59] Saijanai Kuhn: though, I think group IM should be exempted
  • [11:59] Which Linden: It seems like this discussion is winding down
  • [11:59] JayR Cela: hey / thanks for the conversation / *bigg huggs* to everyone / luv u all / stop on by the Party 2mrw
  • [12:00] Which Linden: Group IM is a total can of worms that we haven't even opened yet
  • [12:00] FWord Utorid: thanks which, i appreciate your willingness to elaborate on some of these premises
  • [12:00] Siddhartha Fonda: yes i gotta teleconf to get to lol but thanks which, i'm glad y'all have these, i'm learning as we go
  • [12:00] Which Linden: Thanks all for coming, and contributing to the discussion
  • [12:00] SignpostMarv Martin: inter-grid group IM ?
  • [12:00] Saijanai Kuhn: was thinking about that. AD should be the proxy for all the avies it handles and the central IM server shouldn't even know if an avie is online or not. EVER
  • [12:00] Which Linden:  :-)
  • [12:00] Which Linden: I'll catch you all next week
  • [12:00] Lor Gynoid: I'd be interested in a description of the implied agreements that the two sides in the transaction think they have, if that was written up somewhere.
  • [12:01] Saijanai Kuhn: so the central server sends out a group IM to the ADs and the ADs make the determiniation
  • [12:01] Siddhartha Fonda: bye all, have a great afternoon, or evening or morning as the case may be
  • [12:01] Which Linden: Lor: hm, uh, hmm, don't have too much time to write things up, if you want to I'll review
  • [12:01] SignpostMarv Martin: One set of people would probably like the IRC model, the other would like the Jabber IM model
  • [12:01] Which Linden: Anyway, I gotta run, carry on all
  • [12:01] Saijanai Kuhn: niether model fits a virtual world, letalone a meta virtual world