Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Theory

This document explains the theory that Telltale builds on. It is organized by audience relevance. Developer-facing protocol concepts come first. Proof-oriented topics come last.

Foundations

Session types describe communication protocols as types. They let the type system check message order, branch structure, and termination behavior. Telltale uses them as the structure layer of its protocol model.

Why Session Types

Distributed programs fail when participants disagree about message order or branch choice. Ordinary data types do not describe those communication obligations. Session types add that missing protocol structure.

With session types, communication mistakes become type errors rather than runtime surprises. This is the main reason they matter in practice. They let developers state protocol shape directly and check it mechanically.

Binary Session Types

Binary session types describe one conversation between two parties. The core actions are send, receive, choice, and termination.

SyntaxMeaning
!T.Ssend a value of type T, then continue as S
?T.Sreceive a value of type T, then continue as S
⊕{...}choose one labeled branch
&{...}accept one labeled branch
endterminate the session

Binary types also rely on duality. If one side sends, the other side must receive. If one side chooses, the other side must branch on that choice.

Client: !Request.?Response.end
Server: ?Request.!Response.end

This pair is dual. The client sends then receives. The server receives then sends.

Multiparty Session Types

Multiparty session types extend the same idea to three or more roles. They separate the protocol into a global view and one local view per participant. This is the core abstraction behind Telltale choreographies.

Global types describe the whole protocol from a neutral perspective. Local types describe only what one role must send and receive. Projection computes those local types from the global type.

Global:
  Alice -> Bob: Request.
  Bob -> Carol: Forward.
  Carol -> Bob: Result.
  Bob -> Alice: Response.
  end

This global type describes the whole conversation. Projection gives Alice a two-step local view, Bob a four-step local view, and Carol a two-step local view.

Projection and Merging

Projection extracts one role-local type from the global type. When a message does not involve the target role, projection skips it. When a message does involve the target role, projection turns it into a local send or receive action.

Branching requires one extra operation called merge. If a participant is not the branch chooser, its projected local view must combine the possible continuations. Merge succeeds only when those continuations remain compatible from that participant’s viewpoint.

Protocol Constraints

Not every syntactically valid protocol is meaningful. Telltale relies on a set of constraints that a protocol must satisfy before projection and execution are well behaved. These are often called well-formedness conditions in the literature.

For global protocols, the main rules are:

  • recursion variables must be bound
  • communication branches must be non-empty
  • a role must not send to itself
  • recursion must pass through communication

For local protocols, the main rules are:

  • the type must be closed
  • recursion must unfold to observable communication or termination

These constraints are developer-facing. They are the rules a protocol must satisfy in order to project cleanly and support the later guarantees.

Recursion

Session types support recursive protocols through fixed points. This is how a protocol expresses repetition or long-running interaction.

μX. Alice -> Bob: Ping. Bob -> Alice: Pong. X

This protocol repeats the same request-response cycle forever. Recursion is valid only when unfolding eventually reaches observable communication.

Subtyping

Subtyping determines when one protocol can replace another. This matters when a component offers a more specific behavior than the caller requires.

In synchronous settings, subtyping follows the usual session-typing variance rules. In asynchronous settings, buffering allows some outputs to move earlier relative to inputs. Telltale implements asynchronous subtyping using the Bravetti et al. POPL 2021 algorithm.

Protocol Guarantees

This section describes the guarantees developers usually care about once a protocol satisfies the foundational constraints. These guarantees are still premise-scoped. They depend on explicit assumptions about execution and delivery.

Coherence

Coherence is the central MPST invariant. It states that the collective local state of the protocol still matches the global protocol state. Without coherence, projection would not give a trustworthy local view.

In Telltale, coherence is tracked per communication edge. Each edge relates the sender state, the receiver state, the relevant buffer contents, and the remaining global structure. This is the invariant that lets local endpoint behavior stay aligned with the choreography.

Preservation

Preservation states that a well-typed and coherent protocol state remains well-typed and coherent after a valid step. A correct protocol execution does not silently fall out of the typing discipline. This is the usual subject-reduction property.

Preservation is mainly a meta-level guarantee. Developers benefit from it because protocol execution stays inside the checked state space once it starts there.

Progress

Progress states that a well-typed protocol can continue unless it has already terminated. A participant does not get stuck waiting for behavior the protocol itself forbids.

This guarantee is premise-scoped. Telltale states those premises explicitly. They include well-typedness, reachability of communication, and fair scheduling.

Deadlock Freedom

Deadlock freedom is the developer-facing consequence of preservation plus progress under the declared premises. A well-typed protocol cannot reach a state where all participants are permanently blocked by protocol structure alone.

This guarantee does not ignore the environment. If the delivery model or scheduler violates the stated premises, the theorem does not apply. That separation is part of Telltale’s premise discipline.

Harmony

Harmony is a compilation-correctness property rather than a direct developer-facing liveness property. It states that global protocol evolution and projected local evolution stay in correspondence. This is what makes endpoint projection trustworthy.

project(step(G)) = localStep(project(G))

This equation says that stepping the choreography and then projecting gives the same result as projecting first and stepping locally. Developers benefit indirectly because generated endpoint behavior stays aligned with the choreography they wrote.

Operational Extensions

This section covers theory that matters once the protocol interacts with realistic runtime concerns. These topics are still user-relevant, but they are more specialized than the core session-typing model.

Delegation and Reconfiguration

Delegation transfers a session endpoint from one participant to another. This allows the active participant set to change during execution. It is the main extension beyond fixed-role MPST.

Delegation is safe only when the transferred endpoint state matches what the receiver can legally assume. Telltale captures those conditions with DelegationWF. The important developer-facing point is that endpoint transfer is governed by explicit protocol-side conditions, not by ambient host authority.

Delivery Models

Asynchronous session reasoning depends on the delivery model. Different delivery models allow different message orderings and therefore support different theorems.

Telltale parameterizes theorems over DeliveryModel. Important examples are FIFO, causal, and lossy delivery. This keeps the theorem shape stable while making delivery assumptions explicit.

Host-Runtime Ownership Contract

The Rust runtime adds an ownership contract around delegation, reconfiguration, and host-visible mutation. This layer uses concepts such as current owner capability, ownership generation, transfer receipts, rollback, and stale-owner rejection. It is an implementation hardening layer.

This runtime contract is aligned with theory-side predicates such as DelegationWF. It should not be read as a separate theorem family. It is the host/runtime realization of the protocol boundaries that the theory already identifies.

Verification Topics

This section is mainly for readers of the Lean formalization. These concepts matter for proofs and mechanization. They are not the first concepts a protocol author usually needs.

Bisimulation

Bisimulation compares two types by observable behavior rather than by literal syntax. It is useful when recursive types differ syntactically but unfold to the same behavior. This is a proof and equivalence technique.

In practice, bisimulation matters most when reasoning about proof identities, recursive encodings, and normalization arguments. It is less central for day-to-day protocol authoring.

De Bruijn Indices

The Lean formalization uses de Bruijn indices in foundational proof layers. This avoids name-capture problems during substitution and recursion reasoning. Rust-facing protocol APIs keep named recursion variables for usability.

If you are reading the proof code, expect de Bruijn forms in the foundational libraries. If you are writing protocols, this detail is mostly invisible.

Lean Formalization

The Lean formalization proves the core metatheory behind projection and protocol execution. Important theorem families include coherence, preservation, progress, and harmony. Current library structure and metrics are tracked in Lean Verification Code Map.

At a high level, SessionTypes and SessionCoTypes cover syntax and equivalence. Choreography covers projection and harmony. Protocol covers coherence and typing. Runtime covers the protocol-machine model and runtime correctness surfaces.

Theory in Telltale

Telltale implements the theory across Rust and Lean. The Rust crates provide executable data types and algorithms. The Lean libraries provide mechanized proofs and proof-facing models.

On the Rust side, telltale-types defines GlobalType and LocalTypeR. telltale-theory implements projection, merge, duality, and subtyping. The runtime and machine layers then realize those structures operationally.

On the Lean side, the formalization provides the theorem libraries that justify those structures. See Lean Verification for the proof pipeline and source layout. See Introduction for the system-level overview.

Conservation and Session Structure

Session types are Telltale’s concrete realization of structure conservation. The protocol type fixes the allowed interaction shape. Local behavior must remain a valid projection of that shape.

The other conserved properties extend the guarantee surface beyond session structure alone. Evidence governs witnesses and attestations. Authority governs exclusive ownership. Identity governs stable references. Commitment governs outstanding effects. Premise governs environmental assumptions.

In the runtime and Lean model, these properties are carried by explicit typed objects. They are not left as ambient host assumptions. See Conservation Framework for the full conservation model.

Further Reading

For deeper study of session type theory:

Within this documentation: