What term should we use for a VID-to-VID graph edge?

[talltree]

On last week’s TSPTF call, we had a long discussion about which term would best describe a particular concept at the very heart of our Trust Spanning Protocol architecture. The irony about that discussion is that, as co-chair of the ToIP Concepts and Terminology WG (CTWG), I am constantly reminded that any discussion around terminology is always best resolved by:

1. First reaching agreement on the essential criteria by which the members of a terms community can distinguish the concept for which they are trying to decide on a term.
2. Then, once there is agreement on the criteria that defines the concept, test different terms to see which one seems to best identify that set of criteria.

In our case, I believe we have 100% agreement on the concept we are trying to identify. To use the analogy of a mathematical graph model, the concept we are trying to identify is the graph edge that connects two graph nodes identified by VIDs. In short, it is a "VID-to-VID graph edge". (2024-01030 update: @SmithSamuelM points out that strictly speaking it is a directed graph edge.)

Obviously "VID-to-VID graph edge" is too long and technical even for a technical spec like ours. So the question is simply this: what English language word or words works best to refer to a VID-to-VID graph edge?

The three English words we discussed on last week’s call were:

• relationship
• connection
• channel

Each one of these words had its advocates and its detractors; no consensus was reached.

Ironically, this is where another CTWG maxim applies: whenever an existing term is too general or “overloaded” to adequately identify a concept, it is better to either: a) specialize the term by adding a qualifying word or phase, or b) make up a new term that can be used to identify the concept exclusively.

Since “relationship”, “connection”, and “channel” are all terms that can be used to identify the concept of a “graph edge”, the obvious candidate for a qualifier is “VID”. Adding that qualifier yields these three candidates.

• VID relationship
• VID connection
• VID channel

Of those three, the one that jumps out to me personally is VID channel. Because a VID-to-VID graph edge in the TSP becomes a very specific (and powerful) new kind of communications channel, "VID channel" feels concrete and precise.

To illustrate this, I’ll apply another tool we use in the CTWG: trying out candidate terms in multiple examples of real-world usage to see how well they work. Putting this to work, here are examples of the above three terms, each used in the same set of sentences:

1. Alice and Bob form a real world trust relationship by using an OOBI to set up their first VID relationship. Then they decide they want to have several other VID relationships: one for discussing work, one for their mutual love of rugby, and one for planning a trip together.
2. Alice and Bob form a real world trust relationship by using an OOBI to set up their first VID connection. Then they decide they want to have several other VID connections: one for discussing work, one for their mutual love of rugby, and one for planning a trip together.
3. Alice and Bob form a real world trust relationship by using an OOBI to set up their first VID channel. Then they decide they want to have several other VID channels: one for discussing work, one for their mutual love of rugby, and one for planning a trip together.

To my ear, “VID channel” works the best. It is the least prone to confusion with real-world trust relationships or connections.

However, when it comes to deciding which terms work best to identify a concept, there is no “right” or “wrong”, only rough consensus across the terms community. So…

…what are your thoughts?

[sankarshanmukhopadhyay]

Since “relationship”, “connection”, and “channel” are all terms that can be used to identify the concept of a “graph edge”, the obvious candidate for a qualifier is “VID”. Adding that qualifier yields these three candidates.

• VID relationship
• VID connection
• VID channel

If the edge is intended to represent a connection that indicates a communication (passing of messages), then using "channel" is perhaps most appropriate. Unless the edge is intended to merely indicate that two VIDs are connected in a peer-to-peer mode of relationship.

[kthomas-digicat]

+1 VID channel

I agree with @sankarshanmukhopadhyay and @talltree, as a user of these technologies, I would find it easier to describe a 'VID channel' as it somehow implies flow of data between two connected entities. I can't say the same of other two terms.

[edeykholt]

I also prefer the term channel. But regardless of the name chosen, the definition of it quickly becomes important, which includes at least a channel's properties and relationships (together, its structure), and if you want to think and impose object-orientation, also its behaviors. (Functional thinking might lead to better implementations in the case of TSP.) When we get into any of those details it is helpful to have different subtypes of channel. In TSP, all types of channels have the characteristic that a VID owner can establish a directed channel (over which it can send a directed message) from a VID for which it has the private key(s), to a receiver VID. Sometimes the channel concept is also bi-directional. A channel can be direct VID-to-VID, or indirect and routed through intermediaries. A channel can be a sub-channel of another one that provides it context.

I have a UML class model of the above, which I haven't shared broadly until now because I thought it would be disruptive to the short-term goal of getting out an implementer's draft. Perhaps we should wait to address any of the terminology changes until after the draft is published? Anyway, attached is a snapshot of the diagram, which is evolving.

From what I understand, an OOBI is not a channel, but is essentially providing "this is how you reach me" information, which isn't a channel, but in its simple form includes a resolved VID that includes the inviter's (i.e., receiver's) VID, public key, and service endpoint. When an intermediary is involved, the OOBI takes on a different shape.

[2byrds]

For anyone wanting to read more about OOBIs, this is a good intro to OOBIs https://weboftrust.github.io/WOT-terms/docs/glossary/out-of-band-introduction?level=2
And I agree that in terms of your diagram the OOBI aids the VID resolution. It is a discovery mechanism that yields enough information for the resolver to begin the verification process.
So I think @talltree candidate term examples are worded correctly. @edeykholt you are right that the OOBI isn't the VID channel, but it's the starting point for establishing the VID channel.
The candidate term VID channel sounds good to me.

[SmithSamuelM]

Vid-to-Vid edges are directional i.e. they are directed edges. So that is an essential feature that is not so far captured.

My problem with "channel" is that the TSP itself is a tunneling protocol, it tunnels through other channels. So everytime I describe it technically I have to qualify which type of channel, VID channel versus say TCP channel or HTTP channel. Whereas relationship is not used by either TCP or HTTP or UDP or any of the other channels that TSP is tunneled through. So based on the criteria of "whenever an existing term is too general or “overloaded” to adequately identify a concept," I consider Channel in the context of communication protocols to be the most overloaded of the three terms. The second most overloaded is "connection" since the term connection is also used for TCP connections HTTP connections etc. The only term that is not overloaded is relationship and that is one of the main reasons I used it for the SPAC whitepaper.

Now if you are looking at the TSP protocol from the top down you may not ever care about the channels it tunnels through so you don't see the overload. Still, as an implementer who is concerned about privacy, I have to look at the TSP from the bottom up because the salient feature of the TSP is that it enables correlation-minimizing tunneling over preexisting public channels of any type (oh, I used the word channel, which one did I mean? =)).

As a historical note. the "CEA 852-C-2014 (ANSI) Tunneling Device Area Network Protocols Over Internet Protocol Channels" and the "CEA 852.1-A-2014 (ANSI) Enhanced Protocol For Tunneling Component Network Protocols Over Internet Protocol Channels" specifications, for which I was one of the WG chairs, is all about tunneling other protocols over IP channels. Essentially analogous to the TSP protocol. In writing the specification, we were constantly tripping over the fact that we had two types of channels. The first was IP channels of all kinds, and the second was 852 tunneled channels of all kinds of non-IP protocols. So we had to qualify which type of channel throughout the specs. I was trying to avoid that by using a different term, not channel, anything but channel =).

But thats just me.

BTW, somewhat ironically, the 852A and 852.1 protocols coined the term DID for Device ID, which gets a little meta if we start talking about using TSP for IoT applications; which DID do we mean? Is a DID a VID or the other kind of DID? The world of IoT specifications uses DID as short for Device Identifier. For example, the trusted computing group's DICE (Device Identifier Composition Engine) family of specifications, which, by the way, are types of SCIDs, which means they could be VIDs, so we now have two types of VID DIDs, the IoT type of VID-DID and the w3c type of VID-DID. Oh, the overload! =)

[2byrds]

Interesting! Different contexts does make a difference about what is overloaded. VID relationship sounds good and being consistent with the SPAC white-paper is a benefit.

[wenjing]

Interesting indeed. I also think VID relationship sounds good. As an author of the spec, I have a selfish reason to reduce editorial work if possible. In addition, I also feel the term "relationship" may be somewhat more fitting than alternatives. The mechanisms may change or diverge but the relationship stays.

[talltree]

As I've cooked on the replies in this thread—and at the same time been deep in discussions in the ToIP Concepts and Terminology WG about the ToIP Glossary and the need to use terms consistently across ToIP specifications—I developed this "mental model" proposing three "levels" at which we need to talk about what in the Design Principles for the ToIP Stack we called "trust relationships":

1. The human level (where the relationships are between parties are people and organizations).
2. The machine level (where the relationships are between machines/devices).
3. The logical level (where the relationships are between VIDs).

[guru-barbes]

What about "line", as in opening a "line of communication"?

[SmithSamuelM]

One of the challenges with terminology is that there are not enough terms to go around. Also most terms suffer from polysemy.
https://en.wikipedia.org/wiki/Polysemy
What that means is that a given term will have many closely related but not identical meanings. But we can use that to our advantage. Often, in complex systems, the same term shows up at multiple levels in the system. For some terms, it's unavoidable because there just are not enough terms. But when there is sufficient contextual separation between the levels (i.e. the contexts in which the terms are used) then they terms are not overloaded. When those levels are collapsed then one uses a qualifier. So its actually easy to manage give sufficient distance between contexts (non-overlap or small overlap). The real difficult is when the context overlap a lot then we have severe overload and we are always tripping over each other having to qualify. So we want to avoid that like the plague. A low level tunneling protocol like the TSP strongly overlaps all other low level protocols that it tunnels through to reusing polysemous terms from those other protocols will be problematic. But if we use a polysemous term from other layers in the stack that contextual rarely overlap. Like for example, human level relationships, versus tsp level, versus machine level gain the advantage that we glue toghether the layers with a unifying concept. A level have a type of relationship that is meaninful at the layer and is evocative indeed may be dependent on relationships at other levels. Since we rarely talk about those other types in the same context we do not have overload but we benefit from a vertical semantic that connects the layers. So when we talk about a pair of cryptonymous identifiers have a relationship at the TSP layer, it maps nicely to the human controllers of those identifiers at the human level. The fact that a given human may use multiple cryptonymous identifiers in different contexts with the same other person means that the higher level relationship is an aggregate of lower level relationships is a unifying concept not a collision or an overload.

Think of Maslows hierarchy of needs. We have a hierarchy of relationships. Polysemy arises because as humans we want to have a contextually unifying concept so we use the same term with subtle shifts of meaning to correspond to shifts of context. If we used different terms for each shift of context it would be highly confusing. So the metric to use is the separation of contexts. If the contexts are overlapping when describing the system then we have overload and have to qualify related but different meanings. But when the contexts are sparated, i.e. when describing the system only one of the related meanings applies then we want to use the polysemous term because now we unify our understanding of the related but non-overlapping contexts. One of the metrics for polysemi are similarity measures which measure the degree of overlap between two different contexts.

And a pair of VIDs is a simple abstraction as the simplest possible relationshp that maps to the layers above it as aggregates of atomic relatioships. How a relationship is formed can be totally out of band to the TSP.

The fact that TSP has a sub protocol called a relationship formation protocol, only makes sense when you already have a relationship to begin with.

How any vids actually communicate is complex and is no longer an abstraction. So, calling a Pair of VIDs a channel is modeling the wrong thing. It overloading communications channels in a context that is all about tunneling through communications channels with something that is not in itself a communication channel but an abstraction that must pre-exist in order to instantiate a communication channel. To restate TSP assumes that there exisst two identifiers that have established a relationship between them out-of-band to the protocol. The abstraction says, here are two identifiers vidA and vidB, that represent pseudonomously parties A and B, whose parties may not be named.When party A want to send information to Party B then use VidA as the source and VidB as the destitnation. This establishes a direction. Anything more than that is in addition to that relationship. It may be attached to the relationship but it is not the relationship. We can know use the VIDs from that relationship as universally unique identifiers that allow the lookup of that additional information, be it resolving key state for signing, verifying, encryption, decryption or for looking up addressing and routing information, nesting, wrapping tunneling for a given instance of a communiction that requires additional setup and configuration etc etc. This is just an edge and that edge is inherently allowed to be ephemeral. It may disappear after the communication because we allow that edge to be totally asynchrounous and it may be a one time edge and the next time A wants to talk to B, A may choose to use the same relationship between vidA and vidB and the same direction but the edge details are completely different. This is the essence of a correlation-minimizing protocol.

To clarify, once a relationship (vidA, vidB, direction) is established out of band where those Vids provide a way to resolve or look up or access the supporting infrastructure that enables lookup of key state, as well as the supporting infractructure for actually tunneling a message such as the actual details of communication which transport channel connections addresses. All of that supporting infrastucture must be setup ahead of time out of band to TSP. But now given that initial setup, everything after that, including and changes to the supporting infrastructure can be accomplished via in-band communications using strong authenticity, confidentiality, and privacy provide by the TSP tunnel. The latter is not a relationship.

Now how many instantiated edges are there between those two identifiers. What properties do those edges have? Do those edges consist of multiple other indirect edges that depend on other relationships being formed out of band. As soon as we start to get specific about the edges we run smack dab into overloaded terms of connection and channel. But if we use relationships for pairs of TSP identifiers, we have clear sailing and no overload. We can talk about the details of TSP as a pure tunnel through other channels, and the identifiers, addresses, channels, and connections that must be formed in order for that tunnel to exist do not overlap the TSP use of relationship because it is not used by those other protocols.

A couple of papers to read on why understanding polysemy matters in IT.

https://scholarsarchive.byu.edu/etd/5572/

https://www.semanticscholar.org/paper/Termediator%3A-early-studies-in-terminological-Richards-Riley/06f16d588957b7dc7900ff0ba613ecc77bf9a3a1

https://dl.acm.org/doi/10.1145/2656434.2656443

https://www.researchgate.net/publication/283883079_Automated_identification_of_terminological_dissonance_in_IT_and_adjacent_fields

[wenjing]

Merriam-Webster

• relationship: the state of being [related] or interrelated; a state of affairs existing between those having [relations] or dealings
• channel: a path along which information (such as data or music) in the form of an electrical signal passes
• connection: a means of communication or transport

Of course I picked the definitions that are closest to common tech usages out of many other usages. I have to say that relationship is quite different from either channel or connection, it is a state vs. a means of communication. What we want to model is a state of affairs, rather than a mechanism that parties happen to employ at a certain moment. So, abstraction is a want; if we want to change the perspective in this space, then it should be difficult, should trigger discussions like this.

[talltree]

@SmithSamuelM and @wenjing: I find your arguments today (between the NA/EU meeting and this thread) for sticking with "relationship" in the spec to be persuasive. In the meeting this morning, I volunteered to draft a Note block in the spec that explains why the spec is using the term "relationship" instead of "connection" or "channel" because I expect many readers will have the same initial reaction as myself and @edeykholt and other TSPTF members, i.e., why we are not using the more common protocol spec terms "connection" and "channel". So an ounce of explanation up front might help prevent a pound of questions downstream.

Here is my revised diagram of the different "levels" of relationship that pertain to the ToIP stack. Please do comment on whether this diagram works as a "mental model" and how it can be improved. (Note that the VID relationship arrows, representing the VID-to-VID directed graph edges, are now directional.)

[JoOnGT]

@SmithSamuelM and @wenjing. I have sympathies with both suggestions, because (as always) we can make both of the terms work for this specification. But I would say that the use of the terms are (as always) defined by the context in which they are expected to be used. My rationalisation is therefore that:

• in the context of a point-2-point communication, a VID relationship is established. Sam's correct that this is probably all we need
• in the context of sending messages over the link defined by a VID relationship, the concept of a connection (or just a "link") and logical sub-links (i.e. channels) may be useful to those we have to communicate the protocol to.

As usual, we should be using terminology that actually makes the protocol easier to consume by those that haven't been through the whole journey. If that means that we need to introduce new terms that aren't strictly necessary, then [if it's useful] we should.

The challenge in the introduction of additional terms is that they may further confuse. So we need to be able to articulate a UML diagram to get this clear. @edeykholt 's picture becomes critical not just for the initial definition, but it's wide consumption.

Previously (payments ecosystems) I've used the term "link" to be a "connection" and "channels" as logical or physically segregated messaging streams. Each of these [links and channels] had status and the controls to manage the actual and target status of them were important to the functionality required at the combined (link) or individual (channel) basis (start, stop, resynch, etc.)

I would also suggest that the temporal nature of the trusted relationship link needs to be articulated. "Sessions" have been used to define a trusted interaction, defined by a specific set of keys etc. If we think a relationship has a timeframe and status, then we need to call this out.

As discussed on the APEA TSP call [31/1/24-1/2/24], we might go ahead with the initial specification only using the relationship term, but the discussion can continue and the "communication version" of the specification may introduce other terms to make the protocol more consumable.

[SmithSamuelM]

After some more thought. I have a suggestion.

Technically, a TSP communication path is a Tunnel. It depends on some other network channel or set of channels. Sso it has no independent existence without the other network channel(s). So to avoid overload, in general when talking about TSP the communications path is a tunnel. A tunnel is a special kind of channel, but when talking about a tunnel you can avoid the overload if you use tunnel as its own thing and the channels being tunneled through as the channels. So for TSP we still have relationships, they are the pair of identifiers that we use to identify one or more TSP tunnels that are attached to that relationship. The relationship is not the tunnel, any more than an identitfier is the thing it identifies ( a url is not the resource the url points). Also there is no reason that a given relationship can't have multiple tunnels, indeed a birectional relationship does not exist, its just shorthand for two unidirectional relationships. The usual case would be that each relationship has only one associated tunnel setup, but we don't want to mandate that.

For example a dynamic tunnel would have a one time setup and then the first use of the tunnel, provides the setup for the next tunnel so each use of a tunnel is one-time and there is a tunnel generating function. This is how jam resistant channels work using either frequency multihop or spread spectrum. Each message you send uses a different frequency channel or each message is spread across a different set of frequencies. One shares a pseudo random sequence between the two parties so they can correlate the messages. So with the TSP tunnel concept we can use VIDs as the endpoints and then form dynamic tunnels and do tunnel hopping as a form of random walk routing. This was contemplated by the relationship formation protocol in the SPAC paper.

We also have various types of TSP tunnels that come from the combinatoric of, the transport channel type, the number and types of indermediaries. the layers of nesting and the function (relationship formation, control, communications), persistence (one-time, ephemeral, time limited, unlimited etc). These all are in addition to a relationship. That means there will need to be another identifier, local to each endpoint that manages all that other information. That local management of information is not part of the TSP protocol.

[talltree]

@SmithSamuelM This all makes perfect sense to me. I had noticed how often "tunnel" was being used in our meeting discussions. I also understand how integral the concept is to TSP architecture.

@wenjing, how do you feel about using the term "tunnel" when we want to talk about how a TSP message travels from ToIP endpoint A to ToIP endpoint B?

@edeykholt, how would the term "tunnel" integrate into your UML diagram?

[edeykholt]

@talltree The term tunnel is good with me and the diagram. Just to make your question to @wenjing more precise IMO: "how a TSP message travels" in your question is perhaps misleading or ambiguous. I believe you mean method or paradigm. The term tunnel is used to talk about the authentic parties (from whom and to whom) a message is destined from one of ToIP endpoint A's VIDs to one of B's. So, a message (or possibly other events) would specify the tunnel it would use. The full how might require bringing in the VID routes and physical channel into the discussion.

[SmithSamuelM]

To summarize, a relationship is an identifier. The identifier is a tuple, either an two-tuple (duple) or a three tuple (triple). The duple form is (source VID, Destination VID). The triple form is (local vid, remote vid, direction).

Tuples of identifiers are themselves valid identifiers. (Think tuple spaces) Identifiers are not the things they identify.

A TSP Tunnel includes all the information needed to set up and instantiate that tunnel. A TSP tunnel may itself be tunneled through by another TSP tunnel. TSP tunnels are, therefore, meta-tunnels.

A relationship identifier may be associated with one or more TSP tunnels. A given tunnel may require multiple relationships for its setup and instantiation.

To reiterate, the elements (source VID, destination VID) of each of the many TSP relationships that may be associated with a Tunnel such as the endpoints and intermediaries at each layer of nesting are used in the Tunnel but are not the Tunnel.

BTW the meta-tunnel property of TSP is what gives it its magic. We tunnel a confidential tunnel through another confidential tunnel which is tunneled through an open channel. The result (magic happens here) is that the inner layer of confidential tunnel becomes a private channel with respect to the open channel. Privacy is an emergent property of double-stacking confidentiality over publicity. Indeed when open (public) channels are used heavily (lots of traffic) the double-stacked confidential tunnel gets herd privacy as a result.

[SmithSamuelM]

@edeykholt > The term tunnel is used to talk about the authentic parties (from whom and to whom) a message is destined from one of ToIP endpoint A's VIDs to one of B's.

This is once again confusing identifier with the thing identifed. The term relationship is referring to a tuple identifier. The term tunnel is referring to the information needed to instantiate a communications path. My proposal is we have both, they are not mutually exclusive. A given tunnel may depend on multiple relationships so it is not the authentic parties, the authentic parties are given by the relationship(s). The tunnel is more than that. We are talking about an information hierarchy.

[SmithSamuelM]

A relationship as a tuple identifier is a type of namespace. A tunnel is the detailed information that contains references to multiple relationships. Think relationship is to a DID like a tunnel is to a did doc.

At least one relationship between two endpoints (parties) must be formed out-of-band to the TSP protocol. Therefore, a relationship can't be a TSP tunnel. This bears repeating. To protect form MITM attacks the first relationships between any two parties will be formed out-of-band to the TSP protocols. So we need a way to talk about those things (called relationships) that are not dependent on Tunnels. Relationships can't be tunnels. Now, once a tunnel is formed, if that tunnel, or a part of a tunnel, is exclusive to a given relationship, one might take a shortcut and label that tunnel with the relationship, but a relationship is a tuplized identifier. Its both identifer and data at the same time, its a special type of namespace. Its an abstraction in one sense and a concretization in another sense. As a whole its an identifier, as parts its data.

Because the TSP protocol is about building meta-tunnels, i.e. tunnels, within tunnels within public communication channels we need a way to identify the relationships between identifers that are used to build those tunnels. A tunnel is not its relationships. Those relationships are themselves identifiers because we use them to look up or map to other information.

We map relationships to the key states of the identifiers in that relatioship. We have two key states, sign/verify keys and en-decrpty keys. We map relationships to network addresses. And most importantly we map relationships to other relationships.

To set up a TSP tunnel with two intermediaries there are multiple relationships involved. So calling a tunnel a relationship is oversimplifying you lose the ability to actually talk about what you are building. Frankly I don't understand why this isn't obvious.

[SmithSamuelM]

One more way of describing this that might help. The concept of a relationship is is rooted in the three properties authenticity, confidentiality, and privacy with respect to communication. The relationship (local vid, remote vid, direction) or equivalently (source vid, destination vid) is essential to those properties. Secure attribution of a communication to a source is essential to authenticity of that communication. We can ascribe the communication to its source. We use digital signatures and signing key states to do this. This source is a "who" a party to that communications. If we can also securely encrypt that communication so that only a securely attributed destination can view it, then we can have secure confidentiality. Confidentiality depends on authenticity, if I can't ensure that the intended party is the only party that can view it, then there is no confidentiality, but then I need to be able to bind the identification of the second party to the asymmetric encryption/decryption keys.. So now I have two parties, two "whos" sender and receiver, source and destination, I have a relationship. I also can send information between those two parties "whos" . That information is the "what". I can't begin to talk about the "how" or even the "what" of the communication before I have the relationship.

Finally, privacy is about protecting the knowledge of the "whos" i.e. the parties to the communication. It's not about protecting the what or even the how. It is how do I protect the relationship, which is simply the tuple (source id, destination id), from being known by any other parties besides those two parties to that relationship? That is the core concept of the TSP protocol. I don't need the TSP if all I care about is protecting the authenticity; I have KERI for that or protecting the confidentiality of the what (I just use a secret box to encrypt the what). But the really, really hard problem is how I protect the privacy of the who, the relationship when those two parties want to communicate over public channels. From a privacy perspective, I don't care about channels or tunnels or connections, I only care about protecting the knowledge of the pairing of two identifiers. Its knowledge of that pairing due to their communication is the essence of privacy. So, the fundamental atomic concept that the TSP starts from is a relationship, and then we build on top of that. Otherwise, we lose sight of "why" we have the TSP in the first place.

So preservation of private, confidential, authentic relationship in spite of commuication ultimately over public channels, means that in TSP we build a tunnel that sits atop other tunnels that depend on multiple confidential, authentic (but not private) relationships, which tunnels atop public channels that depend on yet other authentic (but not confidential or private) relationships.

The fact that it seems that we have already lost sight of the "why" of the TSP is deeply unsettling to me because it only reinforces my apprehensions that by not requiring KERI class security for VIDs, we will undoubtedly sacrifice authenticity, which means we will undoubtedly sacrifice confidentiality, which means we will undoubtedly sacrifice privacy. So we no longer satisfy the original "why" of the TSP. What we have left is some weak notion of interoperability, which we can associate with the word "trust" but in word only.

[edeykholt]

This conversation has been valuable to my understanding of Relationship and especially related concepts. We've settled on continuing with the term relationship in the TSP spec, right? Below is a suggestion for this term:

VID relationship (abbreviated simply as relationship in the context of this spec) is an identifier representing a directed edge between two VIDs. The identifier is represented by a tuple, either a two-tuple (duple) or a three tuple (triple). The duple form is (source VID, Destination VID). The triple form from the perspective of the relationship's local owner is (local vid, remote vid, direction), where direction is an enumeration representing inbound or outbound (for receiving or sending).

With additional qualification, the concept of relationship can be extended to a VID bidirectional relationship, which can be represented by two two-tuples between the same VIDs, or a triple form with the added direction enum value of bidirectional.

Let's work to converge on definitions like the above, and then close this issue.