Alternative IPLD Content Layer Design

Protocol Content Layer
1

The current implementation of the content layer uses a set of Ceramic Tile Documents. There is a single, deterministic root Tile document for each pair of user and parcel.

This design has had multiple downsides:

  • There is uncertainty around Tile document schemas and Ceramic data models. ComposeDB seems to be the priority
  • Links between Tile documents have no standard and poor tooling
  • The current MediaGallery schema would not scale to very large gallery sizes

This begs the question, what is the main value Ceramic is providing?

  • Mutable, off-chain content
  • Content controlled by DIDs

IPLD as an Alternative

The following is a potential alternative design for the content layer that may resolve these downsides, while continuing to use Ceramic for the core advantages it provides.

Instead of using a set of linked Tile documents, we can use just a single root Tile document for each user and parcel. This document would have a single link to an IPLD CID.

{
	"/": "<CID>"
}

This CID would be the immutable root of the DAG of content attached to a parcel. The remaining content can be defined using IPLD Schemas instead of Ceramic Tile document schemas and browsed entirely using IPLD tooling instead of Ceramic. This could have the following advantages:

  • IPLD is much more mature than Ceramic and does not have much uncertainty
  • Links in IPLD are a core concept and have great tooling
  • Pinning of IPLD DAGs has much better support than pinning Ceramic streams
  • Any IPLD codec could be used (JSON, CBOR, etc)
  • Various storage solutions could be used (IPFS, Filecoin, CARs, etc)

Here are some potential limitations:

  • IPLD schemas do not have as much tooling or familiarity as JSON schemas
  • Composability with other applications would come from sharing IPLD schemas and not Ceramic data models. However, the current data models approach will probably be superseded by ComposeDB
  • Querying IPLD data may not be as powerful as ComposeDB

Another modification could be to use the proposed DIDPublish StreamType instead of a Tile document.

2 Likes
2

The following is an example of how the media gallery could be defined in IPLD schema

type MediaType enum {
	| 3DModel
	| ImageObject
	| VideoObject
	| AudioObject
}

type MediaObject struct {
  type MediaType
  name String
  content Link
  contentSize Integer
  encodingFormat String
  encoding [&MediaObject]
}

type MediaGallery [&MediaObject]
1 Like
3

A new repo that is experimenting with this pattern is here: GitHub - Geo-Web-Project/js-geo-web

4

This is the pattern that Geoweb.land shipped with.