• Start recording
• Welcome & antitrust notice
• Introduction of new members
• Agenda review

• Antitrust Policy Notice: Attendees are reminded to adhere to the meeting agenda and not participate in activities prohibited under antitrust and competition laws. Only members of ToIP who have signed the necessary agreements are permitted to participate in this activity beyond an observer role.
• New Members:

Discussion of progress on the working draft of the ToIP Technology Architecture Specification:

• Google Doc version 
• GitHub Markdown version
• GitHub issues list

I won’t likely make the Thursday meeting. Business has me messing with too much of the time I am supposed to be spending with friends that flew in from out of town.I suggest reviewing the two slides here: https://docs.google.com/presentation/d/1skHbfJqXaX8er8iUzisNWWnFCMp7bv2ZjKmsq4GXyeA/edit#slide=id.gf9dcc57430_0_4

• • First slide moves Cryptography, Compute, Storage, and Communications under Layer 1 - we aren’t doing ToIP-specific things there - we use them as would any other system.
  • Second slide may fit an appendix (and needs aligning) for telling the story of “How does XXXXXX compare with the ToIP 4-Layer Stack?”

Darrell's first slide is copied as screenshot #1 below and his second slide is screenshot #2.

Discussion: First slide could be updated with a vertical side bar that crosses layers for common ToIP support components used by all layers.

Scott Perry - need to get more detail. Registries are confusing as they are also needed at layer 4. Replace "registries" with "resolver(s)". Trust spanning is perhaps the right term - suggest interop layer

Allan Thomson - need the sidebar for common ToIP components/services. The world hasn't moved to DIDCOMM - what are the preferred protocols and channels for Layer 2. Change this to a set of (Interop) requirements for which DIDComm is the ToIP contribution. Need a diagram version that maps to OIDC (to provide a (conceptual) bridge)

• (Drummond Reed was not on the meeting yet due to Internet issues but later in the meeting noted that this was the purpose of Darrell's second diagram. See discussion below.)

Tim Bouma commented that DIDComm is a "heavy" solution to interop communications. There are several specs that are provided as "full-featured", which may be overkill for initial implementation and acceptance (and actually required functionality). Decentralized identifiers and Verifiable Credentials are other examples. The trend has been to "overspecify".

Drummond Reed said it would not only be a mistake to — at this point in time — specify DIDComm as the only Layer 2 trust spanning protocol, not only because there is not yet consensus on that, but because we put specifying explicit protocols out of scope for this architecture spec. That's the job of component specs.

ACTION: Drummond Reed to update Darrell O'Donnell's proposed diagram to incorporate the feedback from this meeting and then figure out where it best belongs in the next draft.

Neil Thomson suggested we want specifications for each layer expressed as requirements, not solutions and certainly not specific technologies.

Drummond Reed agreed with Neil — we need to be designing the right architecture and designing component specifications to meet those requirements.

Tim Bouma agreed that it is the need for a trust spanning protocol (or "hourglass protocol") that will "capture the imagination" of readers and help us gain the focus and support we need to complete the work of developing and/or assembling the component specifications. The way he expressed our ultimate goal is: "Today we don't think about how we're communicating (over the Internet); tomorrow we won't have to think about how those communications are trusted."

Allan Thomson pointed out that it is not necessarily the purity or beauty of an architecture that wins in adoption of a "stack", but about how easy it is to develop on. He gave a number of examples including TCP/IP. So we need to focus on what is going to use the trust spanning protocol, not the protocol itself.

On Darrell's second diagram (screenshot #2 below), there was consensus on the following decision:

DECISION: We will add a "Current State Mapping" appendix to the ToIP Technology Architecture Specification whose purpose is to provide a "snapshot" of how existing protocols, APIs, and technologies map into the ToIP technology architecture.

ACTION: Drummond Reed to include a first draft of the "Current State Mapping" appendix in the next Working Draft. 

APAC:

• Neil Thomson proposed to use a three-dimensional "cube" diagram that shows how to tie the different views together. See his sketch of such a diagram as screenshot #4 below.
• Neil and Jo both noted our previous discussions about Wenjing's diagrams being focused on comms protocols and not some of the other views. Both are needed.
• ACTION: Neil Thomson will create a first draft of a proposed three-dimensional "cube" diagram that can serve as an anchor to tie the different views of the stack.
• sankarshan asked "Is there a way we can have a repository of these different views of ToIP architecture and stack? It will be valuable now and also when there is a body of work to examine as archive."
  • Drummond responded that the repository for ALL the diagrams we have been creating are in one Google Slides document.
  • Sankarshan said that these should be moved to a GitHub repository for both archiving and review.
  • There was consensus on that point.
• Drummond Reed shared an update (screenshot #3) to Darrell's proposed stack diagram (screenshot #1) that incorporated several suggestion from the NA/EU call.
• Jo Spencer shared that the current set of diagrams in the spec were fully focused on the interaction patterns, and didn't really talk about the overall architecture of the stack.
  • Jo shared several other diagrams, including screenshot #5 below, that can help clarify the key terms. See the "mental model of system types" topic below.

We then talked about the proposed new appendix and how important it was to carry the message about interoperability with existing protocols.

• Review decisions/action items
• Planning for next meeting