Yeah, once you give anyone a capability — bots included — there’s no stopping the capability from getting widely distributed. You have to bake in protections like revocability up front to be prepared for the case that they get disseminated beyond your intended reach. And, with agents, provided the agents behave in a way that is consistent with being unworried about their reputation, they could and might disseminate a capability widely, in their own network. So, a key to safely designing a bot network is to assume all the bots are in a clique and sharing all granted capabilities amongst themselves, as they can converge on that if they choose. At some point, it’s a game of managing their introductions. Hey, that’s a whole lot like parenting.
I’m Kris Kowal and I’m the tech lead on the Familiar project and happy to answer questions about building this new kind of user agent for safely managing and extending the capabilities of bots and apps.
I maintain ses, the compartment primitive LavaMoat relies on. The ses shim for hardenedjs.org creates compartments that deny guest code the ability to inspect the true global object or lexically reference any of its properties. By default, each compartment only sees the transitively frozen intrinsics like Array and Object, and no way to reach the genuine evaluators. The compartment traps the module loader as well, so you can only import modules that are explicitly injected. That leaves a lot of room for the platform to make mistakes and endow the compartment with gadgets, but also gives us a place to stand to mount a defense that is not otherwise prohibitively expensive.
You are absolutely right that React accomplishes much without discrete event-driven change propagation. React falls clearly under the "behavior" style of reactivity, meaning that the state is polled to effect change. This is particularly useful in situations where change occurs more frequently than rendering, or even continuously.
My use of the word "general" was more a joke than the scope of my intent. I meant "general" in the sense of "general relativity", meaning that I’ve proposed relationships among concepts that are often understood to be unrelated. Specifically, I wanted to debunk the notions that one of these tools is categorically better than the others or that any one of them should subsume the others.
Not exactly Functional Reactive Programming, FRB (Bindings) are actually a form of Self Adjusting Computation, but similar in spirit to what you see here, and what you see in Angular. You don’t need #get() and #set(), but it’s implemented using ES5 property descriptors and propagates synchronously. Also, unlike dependent properties like Ember, the dependencies do not have to be repeated—they are inferred from the expression language.
I published Q in 2009. I based it on another project by the same name and API that was published by Tyler Close in 2007. https://waterken.svn.sourceforge.net/svnroot/waterken/server... His work was based on the E programming language and the name is a reference to the underlying event "queue".
Q is around the 20th most depended-upon package in the Node.js package manager, NPM and is downloaded about 100,000 times a month. https://npmjs.org/package/q
I would recommend calling your library Qbix.js with the Qbix name space.
That's a good recommendation. Maybe we'll call it the Qbix library. It's just that our entire large framework (which primarily runs on PHP and Node.js) is called Q, and what I published is just one file from the front-end SDK..
