• 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:
  • Scott Whitmire is working on a project now in which he wants to use TSP.
  • Tahoe Blue is a former director of GLEIF who has been working on registries and protocols for many years.

Daniel Hardman asked if we were going to make regular communications about this activity in order to engage with other communities.

An example of this type of communication is: https://daniel-hardman.medium.com/sentries-confessionals-vaults-and-envelopes-4a58cf4f8a5a

Jo Spencer endorsed this approach and why we should be inclusive rather than exclusive.

Jo Spencer mentioned this Sezoo post about organizational identity: https://www.linkedin.com/feed/update/urn:li:activity:7021248294072827904 

Eric Drury asked what channels should be involved. Drummond Reed replied: 

1. TSPTF itself (such as blog posts we write such as the announcement post)
2. ToIP Communications Committee activities (such as conference panels like the one we will be having at the European Identity Conference in Berlin, May 30-June 2).
3. Articles from individual members (such as the examples from Daniel Hardman).

Wenjing Chu proposed that we plan to do an outbound communication with each major milestone.

There was consensus on the following:

DECISION: We will make a conscious effort to publish and promote regular communications about the progress of the TSPTF in order to engage with other communities, and in particular we will do an outbound communication (such as a ToIP blog post) when we reach each major milestone.

We asked for it and we got it: our new repo. Now we need to decide what we want to do with it.

We discussed the potential issue that currently Discussions and Issues are not currently covered by EasyCLA. So there is the potential for IPR poisoning at those stages.

Judith Fleenor clarified that anything that we take from Discussions (or Issues) and convert into a PR to go into the TSP must be from a ToIP member. She also asked anyone on this call to join as a member.

Andor pointed to this link.

ACTION: Drummond Reed to post an issue asking about any other preliminary configuration steps we need to take for the repo.

What are the first set of discussions we want to start as soon as Discussions is turned on?

Suggestions:

• What feedback/comments/thoughts do we have about the 18 requirements for the Layer 2 trust spanning protocol in the ToIP Technology Architecture V1.0 Specification?
• Sam Smith suggested that it would be good to have a discussion about the academic and theoretical basis for spanning layers and the hourglass model to what extent we want to follow those principles. Scott Whitmire suggested we need to understand why we need the spanning model.
• Is there any requirement worthy of its own discussion thread?
• What forerunner protocols do we wish to review and/or do a "deep dive" into as part of our evaluation? DONE.
• What process do we want to follow to develop our first complete Working Draft? DONE.
• Michael Michael suggested a discussion about whether there can be TSP layer profiles? Here's a link.
• Daniel Hardman suggested a topic about what is OUT of scope — the "negative space". Michael Michael suggested more specifically what is in scope and out of scope as well as a discussion to determine the audience for the TSP specification.

One example of a "forerunner" protocol that we might want to evaluation is Nostr (Notes and Other Stuff Transmitted by Relays). This Forbes article plus Jack Dorsey's blessing has ben generating a lot of buzz for this very simple "non-P2P" protocol.

• Brian Richter summarized that Nostr is very simple: clients and relays, all addresses are public keys, all messages are signed. The idea is to create the simplest protocol possible and then "improve" it with Nostr Implementation Possibilities (NIPs).
• Sam Smith shared that Nostr "makes the same mistake that the Internet CA system made" about security: anyone can sign a message, but with a single key, with no provisioning for key rotation. So Nostr didn't solve the hard problem — it's really not different than PGP.
• mathieu listened to the Nostr podcast that includes Jack Dorsey. He also has used a Nostr client to play with it, and seen the power of "separating the client from the protocol". The other key message (which Jack strongly endorsed) is "microapps".
• Scott Whitmire pointed out that the key rotation issue is directly analogous to the issue of dynamic IP addresses.
• Wenjing Chu mentioned the whole discussion about the difference between "addresses" and "entities". So address translation is a key function of the layer.

APAC:

Eric Drury recommended the following YouTube talk on Nostr:

This 2.25 hour podcast with the founder of Nostr, plus Jack Dorsey, plus the author of a popular Nostr client called Damus is worth the entire listen if you are really interested in the full picture of the Nostr community. (You can also just read the transcript.)

• sankarshan had two observations about Nostr:
  1. How simple the protocol can be — at ToIP we have been talking about it for ages.
  2. It builds on that simple foundation.
• Jo Spencer said that practicality must be a major consideration for us.
• Sankarshan said "simple is good", but then you need to start to ask hard questions about it. We need to find the middle ground, i.e., "as simple as possible but no simpler".
  • It is a good design practice to start from simplicity.
• Drummond Reed said the reason he was fascinated by Nostr is the community that has built up by starting with great simplicity.
• Jo Spencer said that the way to achieve simplicity is by starting with a logical model and then seeing how each additional requirement fits into that logical model.
  • In many cases you can borrow "pieces" from other protocols/technologies that have already solved.
  • Drummond Reed said that a formal method proof of the security of the protocol fits directly with starting with a logical model.
• Jo Spencer "Protocols are always useful, the question is what are they useful for."

Andor produced the graphic below (#1) as a visual flowchart of the typical "IETF process" of developing a new specification. Is this the general process we want to follow? What should happen at each step? What would we want to do differently?

• Note that this discussion has already been started on this topic to continue this asynchronously.
• In the APAC meeting, we took notes on this topic in that discussion.

ACTION: Drummond Reed will produce a second version of Andor's diagram with updates to the labels that correspond to the official names for certain stages according to our ToIP Foundation charter (which is based on our Joint Development Foundation legal roots at the Linux Foundation).

Reminder: Our next pairs of meetings start in 3 weeks:

• February 15
• February 22

ACTION: Drummond Reed to discuss with Wenjing Chu and Darrell O'Donnell whether we can make TSPTF meetings happen for three out of every four weeks (instead of the current two).