A “subscription” is a two-way communication channel between a pair of picos. It is implemented by the io.picolabs.subscription ruleset which is installed in every pico which the pico-engine creates.

DID Comm is a two-way communication channel between a pair of Aries agents (such as, for example but not limited to ACA-Pico agents or ACA-Py agents). For picos it is implemented by the io.picolabs.aca ruleset which can be installed in any pico to make it into an Aries agent.

Both of these capabilities are approaches to a well-defined two-way connection between two systems as described in a white paper in “The Live Web Series” entitled “The Personal Channel.” A subscription functions like a “personal channel” as described in that paper. A DID Comm connection functions like a “hardened personal channel” as described therein.

Purpose

This page explores the possibility of replacing the subscription concept with a broader industry standard of DID Comm connections. However, our purpose here is to consider only pico-to-pico communication, rather than a broader interoperability between picos which are Aries agents and other Aries agents implemented using programming languages other than KRL.

Comparison of the connection implementations

For one pico to communicate with another pico it is necessary, and sufficient, that the first pico has in its state an Event Channel Identifier (ECI) to the second pico. Using this ECI, it can raise arbitrary events or send arbitrary queries to the other pico. A subscription provides two such channels, in opposite directions to a pair of picos, with the necessary state being maintained in entity variables of the io.picolabs.subscription ruleset.

For one Aries agent to communicate with another Aries agent, there must be a connection between them. Each is identified, for the purposes of this connection, by a Distributed Identifier (DID) and an associated DID Document. Each DID Doc includes “endpoints” which the other Aries agent can use to send a DID Comm message to this Aries agent. The necessary state information for a connection is maintained in a pico in entity variables of the io.picolabs.aca ruleset.

A subscription is created when one pico requests it by raising a wrangler:subscription event, which initiates a chain of events between this pico and another pico (for details, see the Managing Subscriptions page). When the other pico accepts the request, the subscription is established. An established subscription is represented within each pico by an entity variable (named established). Here, “Bob” has requested a subscription with “Alice” and she has accepted. From Alice’s perspective, this is the information stored by the io.picolabs.subscription ruleset:

A DID Comm connection is created between two Aries agents when one of them invites the other and that invitation is accepted (and a connections request sent to the inviter, which sends a connections response back). The connection between “Alice” and “Bob” is represented by information held in the connections entity variable of the io.picolabs.aca ruleset in the Alice pico as:

Similarities

At first glance these two structures look quite different, but they have similar components. They both contain an ECI for the pico named “Bob.” In the subscription, this ECI is named Tx while in the DID Comm connection it is named their_did. Similarly, the pico named “Alice” knows which ECI it has given to Bob, and these are named Rx and my_did respectively. Both contain a verification key (for signing) named, respectively, Tx_verify_key` and their_vk.

Differences

A subscription provides a different key for encryption, named Tx_public_key, while in a DID Comm connection, the same key is used for both signing and encrypting. All communications over a DID Comm connection are encrypted and signed, while a subscription offers only the possibility of encrypting selected event attributes, and this has to be done manually by the kRL programmer.

A DID Comm connection stores a label for the other end of the connection, while in a subscription this is implicit (i.e., the pico’s display name serves as a label). A DID Comm connection also maintains a creation timestamp, named created which a subscription does not have, and a subscription maintains roles (named Rx_role for this end’s role, and Tx_role for the other end) which a DID Comm connection does not have explicitly.

One final difference is that DID Comm allows for the possibility of routing messages through a series of other agents, whereas subscription only supports direct point-to-point routing.

An additional difference, important for the implementation, is how the information is located and identified. For a subscription, the field Id is used for this purpose, while with a DID Comm connection code typically uses the verify key (often abbreviated verkey or some such) which is the their_vk field of the connection map.