Protocols vs API’s – Resolving the programming paradigm difference between DIF and Indy

Protocols vs APIs: Resolving The Programming Paradigm Difference Between DIF and Indy

Wednesday 7F

Convener: Daniel Hardman

Notes-taker(s): Daniel Hardman

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

1. Received from Daniel Hardman:

Here is the link to the slide deck that informed our discussion: 

https://docs.google.com/presentation/d/1FfvSfcjnjIbDkT9yUADI-7CJxjlm42eOZB534dXYRSs/edit

******************** ******************* ******************** ******************

2. Received from Eugeniu Rusu

The main goal of the session was to identify key conceptual / design differences between DIF Identity Hubs, referred to as Hubs, and Indy Agents, referred to as Agents(capitalized), and perhaps align the architectures to ensure that the implementations are compatible by design.

One of the first arguments made during the session was that the established client - server architectures that emerged from the caller / callee paradigm do not suffice for the problems that both Hubs and Agents aim to solve. This approach was deemed restrictive in a number of ways, mainly:

- Assumes two participating parties (server - client / caller - callee) - The server / callee maintains the state and is always authoritative of it - Interactions are modelled in terms of request / response loops, which  manifests itself throughout documentation, tests, and error handling flows. This can make it difficult to reason about the overarching protocol / subprotocols the individual interactions are a part of, e.g. in the case of error handling, it might be unclear if an error that happened at step 3 of a protocol (out of 5) means that the entire interaction should be repeated, or only step 3.

The argument was made that in order to more naturally model complex / multiparty interactions between agents online, "protocol" based thinking should be adopted. Protocols have the following characteristics :

- Multiparty (e.g. online auction where multiple buyers interact with one  seller, the peer did method specification). - Have clearly defined roles (e.g. buyer / seller), which are decoupled from being the caller or the callee. - Relevant state is distributed across the participating parties. - Subprotocols can be employed for things like error handling (e.g. if a vendor  did not understand the buyer's order, they can ask them to repeat the order, without having to restart the entire interaction).

Further differences can be found in the linked presentation.

It was also pointed out that in some cases the request / response flows cannot be satisfied by the transport itself (e.g.  simplex communication channels). Furthermore, in some cases agents can be offline, only reachable through push notifications, or only reachable indirectly (through other parties / relays). It is important to keep these factors in mind to make sure Hubs and Agents can accommodate a large spectrum of use cases.

After this introduction, the discussions related to conceptual differences between the designs of Hubs and Agents have started.

It was pointed out that a number of interfaces exposed both by both Hubs and Agents are not contentious (e.g. collections, stores), and that the responsibilities / characteristics of Hubs / Agents are similar (e.g. holding keys, acting as a fiduciary to an identity owner).

One contentious point seemed to be the "Actions" interface exposed by DIF Identity Hubs. The argument was made that this interface is designed with the client / server model in mind, and that despite the fact that hubs can form a mesh network without one central / governing instance, a strong perception of two party API-like interactions still persists. This argument was rebutted by participants involved with developing identity hubs, pointing out that the design of the aforementioned interface allows for multiparty interactions, and that the protocol state accumulated throughout the interaction is evenly distributed between the relevant participants.

As the session progressed, some participants noted that the language used to define Hubs / Agents and their responsibilities is at times ambiguous, and that some terms are overloaded. It was mentioned that this can lead to confusion, and foster the perception that the two initiatives are much more different than they actually are.

For the rest of the session, discussion was centered around the "Actions" interface in an attempt to clarify any confusion and false assumptions present in the group. It was concluded that the best way to reconcile the different understandings is to implement a protocol (e.g. the Indy Introductions protocol) using both Indy Agents and DIF Identity Hubs.

It was also decided that a further session should be scheduled to address any remaining questions.