I’ve been seeing headlines about capabilities from Christopher Lemmer Webber for about two years, maybe more. None of the details behind those headlines actually manage to make me understand what they are and how they can be used by a regular developer. All I see are grandiose promises and techno babble.
CLW has a proven track record of putting to text moderately difficult concepts in the form of his work on the ActivityPub spc, but this seems a lot different and a lot less parsable by the common man.
Re: captp, if you want to get a more hands-on feel you could check out capnproto: https://capnproto.org/
…which is the same fundamental design as CapTP, but has implementations in a handful of different languages, some of which are more mainstream than scheme (which is what the current spritely goblins is implemented in). And there’s some ongoing discussion re: even making the stuff that Chris is working on compatible with it (as well as another system that mark miller’s company is working on).
Thanks for linking to that article, zenhack. And yes, CLW here. That’s about as good of an article as I can answer to on this one right now. :P
It’s hard to explain to someone why CapTP would be interesting. I tried above in the article. But I’ll note that I had exactly the same problem with ActivityPub. When I started working on ActivityPub, I’d try telling people that I was doing this decentralized social network stuff. “What? Huh?” I’d tell them, it’s like email, but for social networks… anyone could host a node. They’d get it a bit more, and then not get it. Obviously this wasn’t true for everyone, but it was true for most people.
Once Mastodon really took off, and once Mastodon picked up ActivityPub, it was as if everyone was like, “oh yeah, ActivityPub, of course ActivityPub.” I was both relieved but it was also a bit maddening. This thing I spent three years on trying to explain to people and justify my work… it went from being completely incomprehensible to people to blasted on the front page of lobste.rs and Hacker News 2 or 3 times a week. What happened?
So yeah. You can’t tell people anything… they need to experience it.
This is partly why I’ve tried to take the demo-centric approach in Spritely. The time travel in Terminal Phase demo is honestly not the most interesting demonstration of the underlying technology… but it is the most visually apparent that something interesting and exciting is going on.
The upcoming demos, once Goblins v0.8 get out the door, hope to do the same for the transactional / time traveling part of the underlying technology as for the networked communication. But I need to actually put them out there. I have a very small demo with goblin-chat, and quite literally small: in about 200 SLOC, a working peer to peer networked secure chat system, without a single line of that code mentioning the network. You can see that people have reacted to screenshots of that and the previous gif released as part of Goblins v0.7, because those were shinier and gave people something to soak their brains in.
But really I need to get networked demos in peoples’ hand. There will be a time where captp-using things swamp HN and Lobsters as much or honestly quite a lot more than ActivityPub… but it won’t be because people are trying to stare at the underlying protocol. It will be because people are experiencing it.
In my humble opinion @paroneayea, the demos you made explain nothing at all. Terminal phase is great game, but time traveling in an immutable or append-only world is easy-peasy. globin-chat great demonstration of racket powerful framework. What does Spritley enable compared to without it? I mean I can both build terminal phase or a globin-chat app without Spritley.
I’d try telling people that I was doing this decentralized social network stuff. “What? Huh?” I’d tell them, it’s like email, but for social networks… anyone could host a node.
I think this is due to gap of knowledge and wide diversity of people (with diverse interests) reading you that makes explaining the whole machinery difficult.
I am overly naive in the first paragraph to try to explain what I think people do not understand or glimpse over and focus on what they see, instead of trying to imagine what they could build with Spritley framework. And I think you should stress the fact that with Spritley it is possible to build the same applications (albeit not the same way) that with nowadays frameworks or SDKs.
[copy paste and remove what is inside brackets if it is too verbose]:
Spritley is a framework that builds upon the Internet network, where users [programs inside servers or personal computers] can not be blindly trusted [in Spritley’s website it is written as “mutually suspicious network”, called “untrusted network” in the literature, unlike a controlled environment such as the network of a centralized application made of private servers OR the network built out of personal computers inside the household’s wifi aka. a private network where the threat model can be cooled down. Still Spritley may be useful even inside a given organization’s private network or across several trusted organizations. Like Wikipedia’s Capability-based security explains, it can be used and is used as part of Operating Systems (Kernel + Desktop Environment + …)]. Spritley allows to establish some trust among its users. Since each user may trust and hand trust to another user, it creates one or more networks of trusts along different software defined aspects. Hence, Spritley establish several network of some trusts. Each user might trust another user, hence allow another user different things: user-to-user mutual relationship builds on several aspects, is not necessarily symmetric, nor systematic, and ever more so not systematically shared among a group a users that trust each other “a lot” [that is, the group trust each others on many different aspects]. Trust is defined by algorithms [both Spritley’s algorithms, and application’s algorithms] and how and who is handed the ability to do something depends on what the something is. Moreover, Spritley makes the development of application that communicates over the network: transparent [such as what Erlang or Gambit Scheme’s Termite does]. That is, the application built on top of Spritley will not have the need to access BSD socket’ file descriptors directly, instead it might be given an abstract object [a value, an integer reminiscent of file descriptors, a variable, whatever…] that allows the application to execute some function [procedure or method] [possibly] remotely [a Remote Procedure Call] without noticing that it needs to reach the Internet network.
Putting it all together: Spritley make easy to build rich decentralized applications [that is without a central authority,] without being naive [aka. not everybody is nice], and without a loss of interactivity or generality [that includes games, social networks, stores, or whatever…].
terminal-phase and goblin-chat can both be built without Spritely in the sense that you can build things that look like them. However, there are some differences… goblin-chat is the more important of the two. You can build something like goblin-chat in other systems… but goblin-chat’s entire “protocol” for client-server is (I just checked) 167 SLOC… for the chatrooms and for the users. It’s also end-to-end-encrypted / peer-to-peer… yet not a single line of code above mentions cryptography or the network. What? How! Well, that’s the CapTP abstraction doing its job. So yes you might write something like the above in “any language”, but could you achieve all those properties in such a small amount of code? Without mentioning the network or cryptography once… yet having a networked and cryptographically secure communication system in the end? (The GUI that sits on top of the protocol is itself less than 300 lines of code, including comments and whitespace.)
As for terminal-phase… yes, you could write that in another system too. I think you’re handwaving a bit much if you’re calling it “easy-peasy” though, that seems a bit dismissive. Yes, you can have time travel in nearly any functional game engine. What’s more interesting is that the style of Terminal Phase looks half functional, half imperative, and that it was entirely written before I even thought about that time travel existed, then I exposed it in an hour or two.
So you’re right, you could do these things elsewhere. And thus it’s not fully descriptive looking at just them as demos on their own either… you have to read the surrounding context. But with that context, I do think these are unusual demos.
Half of the issue is that it’s entirely a different paradigm from default approach of using access control lists, and rarely used in practice. Building transport and communication networks on top of that is again, is even rarerer. On top of that, the person you mention seems to deal with linked data and the semantic web, which was an exciting area of research in the 2000s which so far hasn’t really found industry applications. So, yeah.
But if you had given some specific examples of what you’re confused by, it might be possible to help solve that.
For an example of some of the problems that Capabilities solve, then the paper ACLs Don’t is pretty good, as is The Confused Deputy. For a bit more depth, Mark Miller’s erights site is pretty good, but it’s somewhat pithy, and might require a bit of reference chasing for more detail.
A regular user would use a capability by sending it a message. The ability to send the message is connected to the possession of the capability. You could think of capabilities as credentials, at an introductory level.
I produce a flavor of E, and in these languages, capabilities are modeled by Smalltalk-style objects. Sending an object a message is equivalent to invoking that object as a capability.
Mark Miller’s paper An Ode To The Granovetter Diagram is as good an intro as I’ve found. I can’t claim to know capabilities well, but I’ve run across them multiple times in the past decade.
The simplest explanation I can muster: Imagine you have a robust & secure distributed-object protocol (OO RPC) that allows long-lived object references to be passed transitively between peers: A creates an object, sends a reference to B, then B sends it to C … and finally C can send that reference to A, which derefs it to the same local object.
This is cool in many ways, but especially in that it allows these objects to serve as authentication / authorization tokens … which are called capabilities.
This is where my ability to explain gets sketchy, but as a simple example, say A decides to give B the right to do something. It creates an object describing this, like maybe just (B, read-only, docs/fooproject), and passes B a reference to the object. Now any time B wants to read those docs it passes a reference to that capability as a parameter to the request, and A can deref it and verify it.
It gets even more interesting when you can pass capabilities along to third parties, like delegating authority. Maybe C has more info about fooproject, and when B wants to access that it calls C and passes along the capability token it got from A. C reasons “A gave B access, and I trust A to do that, so I’ll let B read my documents.”
Are the Pony people involved in this too? I’ve been looking in on Pony once in a while; it’s a language strongly based on actors and capabilities, inspired by E, so I’d expect it to be connected to this work. (At a selfish level, I’m more enthused by the idea of coding in Pony than I am about either JS or LISP.)
Afaik there’s no direct crossover with the pony community, but there could be! Actually, I think a Cap’n Proto implementation for Pony would be really neat, and a particularly good fit based on its focus on performance. But no-one’s written one.
(Per my comment elsewhere, Cap’n Proto RPC has the same basic design as spritely goblins, and there is on-going discussion of trying to make them compatible).
The part I have trouble with, is merely having a reference to A is proof you can access A. No problem, but if I can send messages to A, I can in theory exhaustively search the namespace of A and come up with a reference. Since most developers will stick to sane naming and not random UUID’s for function names, the chances of figuring out the right name goes up drastically. This is the part I don’t understand about how a ‘reference == access’.
Capabilities in the more traditional sense are 2 things, a crypto token(say a macaroon, which is awesome) and a reference to call the function/object in question. This way just knowing the name of something doesn’t get you where you want to go.
The part I have trouble with, is merely having a reference to A is proof you can access A. No problem, but if I can send messages to A, I can in theory exhaustively search the namespace of A and come up with a reference.
I think there’s a disconnect here. In a typical CapTP API, there is no human-readable name for an actor that exists at the protocol level – in your program, you’ll have a variable name that stores the object reference, but on the wire it is indeed just some meaningless number, which cannot be pulled out of the ether.
In fact, in CapTP’s design, references you hold on one side of a connection are not even merely un-guessable, they are truly un-forgable (assuming the network transport is itself secured). Basically, each side of the connection maintains a set of tables mapping integers to object references on one side of the connection or the other, so on the wire you send messages like call(export-id #1, ). So knowing an export ID that I’m using to make calls doesn’t actually help you gain access to that object, because if you open up a new connection and try to use that export id, it will be looked up in the table for your connection, not mine – in the same way that if on a unix box you do write(1, …), you’ll write to your stdout, not mine.
Obviously you have to bootstrap into the network somehow in order to get an initial reference to something, which maybe you can do by a cryptographic exchange or something, but from there you can only get new object references by making method calls and receiving results which contain those references.
I’ve been seeing headlines about capabilities from Christopher Lemmer Webber for about two years, maybe more. None of the details behind those headlines actually manage to make me understand what they are and how they can be used by a regular developer. All I see are grandiose promises and techno babble.
CLW has a proven track record of putting to text moderately difficult concepts in the form of his work on the ActivityPub spc, but this seems a lot different and a lot less parsable by the common man.
I think Chris is aware that not everything’s totally getting across, see: http://dustycloud.org/blog/if-you-cant-tell-people-anything/
Re: captp, if you want to get a more hands-on feel you could check out capnproto: https://capnproto.org/
…which is the same fundamental design as CapTP, but has implementations in a handful of different languages, some of which are more mainstream than scheme (which is what the current spritely goblins is implemented in). And there’s some ongoing discussion re: even making the stuff that Chris is working on compatible with it (as well as another system that mark miller’s company is working on).
Thanks for linking to that article, zenhack. And yes, CLW here. That’s about as good of an article as I can answer to on this one right now. :P
It’s hard to explain to someone why CapTP would be interesting. I tried above in the article. But I’ll note that I had exactly the same problem with ActivityPub. When I started working on ActivityPub, I’d try telling people that I was doing this decentralized social network stuff. “What? Huh?” I’d tell them, it’s like email, but for social networks… anyone could host a node. They’d get it a bit more, and then not get it. Obviously this wasn’t true for everyone, but it was true for most people.
Once Mastodon really took off, and once Mastodon picked up ActivityPub, it was as if everyone was like, “oh yeah, ActivityPub, of course ActivityPub.” I was both relieved but it was also a bit maddening. This thing I spent three years on trying to explain to people and justify my work… it went from being completely incomprehensible to people to blasted on the front page of lobste.rs and Hacker News 2 or 3 times a week. What happened?
So yeah. You can’t tell people anything… they need to experience it.
This is partly why I’ve tried to take the demo-centric approach in Spritely. The time travel in Terminal Phase demo is honestly not the most interesting demonstration of the underlying technology… but it is the most visually apparent that something interesting and exciting is going on.
The upcoming demos, once Goblins v0.8 get out the door, hope to do the same for the transactional / time traveling part of the underlying technology as for the networked communication. But I need to actually put them out there. I have a very small demo with goblin-chat, and quite literally small: in about 200 SLOC, a working peer to peer networked secure chat system, without a single line of that code mentioning the network. You can see that people have reacted to screenshots of that and the previous gif released as part of Goblins v0.7, because those were shinier and gave people something to soak their brains in.
But really I need to get networked demos in peoples’ hand. There will be a time where captp-using things swamp HN and Lobsters as much or honestly quite a lot more than ActivityPub… but it won’t be because people are trying to stare at the underlying protocol. It will be because people are experiencing it.
In my humble opinion @paroneayea, the demos you made explain nothing at all. Terminal phase is great game, but time traveling in an immutable or append-only world is easy-peasy. globin-chat great demonstration of racket powerful framework. What does Spritley enable compared to without it? I mean I can both build terminal phase or a globin-chat app without Spritley.
I think this is due to gap of knowledge and wide diversity of people (with diverse interests) reading you that makes explaining the whole machinery difficult.
I am overly naive in the first paragraph to try to explain what I think people do not understand or glimpse over and focus on what they see, instead of trying to imagine what they could build with Spritley framework. And I think you should stress the fact that with Spritley it is possible to build the same applications (albeit not the same way) that with nowadays frameworks or SDKs.
[copy paste and remove what is inside brackets if it is too verbose]:
Putting it all together: Spritley make easy to build rich decentralized applications [that is without a central authority,] without being naive [aka. not everybody is nice], and without a loss of interactivity or generality [that includes games, social networks, stores, or whatever…].
terminal-phase and goblin-chat can both be built without Spritely in the sense that you can build things that look like them. However, there are some differences… goblin-chat is the more important of the two. You can build something like goblin-chat in other systems… but goblin-chat’s entire “protocol” for client-server is (I just checked) 167 SLOC… for the chatrooms and for the users. It’s also end-to-end-encrypted / peer-to-peer… yet not a single line of code above mentions cryptography or the network. What? How! Well, that’s the CapTP abstraction doing its job. So yes you might write something like the above in “any language”, but could you achieve all those properties in such a small amount of code? Without mentioning the network or cryptography once… yet having a networked and cryptographically secure communication system in the end? (The GUI that sits on top of the protocol is itself less than 300 lines of code, including comments and whitespace.)
As for terminal-phase… yes, you could write that in another system too. I think you’re handwaving a bit much if you’re calling it “easy-peasy” though, that seems a bit dismissive. Yes, you can have time travel in nearly any functional game engine. What’s more interesting is that the style of Terminal Phase looks half functional, half imperative, and that it was entirely written before I even thought about that time travel existed, then I exposed it in an hour or two.
So you’re right, you could do these things elsewhere. And thus it’s not fully descriptive looking at just them as demos on their own either… you have to read the surrounding context. But with that context, I do think these are unusual demos.
Half of the issue is that it’s entirely a different paradigm from default approach of using access control lists, and rarely used in practice. Building transport and communication networks on top of that is again, is even rarerer. On top of that, the person you mention seems to deal with linked data and the semantic web, which was an exciting area of research in the 2000s which so far hasn’t really found industry applications. So, yeah.
But if you had given some specific examples of what you’re confused by, it might be possible to help solve that.
For an example of some of the problems that Capabilities solve, then the paper ACLs Don’t is pretty good, as is The Confused Deputy. For a bit more depth, Mark Miller’s erights site is pretty good, but it’s somewhat pithy, and might require a bit of reference chasing for more detail.
A regular user would use a capability by sending it a message. The ability to send the message is connected to the possession of the capability. You could think of capabilities as credentials, at an introductory level.
I produce a flavor of E, and in these languages, capabilities are modeled by Smalltalk-style objects. Sending an object a message is equivalent to invoking that object as a capability.
Mark Miller’s paper An Ode To The Granovetter Diagram is as good an intro as I’ve found. I can’t claim to know capabilities well, but I’ve run across them multiple times in the past decade.
The simplest explanation I can muster: Imagine you have a robust & secure distributed-object protocol (OO RPC) that allows long-lived object references to be passed transitively between peers: A creates an object, sends a reference to B, then B sends it to C … and finally C can send that reference to A, which derefs it to the same local object.
This is cool in many ways, but especially in that it allows these objects to serve as authentication / authorization tokens … which are called capabilities.
This is where my ability to explain gets sketchy, but as a simple example, say A decides to give B the right to do something. It creates an object describing this, like maybe just (B, read-only, docs/fooproject), and passes B a reference to the object. Now any time B wants to read those docs it passes a reference to that capability as a parameter to the request, and A can deref it and verify it.
It gets even more interesting when you can pass capabilities along to third parties, like delegating authority. Maybe C has more info about fooproject, and when B wants to access that it calls C and passes along the capability token it got from A. C reasons “A gave B access, and I trust A to do that, so I’ll let B read my documents.”
Are the Pony people involved in this too? I’ve been looking in on Pony once in a while; it’s a language strongly based on actors and capabilities, inspired by E, so I’d expect it to be connected to this work. (At a selfish level, I’m more enthused by the idea of coding in Pony than I am about either JS or LISP.)
Afaik there’s no direct crossover with the pony community, but there could be! Actually, I think a Cap’n Proto implementation for Pony would be really neat, and a particularly good fit based on its focus on performance. But no-one’s written one.
(Per my comment elsewhere, Cap’n Proto RPC has the same basic design as spritely goblins, and there is on-going discussion of trying to make them compatible).
The part I have trouble with, is merely having a reference to A is proof you can access A. No problem, but if I can send messages to A, I can in theory exhaustively search the namespace of A and come up with a reference. Since most developers will stick to sane naming and not random UUID’s for function names, the chances of figuring out the right name goes up drastically. This is the part I don’t understand about how a ‘reference == access’.
Capabilities in the more traditional sense are 2 things, a crypto token(say a macaroon, which is awesome) and a reference to call the function/object in question. This way just knowing the name of something doesn’t get you where you want to go.
I think there’s a disconnect here. In a typical CapTP API, there is no human-readable name for an actor that exists at the protocol level – in your program, you’ll have a variable name that stores the object reference, but on the wire it is indeed just some meaningless number, which cannot be pulled out of the ether.
In fact, in CapTP’s design, references you hold on one side of a connection are not even merely un-guessable, they are truly un-forgable (assuming the network transport is itself secured). Basically, each side of the connection maintains a set of tables mapping integers to object references on one side of the connection or the other, so on the wire you send messages like call(export-id #1, ). So knowing an export ID that I’m using to make calls doesn’t actually help you gain access to that object, because if you open up a new connection and try to use that export id, it will be looked up in the table for your connection, not mine – in the same way that if on a unix box you do write(1, …), you’ll write to your stdout, not mine.
Obviously you have to bootstrap into the network somehow in order to get an initial reference to something, which maybe you can do by a cryptographic exchange or something, but from there you can only get new object references by making method calls and receiving results which contain those references.
AH. Thanks, this helps my brain! So all the easy vulnerabilities will be around bootstrap time.