Tupelo as it relates to IPLD and IPFS

If you are reading this before 31 August 2019, Tupelo is running a contest where you can win cash for building apps. It is a fun way to explore more of the Tupelo platform. Read more about it here: https://www.quorumcontrol.com/blog/buildthefuture

Under the hood Tupelo uses IPLD, libp2p and it also makes use of bitswap.

The Interplanetary Linked Data (IPLD) specification underlies The Interplanetary File System (IPFS) and is incredibly powerful. In a lot of ways it is what allows Tupelo to be so performant and easy to use.

This post describes how Tupelo relates to IPLD and assumes some familiarity with the protocols. If you are coming here with fresh eyes, I suggest taking a look at the IPLD page.

At the highest level, IPLD is a way to link data in such a way that the links are what is called “content addressable.” In practice, that means that the link to a piece of data includes a hash of the data and so you can always be sure of the data you receive as a result of following a link. This turns out to be a powerful concept, especially in the decentralized world. It allows you to use relatively untrusted storage because you can always be sure of the links coming back.

IPFS is a data sharing and routing layer on top of IPLD. IPFS has added some cool stuff over the years including the Interplanetary Naming System (IPNS) which allows you to have what feels like a mutable link by letting a public key point at a content addressable link. This means you can be sure that someone bearing the private key has created that mapping.

It turns out that these two primitives are almost enough to create an extremely powerful DLT system.

Tupelo fills in the remaining details.

The most basic and powerful thing Tupelo does is make it so that when a user says something, they have to stick to it. Other DLT projects tend to refer to this as the double spend problem. There is nothing in the IPNS/IPFS/IPLD stack that prevents a user from telling one person their IPNS points here and another user their IPNS points there. In fact, the protocol is eventually consistent and therefore one cannot build payments or ownership directly. Tupelo adds in a DLT layer to make sure that the whole world knows the state of a certain object. We call these objects ChainTrees and there is a lot more detail on our documentation site. At a high level, they are simply IPLD trees with a tree for current state and a tree implemented as a blockchain for past updates.

The next thing Tupelo does is enforce state-machine rules. This means that a user can’t do 100% arbitrary things with their data. Instead, they need to follow some rules in order to change the state of their ChainTree from one to another. There is a description of these Transactions in our whitepaper, but they are general-purpose and allow for powerful app building with arbitrary data.

Preventing double-states of ChainTrees (IPLD Trees) and enforcing transactions allows for both token exchange and object ownership on top of the IPLD/IPFS primitives, while allowing data exchange and availability to happen in the IPFS-standard way.

If you are coming from the IPLD stack, you can think of Tupelo as a trusted pointer into the IPLD merkle forest, both making sure that the content you are seeing is the content shown to the world and making sure the data has followed the rules around payments and ownership.

Our newest SDK, based on javascript and Wasm, really illustrates how easy working with Tupelo, libp2p, and IPLD can be: https://github.com/QuorumControl/tupelo-wasm-sdk

If you are reading this before 31 August 2019, Tupelo is running a contest where you can win cash for building apps. It is a fun way to explore more of the Tupelo platform. Read more about it here: https://www.quorumcontrol.com/blog/buildthefuture