A “subscription” is a two-way communication channel between a pair of Picospicos. It is implemented by the io.picolabs.subscription ruleset which is installed in every Pico 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 picos it is implemented by the io.picolabs.aca ruleset which can be installed in an Pico any pico to make it into an Aries agent.
...
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 Picopico-to-Pico pico communication, rather than a broader interoperability between Picos picos which are Aries agents and other Aries agents implemented using programming languages other than KRL.
Comparison of the connection implementations
For one Pico pico to communicate with another Pico pico it is necessary, and sufficient, that the first Pico pico has in its state an Event Channel Identifier (ECI) to the second Picopico. Using this ECI, it can raise arbitrary events or send arbitrary queries to the other Picopico. A subscription provides two such channels, in opposite directions to a pair of Picosof 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 pico requests it by raising a certain event to another Pico wrangler:subscription event, which initiates a chain of events between this pico and another pico (for details, see the Subscriptions API page). When the other Pico pico accepts the request, the subscription is established. An established subscription is represented within each Pico 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:
...
At first glance these two structures look quite different, but they have similar components. They both contain an ECI for the Pico 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 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.
...
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 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.