In some sense, a pico is like a personal computer in the cloud. It reacts to events and responds to queries in a way defined by its installed rulesets.
For ruleset identifiers, "We recommend using the Java convention of using the reversed name of a domain that you control, followed by a name that is unique within your organization. For example, we use the RID io.picolabs.wrangler
for one of our internal rulesets." (see Grammar page)
Every pico created has some system rulesets installed. These are like the OS of a personal computer. An application installs further rulesets, expanding the range of events and queries to which the pico will react and respond. Additional rulesets installed in a pico can layer on additional functionality.
We will outline here an example, layering general agent functionality on a pico, and then specializing further for connections to a specific kind of agent.
Agent Picos
The Sovrin self-sovrin identity solution calls for users to be represented by agents. To make a pico into a Sovrin agent, all that is required is to install the org.sovrin.agent
ruleset. A simple UI is built in as the pico's Agent tab.
org.sovrin.agent
ruleset
This ruleset, and the behaviors it implements, are specified by the Sovrin foundation. Therefore, the ruleset identifier uses the reversed domain name controlled by that organization, and it was written by a person on behalf of that organization. We show a few excerpts from this ruleset here:
Code Block | ||
---|---|---|
| ||
ruleset org.sovrin.agent { meta { use module io.picolabs.wrangler alias wrangler ... } global { ... } // // on ruleset_added // rule on_installation { select when wrangler ruleset_added where event:attr("rids") >< meta:rid ... } ... // // accept invitation // rule accept_invitation { select when sovrin new_invitation url re#^(http.+[?].*c_i=.+)# setting(url) ... } ... } |
...
In addition, when this (org.sovrin.agent
) ruleset is installed, it reacts to a wrangler:ruleset_added
event raised by Wrangler, by executing the on_installation
ruleset rule (lines 12-15).
A agent-to-agent connection can begin when this pico accepts an invitation from another agent, using the accept_invitation
rule (lines 20-23). The Agent tab of the UI has a box into which the invitation URL can be pasted, and a button that can be clicked to send this event to the pico.
...
When we paste the short streetcred URL into the Agent tab (in the box inviting "paste invitation URL here") and click on the "Accept" button, the UI sends the sovrin:new_invitation
event to the pico.
As the pico engine looks through the pico's rulesets, it will not select the accept_invitation
rule from the org.sovrin.agent
ruleset. But, it will select the accept_streetcred_invitation
rule of the id.streetcred
ruleset. This is because the URL does not match the regular expression of the former, but does match the regular expression of the latter.
As the accept_streetcred_invitation
rules executes, it will raise the sovrin:new_invitation
event (again) this time passing it a url
attribute which matches the rule in org.sovrin.agent
but does not match the rule in id.streetcred.redir
. So this time, the accept_invitation
rule will select and as it executes it will begin the agent-to-agent connection using the c_i
parameter provided in the longer URL.