IPLD Schemas Feature Summary

Constructs for Describing Common Data Forms

IPLD Schemas present basics that are well-understood in many programming ecosystems (sum types, product types, some specific recursive types):

Typed maps


Typed lists


Typedef'd primitives

type Foo int


type FooBar struct {
  f Foo
  b Bar

Discriminated unions (several styles matching those commonly found in the wild)

type union FooOrBar {
  Foo "f"
  Bar "b"
} representation keyed


type FBB enum {
  | "Foo"
  | "Bar"
  | "Baz"

A simple syntax for 'maybe' data elements

type Foo struct {
  f nullable Bar

type Bar [nullable Foo]

A clear syntax for non-required fields

type Foo struct {
  f optional Bar

Hooks for transparently transforming data with programmatic logic

advanced ROT13
type EncryptedString string representation advanced ROT13

Mapped to the Data Model

All of this maps over the IPLD Data Model:

There are some other IPLD features you may want to know about which can go even further than Schemas: "Advanced Data Layouts (ADLs)" define that can act as already-familiar data kinds such as Maps or Lists or Bytes (byte arrays), while using a fully pluggable system to transform the content into other forms for representation. A common use of such a feature is splitting data into fully separate chunks for storage, allowing:

...however, see docs chapter for ADLs for more details about these. ADLs work well together with Schemas, but are considered a different portion of the IPLD stack.

All the same tools that work over the IPLD Data Model also work atop Schemas:

All of the generic IPLD algorithms can work over a Schema node in exactly the same way as over nodes in the plain Data Model. This allows novel behaviors such as pathing through a Struct by field names even if the Struct representation is a list.