All

See this Github discussion for more about Drummond Reed began by explaining that the purpose of the Two-Layer Design Model Proposal. The purpose of this proposal was to see if we could achieve alignment by compartmentalizing which problems were solved where. He pointed out the following comments on the proposal so far:

• Samuel Smith raised questions in this context about different approaches to supporting composability.
• Darrell O'Donnell made some points about how TCP/IP required both TCP and IP to gain adoption.
• Jo Spencer spoke in favor of the "logical separation" of the proposal.
• Sam Curren suggested a specific set of five work items that could be a path forward.

Daniel Hardman then kicked off discussion with some thoughts about points he has made in the discussion by sharing screenshots #1 through #7 below from this slide presentation.presentation (which is also here: https://bit.ly/3oaR27Y). 

Wenjing Chu understood Daniel's argument for a number of his proposed features but felt that a different test should be used for whether a feature MUST be in the trust spanning layer, "If a feature is NOT included in Layer 2, it would be hard to implement in a higher layer." If a feature can be implemented in a higher layer and is not strongly required at the spanning layer, then it should not be in the spanning layer. This may leave some "ambiguity" at the spanning layer with regard to those types of features, but "sometimes ambiguity is useful in language".

Daniel Hardman felt strongly that the properties he has been describing cannot be at any higher layers without losing key qualities.

Antti Kettunen is open to the possibility that there are n layers above the TSP layer, and believes that is where the abuse is likely to happen. He suggests we should focus on the features that are needed by those higher layer to achieve Daniel's properties.

Wenjing Chu feels that is important that we move in a way that we define the two layers at the same time. So that way, we can consider both sides of the problem will be considered at the same time.

Drummond Reed shared that the question of whether we can accomplish our objectives with two layers or whether it must be one is precisely why he posted the Two-Layer Design Model Proposal. So far it is eliciting exactly the different perspectives needed to decide about this question.

Samuel Smith made the distinction between trust issues and reliability issues. He feels the latter are important, but the core problem is trust-across-domain-boundary problems. So he would prefer to focus on keeping the TSP layer as thin as possible to address the trust-across-domain-boundary problems, while at the same time keeping Daniel's other considerations/properties in mind as we design the minimal TSP layer because we do need to pay attention to those problems.

Jo Spencer returned to the original question of whether the TSP needs to be designed as two layers. He felt that Samuel Smith and Wenjing Chu are focused on bottom-up design. He feels it is only necessary to separate the TSP layer from the TTMP layer if there is a good reason for the TSP to be agnostic about the layers above it and leave open the possibility of additional protocols at the next higher layer. The separation can be either a logical separation or a physical one. 

He asked whether a trust task is only a trust task because it must communicate across trust boundaries. He gave an example of a trust task that may not need to cross trust boundaries: biometric verification within an edge device like a smartphone (but then admitted that the trust application requiring biometric verification may need to cross trust boundaries within the phone).

So he's asking the question of whether it is helpful to separate the bottom up from the top down considerations.

Wenjing Chu said that the trust tasks at Layer 3 are going to be very numerous, and there will be requirements for types of trust tasks that we are not going to be able to anticipate. That This suggests that there will be at least two higher layers, and maybe more. That again would focus the TSP on the "Inter Trust Domain Protocol (ITDP)" problem domain.

The reason for the focus of the TSP to be across trust boundaries is that there are many solutions within the a trust boundary. But the TSP needs to focus on across trust boundaries.

He also clarified that the "upper part" in this discussion should belong to Layer 3.

Drummond Reed did a check requested and received consensus with the whole group on the following axiom:

DECISION: There MUST be one and only one group about there be a single protocol at Layer 2 that to serves as the trust spanning protocol. 

Daniel Hardman said that the two layers layer design model might be acceptable if the second layer is either required or highly expected.

Antti Kettunen felt that the more features are available at the lower layer mean , the less negotiation is required. So he wants to look at the trade offs, but to do that, it would be more helpful to have more information about the business problems at Layer 3.

Wenjing Chu first wants to address the question about commonality. He used the examples of the two different host-to-host protocols — TCP and UDP — that evolved on top of IP. But that can could (and did) change over time as the computing world changes — for example most Internet traffic used to be over TCP, but now it is less so. So layering allows for the evolution of those protocols. Whatever assumptions we make today about Layer 3 protocols may change. Other designers may have in mind other target contexts (such as IoT or factory floors), but they could use TSP too. So we should be humble about Layer 3 protocol design.

His second point is that, if we have no compelling reason to include a feature in the base layer, we should leave it to a higher layer so that it the TSP protocol can be as thin as possible. That will result in the most durable TSP.

Drummond Reed made the point that adoption will actually work from the top of the stack down. ____________For example, adoption of the TCP/IP stack did not start with developers adopting IP. Rather they adopted TCP (or protocols above TCP that used TCP) because that was the easiest path for them. And TCP used IP. The same will be true here, which is why if we agree with the Two-Layer Design Model Proposal, we should ensure that the TTMP is developed and delivered at the same time as the TSP.

Jo Spencer feels that we decide on Jo Spencer feels that we need an anchor at the base, which is the TSP, that provide a baseline set of expectations for the TSP. One example is time-to-live or message-expiry as potential base capabilities. If we have a "flex layer" above the base layer, the flex layer gives us the ability to understand what the base layer needs.

Wenjing Chu suggested felt that if we are going to design the two protocols at the same time, it would be best to do it in separate task forces.

Jo Spencer thought it would be better to have "alignment".

Wenjing Chu felt said "feedback" would be more important than "alignment" because the latter would mean they depend dependencies in both directions, whereas the TTMP should depend on the TSP but not vice versa.

Daniel Hardman shared screenshot ##8 below and explained how it illustrated the choices we have in this discussion.

Drummond Reed loved Daniel Hardman's picture. ( So did many of the attendees in the chat.).

Jim St.Clair "I really couldn’t follow things til this visual."

Willem de Kok agreed.

Jo Spencer said that it is an interesting option for trust tasks to "skip" the TTMP layer, but that most would not.

Wenjing Chu said that, with a protocol stack, developers always have a choice of the protocols to use and the levels. The only thing that we can insist on is that if a trust task crosses trust boundaries, it should use the TSP.

Daniel Hardman made the point that he was arguing for common semantics to be pushed down to the lowest layer. But he can accept that some properties can be at a higher layer.

Willem de Kok "I hope that If Daniel (and we together with him ;)) can put all our passion in the TTMP and it becomes a very good one, then it could become the canonical one."

Darrell O'Donnell "This is what happened pre-TCP - there were oodles of inconsistent approaches right on top of IP. Thankfully things calmed down and we ended up with two - TCP and UDP. TCP had its abilities that drove many things into it. The UDP realm is where the things that didn’t fit with TCP landed in the UDP realm. Having 2 places where just about everything could fit was amazingly powerful. Having dozens or more is not empowering."

Wenjing Chu said that the right side means that the market will choose (of Daniel's diagram (screenshot #8) represents what we want to see happen in the market, i.e., that developers will choose ) to use the TTMP layer because it gives them what they need, just as they chose to use TCP rather than raw IP. 

Drummond Reed spoke about DIDComm being a potential at the next layer. _______candidate for what the Two-Layer Design Model Proposal calls (temporarily) TTMP.

Wenjing Chu also liked DIDComm at this layer just above TSP, and others _______

Drummond Reed talked about _________

Wenjing Chu talked about next features ________

also suggested there could be others over time, both because they improve upon DIDComm, or because they solve different problems than DIDComm (just as UDP solved different problems than TCP).

Drummond Reed summarized that today's workshop appears to have produced a general consensus that:

1. The two-layer design model makes sense because it partitions the problem spaces.
2. Development of both the TSP protocol at Layer 2 and the TTMP protocol at Layer 3 should proceed in parallel (likely in separate task forces).
3. As a result, we need to start executing on a communication strategy (and community strategy) to see who is attracted to work on each of these two layers respectively.

Wenjing Chu said he would be happy in the next TSP Workshop to prepare a set of slides proposing specific features of the TSP.

Jo Spencer seconded that step because if we follow this strategy, it is essential to decide which Jo Spencer what capabilities are required at the TSP layer and which are essential at the TTMP layer.

Samuel Smith raised questions in this context about different approaches to supporting composability.

Darrell O'Donnell made some points about how TCP/IP required both TCP and IP to gain adoption.

Jo Spencer spoke in favor of the "logical separation" of the proposal.

Sam Curren suggested a specific set of five work items that could be a path forwardDrummond Reed shared that BOTH of these protocol names ("TSP" and "TTMP") are strictly temporary for purposes of these discussions, and that we should make it a separate effort — at the appropriate time — to decide on the actual protocol names.