Skip to main content

Design principles provide guidance to the designers of a product, service, or system. This lets us take advantage of lessons learned from previous designs.

By extension, ToIP design principles help us inform, guide, and constrain the design of the ToIP stack as an Internet-scale architecture for decentralized digital trust.

Our main goal with these principles is to help evaluate ToIP deliverables. We can then assess if the deliverables are consistent both in spirit and substance.

A summary of the design principles is below. The design principles document has more complete descriptions.

Computer Network Architecture (“Dry Code”) Principles

#1: The End-to-End Principle

For maximum utility and adaptability, the best place to put intelligence and processing is at the endpoints of a network and not in the communications subsystems (routers, gateways, etc.) that connect those endpoints.

#2: Connectivity Is Its Own Reward

If connectivity is held up as the highest goal—as it was with the design of the Internet—then every design decision about the ToIP stack will be made in favor of interoperability.

#3: The Hourglass Model

In a layered protocol architecture, the most successful design takes an hourglass shape where a single “spanning layer” in the middle connects a family of higher-level application-facing protocols with a family of lower-level transport protocols.

#4: Decentralization by Design and Default

To be trusted by all parties, a global network cannot favor any single centralized service or authority; it must allow functionality and authority to be distributed as widely as possible.

#5: Cryptographic Verifiability

As part of digital trust, messages and data structures exchanged between parties should be verifiable as authentic using standard cryptographic algorithms and protocols.

#6: Confidentiality by Design and Default

Parties communicating over ToIP protocols should expect communications to be secure, private, and confidential without any special thought or action required on their part.

#7: Keys at the Edge

To maximize security, privacy, and confidentiality, cryptographic private keys should be stored at the edges of the network, not on intermediate nodes.

Human Network Architecture (“Wet Code”) Principles

#8: Trust is Human

Trust is a psychological belief held by people who individually or collectively need to act on that belief in order to make risk decisions.

#9: Trust is Relational

Trust is a relationship between a subject—a person or a group of people—and an object—which can be anything about which the subject needs to make a trust decision.

#10: Trust is Directional

While many trust relationships are bi-directional, each direction is independent. In other words, if A trusts B, it does not mean B trusts A.

#11: Trust is Contextual

A trust relationship exists in a specific context, and it should not be assumed outside of that context. In other words, if A trusts B in context X, it does not mean A trusts B in context Y.

#12: Trust has Limits

In the human perception of trust, every trust decision has a trigger point along a continuum that ends at a limit point. The limit point where risk exceeds reward.

#13: Trust can be Transitive

If a first party trusts a second party who in turn trusts a third party in the same context, then the first party can have some degree of trust in the third party in that context.

#14: Trust and Technology have a Reciprocal Relationship

Technology can only help humans build trust if humans trust the technology.

Overall Principles

#15: Design for Ethical Values

The ToIP Stack has a strong ethical dimension. Design it with a commitment to ethical values.

#16: Design for Simplicity

The simpler the design of a protocol, the more likely it is to be successful.

#17: Design for Constant Change

The only constant on the Internet is change. Design for it.