"The transport layer should be generic": why OpenVTC added TSP
Modeling agent messages across ten-node relay networks pushed OpenVTC to adopt the Trust Spanning Protocol and to restructure its stack so the transport question stays routine. Glenn Gore walks through the decision, and DIDComm's Sam Curren explains the design.
When the OpenVTC project modeled how its agent messages would behave across the relay networks it is building for its Linux Foundation work, the team needed to solve the problem of messages that kept growing in size. In the project's modeling, a 100kB message grows to roughly 400kB after two relays, approaches a tenfold increase by three hops, and ends up somewhere between 20 and 40 megabytes across the ten hops those networks realistically involve. "This was a genuine technical constraint, message size compounding with every hop in a multi-relay network," says Glenn Gore, whose team at Affinidi contributes the bulk of the project's code, "and the move to TSP was the design decision that followed from identifying and modelling it."
The solution they chose is TSP, the Trust Spanning Protocol, adopted this month as the transport for messages crossing those many-hop networks. DIDComm, the identity world's established secure-messaging protocol, stays in the stack, and the two now run side by side and share a web socket channel where useful.
The decision expressed more than just a transport choice. "Our broader position is that the transport layer should be generic," Gore says, "and that is the role Trust Task plays." A trust task, in the Trust over IP stack's vocabulary, sits one layer above messaging as a defined piece of work that two parties carry out together, rotating a key, for example, or verifying an action. Because the definition never mentions a transport, the same task runs the same way over whichever protocol carries it. The term dates to the stack's original design, coined around 2021 by Daniel Hardman, then chief architect at Evernym, for the model's third layer.
What Gore's team built, by generalizing how DIDComm operates on top of a transport, is the working set of trust task protocols that verifiable trust agents need in order to interoperate, published at trusttasks.org, where the registry documents three transport bindings so far: TSP, HTTPS/REST, and DIDComm v2.1. None of it is a standard yet, by design. The ToIP / DIF Decentralized Trust Graph Working Group plans to begin drafting the DTG Core Trust Task Protocols V1.0 specification this fall, once the implementations have banked the experience worth writing down, says Drummond Reed, one of the group's co-chairs. Enabling TSP for a deployment is a matter of updating a DID document with a TSP service endpoint.
To see why the message-size math comes out the way it does, it helps to start with what DIDComm was built to protect.
Why a message grows at every hop
DIDComm delivers messages through mediators and relays by wrapping the original message in successive forward envelopes, one per hop, onion style. Each intermediary decrypts only its own envelope, learns only its next instruction, and passes the rest along untouched. No mediator can read the message it carries or see the full path it travels, and the specification treats that property as central to privacy-preserving routing.
Sam Curren, who led the development and publication of the DIDComm v2 specification at the Decentralized Identity Foundation, where he co-chairs the DIDComm Working Group, explains. "Messages do grow for each hop," he says. When v2 was written, the focus was on an understandable envelope structure, simplicity, and solving the most common cases, and DIDComm was never aimed at large messages. "Given the information hiding about routing, I believe the tradeoffs were worth it."
The most common routing case, Curren says, is a single mediator ending on a mobile app, which extends comfortably to three or four hops. Past roughly five, there is no limit in the specification, but there is a practical one, because each additional envelope re-wraps everything before it and the size compounds.
The thing is, OpenVTC's target topology is past that range, and the cost lands on users. Much of the project's traffic runs over mobile networks, where, as Gore puts it, "large messages cost users time, battery and data allowance, and not every region has equal access to high-speed connectivity."
TSP reaches the same privacy goal by using a fixed set of nested channels, an outer connection to an intermediary, a routing channel that gives each intermediary only its next destination, and an inner end-to-end channel, and that layering stays constant however many hops the path contains. No single intermediary ever sees the full path, and the message body is not re-wrapped along the way. In Gore's example, a 100kB message arrives at roughly 120kB after ten hops.
While DIDComm's per-hop envelope favors simplicity and information hiding across the few-hop paths where nearly all of its deployments live, TSP's constant layering favors longer paths.
What running both takes
Not much, by Gore's account. The Affinidi messaging mediator carries DIDComm and TSP side by side, a bridge lets DIDComm messages ride TSP for the final hop, and the SDK converts between them, so neither developers nor end users need to know which protocol carries a given message. TSP is opt-in per deployment, and existing DIDComm deployments, including ecosystems like Credo, continue unchanged. Running the two protocols together in the same production stack is, in Gore's view, the first of its kind anywhere.
The two protocols are at different points in their lives. DIDComm is the more mature of the two, with the longer track record and the easier deployment story. TSP's specification, developed by a ToIP task force launched in January 2023, reached its first implementers draft in April 2024 and is still pre-1.0; OpenVTC builds against the latest published draft and tests interoperability against the TSP reference SDK. Arriving after DIDComm v2 was finalized also let TSP draw on cryptographic approaches that matured in the interval.
Where DIDComm goes from here
The boundary between the two protocols is set to move, because DIDComm is evolving toward the same class of problem. Curren describes two primary goals for a DIDComm v3: a switch to CBOR, a binary encoding, with CESR considered and rejected, and the introduction of cryptographic sessions that allow ratcheting mechanisms and the adoption of future cryptography without a spec update.
The encoding change bears directly on message growth, since binary encoding reduces each additional envelope's contribution to only its own information. With CBOR, Curren says, twenty or so hops present no issue. The work is visible in DIF's public records, where the working group has been weighing whether binary encoding arrives as an option in a v2.2 or as the default in a v3, alongside post-quantum key encapsulation.
Gore, for his part: "If a DIDComm v3 specification is published, we would support that too." When transports are interchangeable bindings under a task specification, it's just a configuration decision for a deployment rather than a migration for an ecosystem. The task-handling code does not change.
What to look for next
What happens next will play out in public. A spanning layer ultimately asks the world to adopt it, so the thing to watch is where TSP implementations appear next beyond OpenVTC and Affinidi's own deployments. Nearer in, the kernel work heads toward the Linux Plumbers Conference in October with the new transport underneath it. And the specification is still young, with the audit history that production trust infrastructure earns with age still ahead of it.
