User:Which Linden/Office Hours/2008 Aug 21

• [11:01] Latif Khalifa: hi
• [11:01] Ancient Roar: hello
• [11:02] Audoa Giha: Hi all
• [11:02] Latif Khalifa: hi :)
• [11:03] Audoa Giha:  :)
• [11:04] Ancient Roar: feels like the waiting room in Beetlejuice
• [11:04] Audoa Giha: LOL
• [11:04] Which Linden: hoy hoy
• [11:04] Sierra Inman: Hi everyone
• [11:05] Sierra Inman: is it ok to sit here or was this seat reserved
• [11:05] Audoa Giha: now thats an AV
• [11:05] Sierra Inman: hehe
• [11:05] Audoa Giha: my fav is still the toaster tho
• [11:05] Sierra Inman: i love the tree
• [11:06] Sierra Inman: or is that bamboo
• [11:06] Which Linden: I can tell there are a lot of people here because it's taking forever for prims to download
• [11:06] Latif Khalifa: not really ;)
• [11:07] Which Linden: So what's going on with you all? Anyone try out Mono (is that even possible yet?)
• [11:07] Latif Khalifa: its not, waiting for the release of the rc viewer
• [11:07] Which Linden: Ssad
• [11:08] Which Linden: So I understand some folks might be interested in E, the langauge?
• [11:08] Latif Khalifa: i mostly excited about the prospect to script sl objects in a "real" programming language like c#, but that is still some time off
• [11:09] Graph Weymann: Heh. Hi.
• [11:09] Graph Weymann: E programmer and implementor here, but I haven't heard anyone think about having it in SL
• [11:10] Which Linden: No, I don't think anyone here has heard of it before
• [11:10] Renouf Frobozz: E?
• [11:10] Which Linden: Except Zero, he knows pretty much everything
• [11:11] Which Linden: It seems that the commonality between E and OGP is that both are capability-based
• [11:12] Which Linden: But beyond that I know little
• [11:12] Graph Weymann: if you want to know more about E feel free to ask me
• [11:13] Renouf Frobozz: [1]
• [11:13] Which Linden: Well, ok, what are capabilities in E represented as?
• [11:14] Graph Weymann: In the local case, E is an object-capabiltiy system (ocap) -- this means that they are just local object references, as in any memory-safe language
• [11:14] Which Linden: Ah, I see, so the runtime enforces the constraints
• [11:15] Graph Weymann: In the remote case, there is a custom protocol. Capabilities are either 'live refs' or 'sturdy refs'. Sturdy ref are URLs which designate their targets over long time periods. Live refs last as long as a TCP connection.
• [11:16] Graph Weymann: (This distinction is exposed to the application; the idea is that if you lose connection you need to resync with remote side and you do this by building up your live-refs from your sturdy-ref roots)
• [11:16] Which Linden: Sorry if this is a total newb question, but how do capabilities manifest themselves to the programmer? Simply as an instance?
• [11:16] Graph Weymann: Every reference is a capability
• [11:17] Graph Weymann: It's not a technical distinction but a way of looking at a reference rgaph (object graph)
• [11:17] Which Linden: Right, yeah, was gonna ask how those differ
• [11:17] Graph Weymann: Tht's the nature of object-capabilities -- you subsume the security into object-oriented+POLA programming
• [11:18] Which Linden: In our system, capabilities are more secure because they're unguessable -- it seems that if the capability is simply a memory address, it's more guessable and thus less secure... thoughts?
• [11:18] Graph Weymann: NO!
• [11:18] Which Linden: s/more secure/considered secure/
• [11:19] Morgaine Dinova: Back. Hi all :-)
• [11:19] Graph Weymann: you have it exactly backwards :)
• [11:19] Graph Weymann: Your capabilities are unguessable, but not unforgeable
• [11:19] Graph Weymann: In an ocap system you CANNOT construct a reference from data
• [11:19] Graph Weymann: just like in any memory-safe language
• [11:20] Which Linden: Ah... I see -- so, let me see if I have this right
• [11:20] Graph Weymann: this only holds in the local case, of course; insofar as E is distributed it is not a pure ocap system
• [11:20] Which Linden: In our system, you could forge a capability simply by constructing the url once you know the uuid and host
• [11:21] Graph Weymann: well, what is "the uuid"?
• [11:21] Morgaine Dinova: Their unforgeability results from the sparseness of the address space. They're unforgeable in the same sense that RSA keys are unforgeable.
• [11:21] Which Linden: However, in E, even if you know the address of an object, the runtime doesn't let you construct a capability from an int
• [11:21] Graph Weymann: if it is a capability ID, then that's perfectly fine; they already have it.
• [11:21] Graph Weymann: that's not forging, that's making use of the capability-as-data you have
• [11:21] Which Linden: Yeah, Graph, our capabilities have the general url structure https://host/cap/uuid/
• [11:21] Saijanai Kuhn: UUID is generated on the fly for specific purpose, IIRC
• [11:22] Which Linden: So if you can guess the uuid and the host, you can use the capability
• [11:22] Saijanai Kuhn: POST "gemme this cap" response here's this ad-hoc URL
• [11:22] Graph Weymann: sure, but it is spares, therefore not guessable, right? :)
• [11:22] Graph Weymann: er, sparse
• [11:22] Which Linden: Very sparse, so yeah not guessable
• [11:22] Graph Weymann: right, E and your system do not difer in this point
• [11:23] Graph Weymann: there's no reason you couldn't have OGP as a comm system in E
• [11:23] Which Linden: Oh, cool
• [11:23] Graph Weymann: but let's talk about your stuff :)
• [11:23] Graph Weymann: (comm system = component which translates mesages on references into network data -- or whatever)
• [11:24] Which Linden: If you want to check out the deets on OGP capabilities: [2]
• [11:24] Graph Weymann: Yeah, read that
• [11:24] Which Linden: Oh, ok
• [11:24] Graph Weymann: It seems sound to me
• [11:25] Graph Weymann: It's more the details of the protocols built on that that are unknowns and possibl Wrong! Wrong!!! :)
• [11:25] Which Linden: Correct me if I'm wrong, but it seems that the most interesting bits of any capability-based system focus around the capability-granting aspects of the system
• [11:26] Morgaine Dinova: Everything is possibly wrong wrong wrong ;-)
• [11:26] Which Linden: Heh, Rule 34
• [11:26] Graph Weymann: Well, you have a capability to A and to B, then you can pass A to B, and now B has A
• [11:26] Graph Weymann: that is the fundamental.
• [11:26] Graph Weymann: everything else is application-specific (though of course there are use patterns that are common)
• [11:27] Graph Weymann: (revokers, membranes, facets, ...)
• [11:27] Which Linden: What are membranes and facets?
• [11:27] Which Linden: A revoker I understand
• [11:28] Graph Weymann: Facets are the fundamental of capability POLA
• [11:28] Graph Weymann: You divide a thing-in-your-application into facets
• [11:28] Graph Weymann: Each facet is given to (some subset) of clients fo your thing
• [11:28] Graph Weymann: Each facet lets them do only what they need to do
• [11:28] Graph Weymann: For example, you can have read-write access to omething and read-only access
• [11:29] Which Linden: How does a facet differ from a capability? Is it composed of capabilities?
• [11:29] Morgaine Dinova: I think erights.org has used some of the leading edge SL slowdown technology ;-)
• [11:29] Graph Weymann: Facets are not a basic concept - they are a way-of-understanding-the-structure
• [11:29] Graph Weymann: For example, if you use pipe() in unix, you get two facets - the read-end and the write-end. The pipe itself a compoite of those two facets, is not something you have a handle on directly.
• [11:30] Morgaine Dinova: The pipe is merely anonymous. The fact that you can't name it doesn't alter its semantics
• [11:30] Graph Weymann: (unix file descriptors are quite similar to object-caps - you can't forge a fd)
• [11:30] Which Linden: OK, I think I'm getting it, a facet isn't a tangible thing, it's more of a design pattern
• [11:30] Graph Weymann: Right!
• [11:31] Which Linden: [3]
• [11:31] Graph Weymann: Yah
• [11:31] Graph Weymann: So the important thing is to remember to divide your composites into the right facets
• [11:31] Graph Weymann: In a capability system you *NEVER* ask "who is sending me this messae"
• [11:32] Graph Weymann: Instead you arrange for "them" to get the appropriate facet of you
• [11:32] Graph Weymann: If you ask "who is sending me this message" then you have identity-based access control and the confused deputy problem, and prohibit delegation
• [11:32] Graph Weymann: All of these are nearly entirely opposed to the cpability paradigm
• [11:33] Graph Weymann: This does not mean that you can't have avatar identites, or accounts/logins; but you must make them higher-level concepts.
• [11:34] Saijanai Kuhn: ack a lot of that going around lately
• [11:34] Morgaine Dinova: That's not strictly true. It only affects the capability paradigm if you use the {origin.cap} tuple as your actual cap, which would be wrong. Being able to address the source doesn't mean that you've compromised your cap model.
• [11:35] Graph Weymann: Btw, I wrote a capability mud (look for "kpreid" "den") -- it contains some of my ideas about capabilities in virtual worlds, though it is terribly incomplete and half-baked
• [11:35] Saijanai Kuhn: [4]
• [11:35] Graph Weymann: Address the source -- as in sending replies? Yes
• [11:36] Graph Weymann: Bur you should not give the recipient a reference to the "sending object" -- that is too much authority
• [11:36] Saijanai Kuhn: hmmm
• [11:36] Graph Weymann: Just let them give a return value. You can think of that as a dinky little facet on the sender
• [11:36] Graph Weymann: Remember, the reference graph is a directed graph!
• [11:36] Saijanai Kuhn: the way caps work at this poitn in OGP is you request the cap, which is a URL. What do you mean by sending object?
• [11:37] Which Linden: Sheesh, I can has reliable wireless?
• [11:37] Morgaine Dinova: Hehe
• [11:37] Morgaine Dinova: Or lolz, I should say
• [11:37] Graph Weymann: Saiganai -- it would be something to do with the http client. It isn't a well-defined concept in general, so don't use it
• [11:38] Graph Weymann: HTTP is a pretty good place to start
• [11:38] Saijanai Kuhn: ah, OK, I think OGP sidesteps that bu not sure
• [11:38] Morgaine Dinova: I think we're conflating two separate layers here. OGP will use HTTP (and only CRUD specifically) for transport, nothing else. HTTP won't affect the OGP semantics.
• [11:39] Which Linden: OGP is not terribly object-oriented
• [11:39] Graph Weymann: C capability *is* an object, so yes it is :)
• [11:39] Graph Weymann: er, a capability
• [11:39] Graph Weymann: (Well, there are degrees. But don't take my talking about object as restrictive)
• [11:39] Saijanai Kuhn: well,OOP reqries inheritance according to Alan Kay, so object-baswed
• [11:39] Which Linden: Hah , yeah, but generally we issue multiple capabilities per underlying object
• [11:40] Graph Weymann: Yes, that means your underlying object is a composite, with many facets
• [11:40] Which Linden: So -- yes each capability is itself an object, but there's some higher-level concept that's represented by a suite of caps
• [11:40] Which Linden: Yeah
• [11:40] Which Linden: Did you get to explaining membranes?
• [11:40] Graph Weymann: We call it a composite even if the implmentation has one root object
• [11:40] Graph Weymann: A membrane is where you interpose forwarders in communication
• [11:41] Which Linden: Like the decorator pattern?
• [11:41] Graph Weymann: Think of a cell membeane -- every message goes through it, between the inside and the outside
• [11:41] Morgaine Dinova: A cap is opaque and semantic-free, so it's clearly not an object, even if you represent it as one in your code. It's an opaque reference, and it doesn't implement a capability at all. It merely provides a key to one.
• [11:41] Graph Weymann: YOu can use them to rewrite messages, or to revoke access (revoking is the primary use)
• [11:42] Graph Weymann: If you translate between cap protocols, the transator is also a membrane
• [11:42] Graph Weymann: The characteristic of a membrane is that if you pass a new cap through it ten the membran stretches to interpose on it as well
• [11:43] Which Linden: I see, a proxy
• [11:43] Morgaine Dinova: REST has forwarders (interfaces), but that's at the transport level (ie. HTTP), so we won't see the forwarders at the OGP level.
• [11:43] Graph Weymann: Yes, but with many facets -- one for each reference passing through it
• [11:43] Which Linden: Morgaine: be careful about confusing capability urls with the capabilities they represent
• [11:44] Which Linden: (re: your earlier comment)
• [11:44] Morgaine Dinova: Which: indeed, I was trying to separate them :-)
• [11:44] Graph Weymann: My interation with this simulator is effectively through a membrane
• [11:44] Which Linden:  :-)
• [11:44] Graph Weymann: If I get kicked out or disconnect, all my possibilities for interaction with any object in it immediately vanish
• [11:44] Which Linden: Hmm... yes, because the sim brokers all such interaction
• [11:45] Graph Weymann: Yes, but there is a specific concept of "my avatar being in the space"
• [11:45] Graph Weymann: All my interactions are mediated by that membrane
• [11:45] Which Linden: Ah -- I see, interesting way to think about it.
• [11:45] Graph Weymann: Similarly I can no longer talk at you if you disconnect, revoking your incoming-message connections to here
• [11:45] Saijanai Kuhn: is there a graphical markup for these concepts?
• [11:46] Graph Weymann: Yes, again, a membrane is a pattern, not necessarily a reified object (though it can be)
• [11:46] Graph Weymann: Saijanai, we use boxes and arrows :)
• [11:46] Graph Weymann: Half-circles are good for forwarders of all sorts
• [11:46] Saijanai Kuhn: advant guarde
• [11:46] Which Linden: Ha ha :-)
• [11:46] Graph Weymann: And a message in transit is a fat arrow on the reference-arrow, with references going out from the arrow representing the caps the message carries
• [11:47] Morgaine Dinova: Once we're fully cap-based though, the concept of "disconnection" won't exists --- the "session" is at a layer below the caps. In fact, that's the whole basis for mobile operation: we'll be able to pass the set of caps to some other client, and continue the VW presence somewhere else.
• [11:47] Graph Weymann: Plenty of diagrams like that in erights.org/elib/
• [11:47] Saijanai Kuhn: bookmarks
• [11:47] Graph Weymann: Morgaine, yes, I mean in general being no longer in the virtual space
• [11:47] Saijanai Kuhn: I'm seeing use for this stuff even if E itself won't be a fit
• [11:47] Graph Weymann: Just so
• [11:48] Graph Weymann: You are using a capability protocol (allegedly); all of this is capability design
• [11:48] Which Linden: Morgaine: yes, though I believe that we'd still have some sort of timeout based on the event queue
• [11:48] Saijanai Kuhn: though, seems that a bare bones simulation of OGP could be written in E just to test the ccaps-ness of it all
• [11:48] Graph Weymann: Remember: If you want to ask "who is making this request" then you didn't introduce enough facets.
• [11:48] Graph Weymann: Saijanai, absolutely!
• [11:48] Graph Weymann: And it should be bridgable to real OGP tranaparently
• [11:48] Saijanai Kuhn: E-OGP
• [11:49] Which Linden: That would be kinda fun
• [11:49] Graph Weymann: E is a good language for practicing capability design, even if the impls are not all that fast for practical purposes
• [11:49] Which Linden: I gotta say, I like the syntax of E much more than the syntax of Erlang
• [11:49] Which Linden: (how's that for a backhanded compliment :-)
• [11:49] Graph Weymann: It is built from the ground up to be a test-bed and demonstration of capability concepts
• [11:49] Morgaine Dinova: Graph: we are, although it's not so much design philosophy as design pragmatism: we're decoupling our protocols from the transport layer, yet still reaping the full benefits of running on web technology. The URI representation of caps is just an easy way to achieve that.
• [11:50] Graph Weymann: Sorry, are what?
• [11:50] Morgaine Dinova: Are using a cap protocol
• [11:51] Graph Weymann: Note that in using http as caps, you want to add one thing: verifying that the server is what it should be -- that it is what the provider of the URL intended to designate
• [11:51] Saijanai Kuhn: well, I think CAPs is the eseential part of OGP, not http
• [11:51] Graph Weymann: Look up Tyler Close's YURL and HTTPSY concepts
• [11:51] Graph Weymann: He is the expert on sing http as caps
• [11:52] Which Linden: Both HTTP and capabilities are essential
• [11:52] Graph Weymann: also, don't send the referer header!
• [11:52] Which Linden: Hah
• [11:52] Graph Weymann: You see why?
• [11:52] Which Linden: You mean, "don't use the referer header for anything meaningful"?
• [11:52] Morgaine Dinova: Indeed, the HTTP is at a layer belong. We could run OGP over string and tin cans using crawling maggots as packets ... but using HTTP over IP allows us to run OGP fast, because of all the work that gone into web tech.
• [11:52] Graph Weymann: No
• [11:52] Morgaine Dinova: s/belong/below/
• [11:52] Graph Weymann: You cannot use referer
• [11:53] Graph Weymann: Because if you do, then you leak caps
• [11:53] Saijanai Kuhn: Which, for implementation, ys. But you could base the architecture on some other transport if you needed to and just keep the capsness
• [11:53] Graph Weymann: say CapURLa is a container containing CapURLb. A request to b should not give the URL a, which would grant b access to a.
• [11:54] Saijanai Kuhn: so no circular references...?
• [11:54] Graph Weymann: Of course you can have circles.
• [11:54] Saijanai Kuhn: misunderstood
• [11:54] Graph Weymann: But you don't want the *implicit* transfers that Referer does.
• [11:55] Graph Weymann: if A gives you the url of B, B should not become aware of A when you make a request of B
• [11:55] Which Linden: Oh, I see Graph, yes.
• [11:55] Saijanai Kuhn: s a side-effect...
• [11:56] Saijanai Kuhn: concievably you could request a reconnect if the original connection to A went down
• [11:56] Graph Weymann: That's entirely unrelated...
• [11:56] Saijanai Kuhn: right.
• [11:57] Graph Weymann: Anyway, consulting Tyler CLose is a really good idea, if you're going to use caps on HTTP. he knows all the gotchas.
• [11:57] Which Linden: good to know, I'll write that down
• [11:57] Graph Weymann: [5]
• [11:57] Which Linden: Man, seriously what is up with erights.org? It's down more than up!
• [11:57] Morgaine Dinova: Aye, it has problems
• [11:58] Graph Weymann: I'll pass on the report :)
• [11:58] Which Linden: Ha ha, so where did E get started, and how did you get interested in it, Graph?
• [11:58] Which Linden: (I gotta go soon)
• [11:59] Graph Weymann: E was originally the scripting language for Electric Communities, a capability-based virtual world system
• [11:59] Morgaine Dinova: It's a damn silly name, chosen for coolness
• [11:59] Saijanai Kuhn: This specification defines a mechanism for identifying and authenticating an HTTP server based on the hash of a public key, instead of a certificate from a certificate authority.
• [11:59] Graph Weymann: (It died for business foul-ups)
• [11:59] Saijanai Kuhn: [6]
• [12:00] Graph Weymann: I got interested in E when I was looking at the problem of bulding a distributed virtual world, with some other people, and Bruce Mitchener said I really should check out E
• [12:00] Graph Weymann: eventually the idea of capabiltiis sunk in, and I've been working with them ever since
• [12:01] Which Linden: Awesome
• [12:01] Which Linden: Well, I really appreciate you taking the time to come here and discuss it
• [12:01] Graph Weymann: Sure.
• [12:01] Which Linden: and explain it to newb me
• [12:01] Which Linden: You're welcome, of course, to come back next week
• [12:02] Graph Weymann: Unfortunately I'm going into college and my mid-day tim will be mostly occupied for the next year, at minimum
• [12:02] Graph Weymann: But I'll see what I can do
• [12:02] Which Linden: Hmmm...ok, well, perhaps I'll see you some other time
• [12:02] Graph Weymann: feel free to join the cap-talk mailing list if you want to discuss a capability design problem
• [12:02] Saijanai Kuhn: referrals to other CAPs folk always welcome to
• [12:02] Morgaine Dinova: That's OK, we work around the clock :-)
• [12:02] Which Linden:  :-)
• [12:03] Graph Weymann: And I've passed on Saijanai's message there so others might show up...might.
• [12:03] Saijanai Kuhn: we're still pretty insular right now. Need as many eyes looking at this as possible, IMHO
• [12:03] Which Linden: Yeah, agree with that
• [12:03] Which Linden: OK, I do have to run, so.... till next time!!!
• [12:03] Morgaine Dinova: Cya Which :-)
• [12:04] Graph Weymann: Anyway, you can catch me anytime I'm around at #erights on freenode IRC
• [12:04] Graph Weymann: (I'm kpreid / Kevin Reid)
• [12:04] Saijanai Kuhn: thanks a lot for coming Graph. Think Which is excited about E now
• [12:05] Morgaine Dinova: If you arrange some SL talks or just chat sessions, you're bound to have lots of interested parties pop in
• [12:05] Tegg Bode: Cool stuff by sounds of it :)
• [12:05] Graph Weymann: I wasn't expecting to spend two hours talking :)