2025-11-26 GATF Meeting Notes - Americas

2025-11-26 GATF Meeting Notes - Americas

This TF schedules meetings as needed. Each meeting will be announced on the #toip-governance-architecture-tf discord channel.

The meetings (and Zoom links) are available on the ToIP meeting calendar:
LFX Meetings

The calendar also gives access to past meeting recordings, transcripts, chat messages and AI generated minutes.

Zoom Meeting Links / Recordings

Video, Transcript, and Chat messages:

Video Conferencing, Web Conferencing, Webinars, Screen Sharing

Attendees

  • @John Phillips

  • @Neil Thomson

  • @sankarshan

  • @Makki Elfatih

  • @Drummond Reed (first half of meeting)

 

Agenda Items and Notes (including all relevant links)

Time

Agenda Item

Lead

Notes

3 min

  • Start recording

  • Welcome & antitrust notice

  • New member introductions

  • Agenda review

Chairs

  • 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.

2 min

Review of previous action items

Chairs

 

 

Topic #1

 

 

 

Topic #2

 

 

 

Topic #3

 

 

 

Topic #4

 

 

5 mins

  • Review decisions/action items

  • Planning for next meeting 

Chairs

 

Summary of meeting (auto-generated and reviewed/edited):

Quick Recap

The meeting began with discussions about meeting process changes and concerns regarding YouTube video uploads, followed by updates about the upcoming Thanksgiving holiday and the "hourglass" Trust Over IP diagram. The Governance Architecture Task Force meeting covered topics including Linux Foundation policies, AI-generated meeting notes, and the upcoming UNC forum in Senegal. The main technical discussion focused on the Trust Over IP diagram's hourglass model, including its placement and interpretation, with the team agreeing to maintain a flexible approach while ensuring clarity in their protocols and architecture.

Next Steps

  • John: Send an email to support@lfdecentralizedrust.org about problems accessing directories

  • John: Look at the LFDDT YouTube channel to check for auto-uploaded meetings

  • John: Share the diagram link in the meeting notes and leave it open for editing

  • Drummond: Finish the technical architecture spec and get it out in December

Summary

Meeting Process and Diagram Discussion:

The meeting began with a discussion about changes to the meeting joining process and concerns about automatic YouTube video uploads during meetings, which John raised at the steering committee. Sankarshan confirmed that the recordings were not being pushed to a custom endpoint. Neil joined the call, mentioning the upcoming Thanksgiving holiday in the US. The group awaited Drummond's arrival to discuss the narrow-waisted diagram for the trust over IP stack diagram, but Neil had a suggestion to resolve the problem. John planned to create a new page for the meeting and conduct a proper introduction, though he expressed doubt about the necessity of such formalities.

Linux Foundation Governance Updates:

The Governance Architecture Task Force meeting began with John reminding attendees about the Linux Foundation's antitrust policy and the importance of adhering to the meeting agenda. The group discussed the use of AI-generated meeting notes, which John noted have improved significantly. Neil expressed concern about the AI's ability to accurately capture meeting commitments and deliverables. The conversation ended with John mentioning the upcoming 40th forum for the UNC fact in Senegal and a panel discussion on the GRID, which Sankashan may attend.

Trust Over IP Diagram Update:

John presented a new version of the Trust Over IP diagram with a narrow-waisted shape, inspired by Wenjing's presentation at the recent symposium. Drummond suggested adding an overlay of the hourglass model between the fourth and seventh slides to emphasize the spanning layer concept, allowing presenters to focus on the governance process without delving into the full stack. The team discussed the challenge of fitting skeuomorphic icons into the narrow waist while maintaining visual clarity, and agreed to consider an overlay approach for future versions.

Trust Protocol Interoperability Discussion:

The team discussed technical issues with directory access and agreed to contact support for resolution. They explored the concept of the trust spanning protocol, which Neil described as a narrow communication mechanism across multiple protocols, essential for interoperability. Drummond emphasized the sophistication of the hourglass model design principle, which ensures efficient communication and interoperability within the Trust RP stack.

Hourglass Model Protocol Clarification:

John and Drummond discussed the importance of using simple and precise language in their protocols, emphasizing the need for clarity while avoiding terms that cause challenges. They agreed to use the term "hourglass" to avoid confusion and to ensure the model's metaphorical representation is understood correctly. Drummond suggested adding quotes around "Hourglass" to highlight its metaphorical nature, and John acknowledged the importance of this adjustment. Neil contributed by clarifying that the Hourglass model provides a single communication protocol that supports all protocols above it and is supported by those below, despite its visual representation.

Trust Bus and Layer Diagrams:

The group discussed the concept of a "trust bus" and its relationship to layer diagrams in their architecture. Neil explained that the term comes from hardware, where backplane buses enabled mixing and matching of components, and suggested that trust spanning could be seen as a communication protocol that connects different components. John and Drummond agreed that while there are multiple ways to interpret the layer diagrams, they should maintain consistency, with Layer 3 implementing protocols for Layer 2 services and Layer 2 providing services for Layer 1. Neil raised the possibility of direct communication between layers, which John acknowledged could be messy but was used in some protocols to allow for flexible interaction between different layers.

Technical Architecture Diagram Discussion:

The group discussed the layers of a technical architecture diagram, with John and Neil initially disagreeing about the placement of the transport layer. Drummond suggested referring to the technology architect's diagrams for clarification, which led to a better understanding of the stack's structure. They agreed that the transport layer could be considered part of layer 1 in their context, encompassing TCP/IP and other protocols. Drummond mentioned he was working on finalizing the technical architecture specification, which had been an ongoing issue for the past two years.

Network Layer Diagram Placement Discussion:

The group discussed the placement of network plumbing and communication layers in a diagram, with Drummond and Neil agreeing that these should be at the bottom. John and Neil debated the relationship between different layers, with John suggesting that trust applications might use services from lower layers. Sankarshan raised questions about the structure of the diagram, and Neil proposed that some elements might be "layer 2.5." The group agreed that there might be a need for further discussion on the correct placement of different components in the diagram.

Trust Spanning Protocol Hourglass Model:

The group discussed the concept of the trust spanning protocol as an hourglass-shaped element with a narrow waist, representing a common protocol that can handle secure communications across multiple layers. While they agreed on the basic shape and concept, there was debate about the exact content and number of layers, with Neil suggesting it could be visualized as a pipe carrying different types of communication channels. The discussion concluded that the diagram should be seen as a logical model rather than a precise technical specification, and that different implementations could select and use various Trust over IP elements based on their specific needs.