Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: typo

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
linenumberstrue
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.