Ceramic is a tricky thing to get your head around, thanks in part to the many new terms it uses. I hope to show that not only do you already understand schema, data objects, streamcodes and streams, you’ve probably already used them (in an offline form). 

We’ll use a simple example - a letter mailed through the post. 

Schema is a fancy word for a set of properties. Together, they form data objects. We can think of a letter as a simple data object, consisting of two schema. The first is a schema for the content of the letter itself. This is a very basic example, consisting of a single property (a string of text). To make our data object, we combine this with another schema - the address. Addresses have several properties - who the letter is addressed to, their street and street number, the town or city, the country, and a postal code. When we put these two schema together we create an object that is recognisable as a letter just about anywhere in the world. 

This is a very useful thing. It means we can send letters to anyone and be confident that an overseas postal service and our local post have a shared understanding of what these mean, unlocking a global form of communication. 

At this stage, though, our letter is just sitting on our desk. We also need some instructions explaining what we want to happen next. We don’t need to know the details, all we need to do is set the process in motion by putting a stamp on the envelope and dropping it into a mailbox. In effect what we’ve done is tell the postal service “please take this envelope to the address on the front”. 

Let’s imagine that instead of mailing our letter, we wanted to post the contents online and store them on Ceramic. We need to find an app that uses the Ceramic data network, type in the contents of the letter, and press a button to post it. This is equivalent to dropping your letter into the mailbox; it starts the process of getting the information to where it needs to go. Just like we attached a stamp to say “please deliver this letter”, the app attaches a streamcode to your data that tells Ceramic what needs to happen next. In this case the instructions are “please store this content on the network under my user ID”. 

There is one final important thing. The letter in the example is stamped with a postmark showing where it was sent from, and at what time. This is how a post office confirms that the letter is a legitimate article in their system that needs to be delivered to its destination. The equivalent process on Ceramic is a message signed with your private key, a step which also records the date and time at which you signed it. 

Let’s recap. We have a data object (our letter) which is defined by two sets of properties, or schema: the text of the letter and the address. We have a streamcode, or set of instructions (our stamp), saying what needs to happen with that data object, and we have a signature confirming when and where it came from (the postmark). In Ceramic terms, we now have a stream. 

In plain English, the stream for my letter would be something along the lines of:

At 1:00pm UTC on Wednesday, August 24th, the Melbourne post office processed a letter sent by Adam and addressed to Alice. It read “Dear Alice. gm. Sincerely, Adam.”

Let’s imagine Alice is a dedicated penpal who stores every letter I’ve ever written to her, along with the envelopes showing when and where they came from. I, or anyone else, could visit her at any time, ask to see all of the letters, and have access to a complete history of our correspondence.

This is what Ceramic does. Ceramic stores streams. It is a giant digital warehouse of data created according to very specific rules (the data models) and stored in a very specific way.

I’ll let you muse on what unlocks, as in the next installment we’ll leave our analogue metaphor behind and dive into what’s possible when everything is digital, composable, and defined consistently. Bring your caving gear, because this rabbithole goes deep.

Ceramic is a tricky thing to get your head around, thanks in part to the many new terms it uses. I hope to show that not only do you already understand schema, data objects, streamcodes and streams, you’ve probably already used them (in an offline form). 

We’ll use a simple example - a letter mailed through the post. 

Schema is a fancy word for a set of properties. Together, they form data objects. We can think of a letter as a simple data object, consisting of two schema. The first is a schema for the content of the letter itself. This is a very basic example, consisting of a single property (a string of text). To make our data object, we combine this with another schema - the address. Addresses have several properties - who the letter is addressed to, their street and street number, the town or city, the country, and a postal code. When we put these two schema together we create an object that is recognisable as a letter just about anywhere in the world. 

This is a very useful thing. It means we can send letters to anyone and be confident that an overseas postal service and our local post have a shared understanding of what these mean, unlocking a global form of communication. 

At this stage, though, our letter is just sitting on our desk. We also need some instructions explaining what we want to happen next. We don’t need to know the details, all we need to do is set the process in motion by putting a stamp on the envelope and dropping it into a mailbox. In effect what we’ve done is tell the postal service “please take this envelope to the address on the front”. 

Let’s imagine that instead of mailing our letter, we wanted to post the contents online and store them on Ceramic. We need to find an app that uses the Ceramic data network, type in the contents of the letter, and press a button to post it. This is equivalent to dropping your letter into the mailbox; it starts the process of getting the information to where it needs to go. Just like we attached a stamp to say “please deliver this letter”, the app attaches a streamcode to your data that tells Ceramic what needs to happen next. In this case the instructions are “please store this content on the network under my user ID”. 

There is one final important thing. The letter in the example is stamped with a postmark showing where it was sent from, and at what time. This is how a post office confirms that the letter is a legitimate article in their system that needs to be delivered to its destination. The equivalent process on Ceramic is a message signed with your private key, a step which also records the date and time at which you signed it. 

Let’s recap. We have a data object (our letter) which is defined by two sets of properties, or schema: the text of the letter and the address. We have a streamcode, or set of instructions (our stamp), saying what needs to happen with that data object, and we have a signature confirming when and where it came from (the postmark). In Ceramic terms, we now have a stream. 

In plain English, the stream for my letter would be something along the lines of:

At 1:00pm UTC on Wednesday, August 24th, the Melbourne post office processed a letter sent by Adam and addressed to Alice. It read “Dear Alice. gm. Sincerely, Adam.”

Let’s imagine Alice is a dedicated penpal who stores every letter I’ve ever written to her, along with the envelopes showing when and where they came from. I, or anyone else, could visit her at any time, ask to see all of the letters, and have access to a complete history of our correspondence.

This is what Ceramic does. Ceramic stores streams. It is a giant digital warehouse of data created according to very specific rules (the data models) and stored in a very specific way.

I’ll let you muse on what unlocks, as in the next installment we’ll leave our analogue metaphor behind and dive into what’s possible when everything is digital, composable, and defined consistently. Bring your caving gear, because this rabbithole goes deep.