1 00:00:00,300 --> 00:00:04,800 This is epicenter episode, 482, with guest joah thorsten. 2 00:00:19,000 --> 00:00:21,400 Welcome to epicenter the show which talks about the 3 00:00:21,400 --> 00:00:24,600 Technologies project and people driving decentralisation and the 4 00:00:24,600 --> 00:00:27,200 blockchain revolution. I'm literally can't and I'm here 5 00:00:27,200 --> 00:00:29,800 with my hair Roy and today, we're speaking with do, with 6 00:00:29,800 --> 00:00:33,100 those citizen, who is the technical co-founder of 7 00:00:33,100 --> 00:00:37,500 three-box Labs, the creator of ceramic and creative. 8 00:00:37,500 --> 00:00:40,400 Ceramic, is this data storage solution? 9 00:00:41,100 --> 00:00:46,500 For web three projects and we will talk about this in just a 10 00:00:46,500 --> 00:00:49,500 little bit. But just before, I'd like to 11 00:00:49,500 --> 00:00:54,400 tell you about our sponsor this week, our sponsor this week is 12 00:00:55,000 --> 00:00:59,500 Omni Omni is your new favorite Mighty change Mobile wallet. 13 00:00:59,500 --> 00:01:02,800 I'll need supports more than 25 protocols, so you can manage all 14 00:01:02,800 --> 00:01:05,900 of your assets in one place. But what's really special about? 15 00:01:05,900 --> 00:01:08,400 Omni is what you can do. Inside the wallet want to get 16 00:01:08,400 --> 00:01:10,900 yet on the allows you to get the best API. 17 00:01:11,400 --> 00:01:15,000 With zero fees and three Taps need to swap on the Aggregates 18 00:01:15,000 --> 00:01:18,600 are major Bridges and dex's so you can Bridge into up across 19 00:01:18,600 --> 00:01:21,200 all supported networks in one transaction directly in your 20 00:01:21,200 --> 00:01:25,200 wallet love and ft is Omni offers the broadest and a few 21 00:01:25,200 --> 00:01:27,800 support of any wallet. So you can collect and manage 22 00:01:27,800 --> 00:01:30,500 your favorite and F Keys across all chains in one place. 23 00:01:30,800 --> 00:01:33,600 I'm need through these, the easiest way to use web three and 24 00:01:33,600 --> 00:01:36,200 it's fully safe custodial. Meaning, you never has Factory. 25 00:01:36,200 --> 00:01:39,400 Trust anyone with your assets other than yourself and they 26 00:01:39,400 --> 00:01:42,400 support Ledger's. Well, If I'm near Triad Omni dot 27 00:01:42,400 --> 00:01:45,600 Airport. So it's a pleasure to have you 28 00:01:45,600 --> 00:01:47,100 on. Yeah, thanks. 29 00:01:47,100 --> 00:01:50,400 Great to be here. I remember you from ages ago at 30 00:01:50,400 --> 00:01:52,400 consensus. So clearly you've been in the 31 00:01:52,400 --> 00:01:57,300 ecosystem or wire, tell us what you've been up to? 32 00:01:58,800 --> 00:02:03,000 Yeah, well started I was playing around with it there even before 33 00:02:03,000 --> 00:02:06,900 the launch in like 2015, did a bachelor project the LED to an 34 00:02:06,900 --> 00:02:11,700 internship at consensus and eventually started working 35 00:02:11,700 --> 00:02:15,300 part-time at consensus. As I was finishing my masters in 36 00:02:16,300 --> 00:02:21,500 complex, adaptive systems. And so at the time, the project 37 00:02:21,500 --> 00:02:23,600 I was working at a consensus called you bored. 38 00:02:24,100 --> 00:02:30,600 So this was this early identity Focus project in the theorem 39 00:02:30,600 --> 00:02:34,500 ecosystem so some of the older listeners might remember that. 40 00:02:35,700 --> 00:02:38,200 And as you port, that's essentially where I met my 41 00:02:38,200 --> 00:02:40,500 co-founders. And we started actually 42 00:02:40,500 --> 00:02:45,000 incubating inside of you port with eventually has become 43 00:02:45,000 --> 00:02:47,500 ceramic Network. Right. 44 00:02:47,500 --> 00:02:50,900 So how did you come up with the idea of settlement or rather? 45 00:02:51,000 --> 00:02:53,800 What is the grand idea behind ceramic? 46 00:02:54,900 --> 00:02:57,900 Yeah, so one thing that we noticed with you port was that 47 00:02:58,800 --> 00:03:04,800 we're building this identity solution and we kind of had to 48 00:03:04,800 --> 00:03:10,400 build our own wallet and even back in like 2016, 2017, it felt 49 00:03:10,400 --> 00:03:14,000 like it doesn't seem right to compete with metal mask and all 50 00:03:14,000 --> 00:03:16,200 of the other walls that were was around at the time. 51 00:03:17,500 --> 00:03:21,400 And so, one of the inquiries that led to the creation of our 52 00:03:21,400 --> 00:03:26,400 first prototype called three-box Jas, Was essentially like, hey 53 00:03:26,400 --> 00:03:31,700 can we build a system that allows allows developers to 54 00:03:31,800 --> 00:03:36,600 build more data Rich applications but it works with 55 00:03:36,600 --> 00:03:39,500 any wallet. And so we're prototyping on that 56 00:03:39,500 --> 00:03:45,000 and that led to this three-box JS SDK and after like that 57 00:03:45,000 --> 00:03:49,100 having been used by a bunch of people over time, we draw some 58 00:03:49,100 --> 00:03:53,500 main insights from that experience and and created 59 00:03:54,600 --> 00:03:57,900 hammock. Thinking back a while ago, the 60 00:03:57,900 --> 00:04:01,500 first thing that I kind of became aware of under the 61 00:04:01,500 --> 00:04:04,500 three-box umbrella. Was this chat box? 62 00:04:04,500 --> 00:04:08,400 And we actually, at the time we kind of integrated into a 63 00:04:08,400 --> 00:04:11,500 prediction Market platform that we were offering at the time. 64 00:04:11,500 --> 00:04:15,100 I mean, still around, you can still use them but I mean and 65 00:04:15,100 --> 00:04:18,899 basically, it was just a way to kind of put comments and stuff. 66 00:04:19,500 --> 00:04:22,800 So how did you get from there to? 67 00:04:23,000 --> 00:04:25,700 You know, this very comprehensive data source? 68 00:04:25,900 --> 00:04:28,900 Sushi. The JavaScript SDK that we're 69 00:04:28,900 --> 00:04:30,900 building was very ambitious. We're trying to build this 70 00:04:30,900 --> 00:04:36,500 completely decentralized in browser system that would allow 71 00:04:36,500 --> 00:04:41,100 you to make some basic social features, like comments and 72 00:04:41,100 --> 00:04:46,700 profiles, and things like this and have that be live inside of 73 00:04:46,700 --> 00:04:49,300 your browser. So, that was using a JavaScript 74 00:04:49,300 --> 00:04:52,100 implementation of ipfs at the time. 75 00:04:54,700 --> 00:05:00,800 And some of the learnings we got from, That is that these kind of 76 00:05:00,800 --> 00:05:04,500 data structures that enable this really local first type of 77 00:05:04,500 --> 00:05:07,500 applications or really powerful Primitives. 78 00:05:07,900 --> 00:05:10,800 And they are have similarities to blockchains in that you have 79 00:05:10,800 --> 00:05:16,500 these verifiable data structures that can be shared across 80 00:05:16,500 --> 00:05:22,400 multiple nodes, but doing actually doing it and starting 81 00:05:22,400 --> 00:05:26,900 to build that in browser. First is really difficult and so 82 00:05:26,900 --> 00:05:30,300 we took the core insides of like these data structures how we can 83 00:05:30,500 --> 00:05:38,000 deal with identities and how we can create basically use Updates 84 00:05:38,000 --> 00:05:40,500 and events users create over time to create an actual 85 00:05:40,500 --> 00:05:48,000 database and take this and build a node application that your 86 00:05:49,300 --> 00:05:50,800 front-end applications can talk to. 87 00:05:50,800 --> 00:05:53,000 So in the same way you talk to you like an ethereal node, you 88 00:05:53,000 --> 00:05:56,200 can also talk to a ceramic. Now they could deal with more of 89 00:05:56,200 --> 00:06:00,800 like the data Rich features. I was going through all these 90 00:06:00,800 --> 00:06:08,800 ceramic ceramic documentation on the on the web today and maybe 91 00:06:08,800 --> 00:06:12,400 I'll tell you my imagination of how like, why you need something 92 00:06:12,400 --> 00:06:15,500 like ceramic or how this idea comes about and maybe you could 93 00:06:16,200 --> 00:06:19,200 corroborate, if if I understand it, right? 94 00:06:19,700 --> 00:06:25,900 So to me the story really starts with Just just the observation 95 00:06:25,900 --> 00:06:29,800 that, you know, the fact that you know I have data on is 96 00:06:29,800 --> 00:06:33,900 helium and then I can use multiple front ends or multiple 97 00:06:33,900 --> 00:06:40,300 user interfaces for for my accounts is really cool. 98 00:06:42,200 --> 00:06:46,200 And you always start to wonder why doesn't like the entire 99 00:06:46,200 --> 00:06:52,100 internet stack work that way inning start to wonder? 100 00:06:52,800 --> 00:06:54,900 Okay, why doesn't she Chill media work. 101 00:06:54,900 --> 00:06:58,700 That way I can put my data onto Facebook and then I can use some 102 00:06:58,700 --> 00:07:01,000 other user interface to Facebook. 103 00:07:01,900 --> 00:07:06,200 And this is like this is like is quite a standard thought 104 00:07:06,200 --> 00:07:08,200 experiment. Many of us have done and there 105 00:07:08,200 --> 00:07:12,700 are many projects that go down in this direction. 106 00:07:13,600 --> 00:07:19,300 So I think one of the things that one starts to realize When 107 00:07:19,300 --> 00:07:22,400 you want this kind of composability that like they 108 00:07:22,400 --> 00:07:24,900 should be multiple user interfaces to some data. 109 00:07:24,900 --> 00:07:32,200 I have is you don't really need. Blockchains or consensus all the 110 00:07:32,200 --> 00:07:35,500 time, right? So if your financial data that 111 00:07:35,500 --> 00:07:39,300 data should lie on is helium or if you have a dow that Financial 112 00:07:39,300 --> 00:07:44,800 logic, should lie on is helium, but if it's my personal data, 113 00:07:47,300 --> 00:07:50,900 That I want to put somewhere and allow lots of people to build 114 00:07:50,900 --> 00:07:55,400 applications. Then my personal data may not 115 00:07:55,400 --> 00:07:59,500 need the blockchain at all and I necessarily don't want to pay 116 00:07:59,500 --> 00:08:01,800 the cost of the blockchain consensus at. 117 00:08:01,800 --> 00:08:09,000 Also start to need some kind of data layer where I can put I can 118 00:08:09,000 --> 00:08:14,000 push my data. And and then other people can 119 00:08:14,000 --> 00:08:16,700 build applications on top of top of that. 120 00:08:18,400 --> 00:08:20,500 So that's kind of like the direction. 121 00:08:20,500 --> 00:08:26,500 Ceramic goes down. Goes toward, but what ceramic is 122 00:08:26,500 --> 00:08:29,100 kind of also. Adding is the observation that 123 00:08:30,200 --> 00:08:35,299 for for good interoperability to exist among multiple 124 00:08:35,299 --> 00:08:38,700 applications. We need no standard ways of 125 00:08:38,700 --> 00:08:42,700 doing identity, standard ways of doing profile standard ways of 126 00:08:42,700 --> 00:08:48,600 doing X, like all of these news feeds and things like that and 127 00:08:49,000 --> 00:08:51,700 you're allowing for such standards to to exist. 128 00:08:51,700 --> 00:08:55,600 So is that right? Is it is like a data. 129 00:08:56,800 --> 00:09:01,700 It's a data layer that enables people to build you eyes for 130 00:09:01,700 --> 00:09:03,500 these. You eyes to be on interoperable 131 00:09:03,500 --> 00:09:07,300 with each other. Yeah, I think that that's a good 132 00:09:07,300 --> 00:09:09,200 overview. I think there's a few things 133 00:09:09,200 --> 00:09:12,800 there, I could double click on. So first of all like the 134 00:09:12,800 --> 00:09:17,700 financial aspect of blockchains blockchains are hard to scale 135 00:09:17,800 --> 00:09:22,400 because we have this requirement of what in this resistance is 136 00:09:22,400 --> 00:09:25,600 called strong consistency. That means that basically all 137 00:09:25,600 --> 00:09:31,700 nodes in the network need to be able to have an agreement, all 138 00:09:31,700 --> 00:09:34,300 the time, like what the state of the system is, and this is how 139 00:09:34,300 --> 00:09:38,200 we prevent double spins. And in a system that doesn't 140 00:09:38,200 --> 00:09:42,100 deal with any kind of assets but it's more data that's produced 141 00:09:42,100 --> 00:09:46,500 by the user. We can kind of loosen that 142 00:09:46,500 --> 00:09:49,500 constraint because we're fine with what is called eventual 143 00:09:49,500 --> 00:09:54,400 consistency and so we don't need to always have all the nodes 144 00:09:54,400 --> 00:09:57,400 have the same agreement on what the state of the system is. 145 00:09:58,200 --> 00:10:01,800 And the nice thing is that we can also have different nodes, 146 00:10:01,800 --> 00:10:05,100 only synchronize, different aspects of the network. 147 00:10:05,700 --> 00:10:09,500 So you might care only about a subset of users or subset of 148 00:10:09,900 --> 00:10:15,900 data models in the network. And this is really what we 149 00:10:16,100 --> 00:10:18,500 achieve with ceramic. Yeah. 150 00:10:18,500 --> 00:10:21,400 And then the second Point around like standards and things like 151 00:10:21,400 --> 00:10:24,500 this. I think that's something that is 152 00:10:24,500 --> 00:10:27,700 really tricky and and our approach to it has been to like 153 00:10:29,100 --> 00:10:32,700 provide examples where we don't want to like set the standards 154 00:10:32,700 --> 00:10:34,100 right? We want the community to come up 155 00:10:34,100 --> 00:10:35,600 with the things that works for that. 156 00:10:35,700 --> 00:10:39,200 Applications because ultimately like, we are not going to be 157 00:10:39,200 --> 00:10:42,300 able to know what the different applications needs. 158 00:10:43,700 --> 00:10:47,600 And so, the approach we take to it in in our graph database 159 00:10:47,600 --> 00:10:51,800 product which were building on top of ceramic called compose, 160 00:10:51,800 --> 00:10:55,900 DB is that developers can come and create the data models, they 161 00:10:55,900 --> 00:10:59,100 can onboard their users and have their uses write data to these 162 00:10:59,100 --> 00:11:04,100 data models. And then other developers can 163 00:11:04,800 --> 00:11:07,800 import these data models into their applications and kind of 164 00:11:07,800 --> 00:11:10,400 get the onboarding of those users for free because the data 165 00:11:10,400 --> 00:11:12,500 is already there. So that's the composability that 166 00:11:12,500 --> 00:11:17,200 you were talking about. I have lots of questions for 167 00:11:17,200 --> 00:11:22,100 kind of these for lots of lots of different facets here but 168 00:11:22,100 --> 00:11:26,700 kind of, I think I want to step back and kind of look at the 169 00:11:26,700 --> 00:11:32,900 larger landscape of Data Solutions in the web three space 170 00:11:32,900 --> 00:11:36,500 first. So I think our listeners may be 171 00:11:36,500 --> 00:11:42,500 familiar with products such as we even ipfs and sire. 172 00:11:42,700 --> 00:11:48,100 And so, how would you kind of We contextualize ceramic within 173 00:11:48,100 --> 00:11:51,400 that landscape. How is it different or similar 174 00:11:51,400 --> 00:11:56,700 to those? So, you're all of the three 175 00:11:57,100 --> 00:11:59,900 products. You mentioned their focus first 176 00:11:59,900 --> 00:12:02,700 on this, like, how can we store files? 177 00:12:02,700 --> 00:12:05,900 And I can restore like pieces chunks of data in an efficient 178 00:12:05,900 --> 00:12:11,300 way that can scale and those are all very useful. 179 00:12:11,300 --> 00:12:15,900 Things to have in the ecosystem, like storage of massive amount 180 00:12:15,900 --> 00:12:18,400 of data is, is incredibly important. 181 00:12:20,200 --> 00:12:25,800 Our Focus From the Start has been on Users their identity in 182 00:12:25,800 --> 00:12:28,800 like how to make these systems easy to use for people. 183 00:12:30,900 --> 00:12:34,400 So in the ceramic instead of having creating blocks where you 184 00:12:34,400 --> 00:12:38,400 either have deals with minors to store data or you have big 185 00:12:38,400 --> 00:12:40,500 blocks that include a bunch of data. 186 00:12:40,800 --> 00:12:45,700 As in some of these systems through we use. 187 00:12:45,700 --> 00:12:48,200 Let we don't really have blocks in ceramic. 188 00:12:48,200 --> 00:12:52,000 We rely on the security of a theorem and instead each user 189 00:12:52,000 --> 00:12:55,500 creates an event stream, Of actions, they take in the 190 00:12:55,500 --> 00:12:57,600 network. This event stream you can think 191 00:12:57,600 --> 00:13:01,700 of kind of like a micro Ledger that is signed by the users key 192 00:13:02,900 --> 00:13:05,400 and all these updates, we can verify that the come from the 193 00:13:05,400 --> 00:13:10,100 user. And since we have like all like, 194 00:13:10,100 --> 00:13:15,200 if we take that together, we can have a view of multiple users 195 00:13:15,600 --> 00:13:20,500 with all their independent event streams and we can compose that 196 00:13:20,500 --> 00:13:23,200 into a database view. So it's like a different 197 00:13:23,200 --> 00:13:27,900 approach to 22 the architecture. But but does it mean that 198 00:13:27,900 --> 00:13:31,400 basically the only the event Creator can write to the event 199 00:13:31,400 --> 00:13:33,400 stream? Because basically if different 200 00:13:33,400 --> 00:13:37,100 people have like right permissions, this won't work, 201 00:13:37,100 --> 00:13:40,100 right? Yes, in ceramic right now. 202 00:13:40,600 --> 00:13:44,000 Each event stream has a controller, which is essentially 203 00:13:45,500 --> 00:13:48,600 a user account. So, right now, there's support 204 00:13:48,600 --> 00:13:52,500 for, I think three different block chain wallets most users. 205 00:13:52,600 --> 00:13:55,400 Use the varium if they're in based wallets. 206 00:13:56,300 --> 00:14:00,800 And so every event stream is controlled by one account, but 207 00:14:00,800 --> 00:14:04,200 then you can take multiple event streams and listen, to all these 208 00:14:04,200 --> 00:14:08,400 events and create a combined view of that. 209 00:14:10,000 --> 00:14:12,500 Okay. So say one of the event streams 210 00:14:12,500 --> 00:14:16,600 is say. My Twitter output, so things I 211 00:14:16,600 --> 00:14:18,300 tweet. But also things I like and 212 00:14:18,300 --> 00:14:21,200 things I retweet. And so on, you could just kind 213 00:14:21,200 --> 00:14:26,100 of this will kind of fit the. I don't know whether broader 214 00:14:26,100 --> 00:14:30,600 social media data structure or Twitter data structure and then 215 00:14:30,600 --> 00:14:33,100 it can be compared to other people's data structures. 216 00:14:33,100 --> 00:14:38,600 And can be compiled into a view of a decentralized version of 217 00:14:38,600 --> 00:14:41,900 Twitter where they see, I can say how I want to how I want to 218 00:14:41,900 --> 00:14:43,800 view things or which things I want to prioritize. 219 00:14:44,100 --> 00:14:46,700 Guys are which things I want to be showed because basically, the 220 00:14:46,700 --> 00:14:51,600 way that social media works right now is that I mean 221 00:14:51,600 --> 00:14:56,800 obviously there's you know, very complex algorithms at work to 222 00:14:56,800 --> 00:15:01,100 kind of calculate what to show you but what exactly they do and 223 00:15:01,100 --> 00:15:05,300 how they operate and what they prioritize, this is this is not 224 00:15:05,300 --> 00:15:07,900 visible and there's no competition as to this. 225 00:15:07,900 --> 00:15:11,700 So basically it would kind of ceramic enable. 226 00:15:13,900 --> 00:15:19,300 Other people to kind of build on the same data streams and kind 227 00:15:19,300 --> 00:15:22,800 of showcase this differently or prioritize things with 228 00:15:22,800 --> 00:15:27,700 differently. The power of ceramic in this 229 00:15:27,700 --> 00:15:31,100 case is that we can actually start to mimic a little bit 230 00:15:31,100 --> 00:15:33,500 more. How the architecture of kind of 231 00:15:33,500 --> 00:15:38,600 web to social media works because web to social media 232 00:15:38,600 --> 00:15:40,400 networks like Twitter or Facebook. 233 00:15:40,400 --> 00:15:42,700 They don't scale on a strong consistency model like a 234 00:15:42,700 --> 00:15:46,900 blockchain they have they have some databases, they have event 235 00:15:46,900 --> 00:15:49,200 streams in their systems and they have a bunch of micro 236 00:15:49,200 --> 00:15:51,100 services that they care of different tasks. 237 00:15:51,900 --> 00:15:55,400 So we can imagine a very primitive social network on. 238 00:15:55,500 --> 00:15:58,800 Around make that just like oh here's my tweets and then when I 239 00:15:58,808 --> 00:16:03,700 follow Frederick in mayor, I use compost that into my view. 240 00:16:03,700 --> 00:16:09,000 But if I follow, like thousands of people, that's not really 241 00:16:09,000 --> 00:16:12,400 going to be efficient. But the cool thing with ceramic 242 00:16:12,400 --> 00:16:16,500 is that they could actually be a service somewhere that ingests, 243 00:16:16,500 --> 00:16:19,600 all of these strings of my followers as and as a micro 244 00:16:19,600 --> 00:16:22,800 service run, some computation over it and outputs that in a 245 00:16:22,800 --> 00:16:27,300 new event stream. And then, Then I consume that 246 00:16:27,500 --> 00:16:32,100 and this computation could be done in a verifiable matter. 247 00:16:32,400 --> 00:16:35,400 Either. It's a deterministic computation 248 00:16:35,400 --> 00:16:40,700 that I can rerun and see that it was correct or maybe in the 249 00:16:40,700 --> 00:16:43,900 future, if we can have like very efficient seek a piece like that 250 00:16:43,900 --> 00:16:46,800 could even be that. But for the time being like 251 00:16:46,800 --> 00:16:51,700 having compute actually attributed, by in the ceramic 252 00:16:51,700 --> 00:16:54,700 stream, by The Smokers micro service provider actually gives 253 00:16:54,700 --> 00:16:58,800 us some Um better trust in the system. 254 00:16:59,200 --> 00:17:02,900 And I can actually choose which of these service providers that 255 00:17:02,900 --> 00:17:10,099 I want to build my my stream of tweets or what have you. 256 00:17:12,200 --> 00:17:18,900 Okay, I think one thing that I kind of don't understand yet is 257 00:17:19,000 --> 00:17:21,700 I mean, you do distinguish between different kinds of 258 00:17:21,800 --> 00:17:27,800 consensus. But why do you need a consensus 259 00:17:28,200 --> 00:17:32,300 in the ceramic Network at all? I mean, if it's just a 260 00:17:32,300 --> 00:17:37,400 decentralized storage layer and it can be proven that basically 261 00:17:37,400 --> 00:17:39,900 my data stored, why does it need consensus? 262 00:17:41,000 --> 00:17:43,600 Also, we need some some basic form of consensus, right? 263 00:17:43,600 --> 00:17:48,500 Like if your node and my node, get the exact same events. 264 00:17:48,900 --> 00:17:52,600 We want to be sure that we end up in the same state if we don't 265 00:17:52,600 --> 00:17:55,200 end up in the same state that's bad. 266 00:17:55,400 --> 00:17:59,200 So it's not like a global consensus that in the in the 267 00:17:59,200 --> 00:18:03,200 sense of blockchains, where there is an agreed-upon state 268 00:18:03,200 --> 00:18:04,800 that everyone didn't ever get grease on. 269 00:18:05,000 --> 00:18:08,300 It's more like if we consume the same events we end up at the 270 00:18:08,308 --> 00:18:10,500 same state so it would be terrible. 271 00:18:10,700 --> 00:18:15,100 Check them. Yeah, in distributed systems, 272 00:18:15,100 --> 00:18:18,000 this is called consensus like that that your knowledge can 273 00:18:18,000 --> 00:18:19,700 actually arrive at the same conclusion. 274 00:18:20,900 --> 00:18:24,300 Okay, I think then I just have very different mental 275 00:18:24,300 --> 00:18:27,200 representation of consensus because to me, consensus kind of 276 00:18:27,200 --> 00:18:29,500 is it is by default a global thing. 277 00:18:29,500 --> 00:18:33,300 But I think this is maybe just a Corruption of kind of how the 278 00:18:33,300 --> 00:18:37,800 actual technical term is used by and learn communities. 279 00:18:38,500 --> 00:18:40,900 Okay? So then I kind of then I kind of 280 00:18:40,900 --> 00:18:44,000 understand that part you said that you guys build on e 281 00:18:44,000 --> 00:18:45,400 theorem. So basically what's kind of the 282 00:18:45,400 --> 00:18:50,600 connection between ceramic and deuterium Yeah, so I mentioned 283 00:18:50,600 --> 00:18:55,500 this event streams. There are signed by end users so 284 00:18:55,500 --> 00:18:58,900 they're good for like, okay. Now we know we have attribution 285 00:18:58,900 --> 00:19:02,200 to who created what and who wrote, what into the network. 286 00:19:02,200 --> 00:19:07,300 But we also want some some guarantees about when certain 287 00:19:07,300 --> 00:19:10,900 events took place and this is where ethereum comes into the 288 00:19:10,900 --> 00:19:15,000 picture. So every once in awhile event 289 00:19:15,000 --> 00:19:18,000 streams are anchored into the blockchain, and what this means 290 00:19:18,000 --> 00:19:21,500 is that That there is a hash or some other kind of vector 291 00:19:21,500 --> 00:19:25,400 commitment that's included in the blockchain that basically 292 00:19:26,000 --> 00:19:30,600 allows any consumer of this event stream to convince 293 00:19:30,600 --> 00:19:33,300 themselves that. Okay this event was published at 294 00:19:33,300 --> 00:19:37,700 least at this point in time and obviously like making one 295 00:19:38,700 --> 00:19:43,400 ethereum transaction per event stream update would not really 296 00:19:43,400 --> 00:19:47,700 be scalable. So what we do is we create a 297 00:19:47,700 --> 00:19:51,800 Merkle tree That batch has a bunch of updates to a bunch of 298 00:19:51,808 --> 00:19:56,300 different streams and puts the root of that Merkle, Tree on 299 00:19:56,300 --> 00:20:00,300 Jay. So earlier, you mentioned that 300 00:20:00,800 --> 00:20:05,200 data in ceramic will be eventually consistent, which, 301 00:20:05,900 --> 00:20:11,300 which kind of means that, if, if let's say, I push to updates. 302 00:20:12,500 --> 00:20:16,300 So let's say I'm using the ceramic Twitter and I push two 303 00:20:16,300 --> 00:20:21,900 posts and one. After the other ultimately, the 304 00:20:21,900 --> 00:20:27,000 ceramic network will decide on which post came first and which 305 00:20:27,000 --> 00:20:29,300 came second. Right? 306 00:20:30,400 --> 00:20:34,700 And they might be a span of time where the network hasn't made a 307 00:20:34,700 --> 00:20:39,000 decision, but ultimately it will eventually it will make make 308 00:20:39,000 --> 00:20:41,000 this decision. That's how I think of eventual 309 00:20:41,000 --> 00:20:43,000 consistency. Yeah. 310 00:20:43,000 --> 00:20:47,700 And in the case of your personal posts, you actually, when you 311 00:20:47,708 --> 00:20:50,500 make post one, and then you make post to your post, you will 312 00:20:50,500 --> 00:20:52,100 actually point back to your previous posts. 313 00:20:52,100 --> 00:20:55,000 So like for your personal things, it will be like ordered 314 00:20:55,700 --> 00:20:58,400 but between like two different users, it's not ordered in the 315 00:20:58,700 --> 00:21:00,600 When done, we would rely on these anchors. 316 00:21:02,300 --> 00:21:06,600 Okay, so how do you reach eventual consistency in the 317 00:21:06,600 --> 00:21:09,800 network? Is it is it down to, is it down 318 00:21:09,800 --> 00:21:13,700 to the Anchor in the ethereum blockchain meanings like some 319 00:21:13,700 --> 00:21:17,500 ceramic node at some point of time is going to put push an 320 00:21:17,500 --> 00:21:22,700 anchor and then whatever ordering they did is the 321 00:21:22,700 --> 00:21:25,900 ordering of the ceramic network, is it like that or is there a 322 00:21:25,908 --> 00:21:29,800 different mechanism here? So based on the anchor, you can 323 00:21:29,800 --> 00:21:32,200 look at the Block Chain and see like, hey, that's this block 324 00:21:32,200 --> 00:21:35,000 those produce was the block out and what's the timestamp in this 325 00:21:35,000 --> 00:21:38,500 block and so if you have two conflicting events in the 326 00:21:38,500 --> 00:21:44,200 network, you can look at like which one came first and then 327 00:21:44,200 --> 00:21:49,600 you would know how to choose I'm actually I'm actually curious 328 00:21:49,600 --> 00:21:53,100 like so data. There have been these computer 329 00:21:53,100 --> 00:22:00,500 science data structures called like CR DTS conflict free data 330 00:22:00,500 --> 00:22:03,000 types are essentially. It's a data structure. 331 00:22:03,000 --> 00:22:06,200 Different people can push updates to it and they will be 332 00:22:06,200 --> 00:22:10,300 eventual consistency of the data. 333 00:22:10,600 --> 00:22:13,800 Without there being like an active voting base consensus, 334 00:22:13,800 --> 00:22:17,100 like in proof of stake, proof of stake Networks. 335 00:22:18,100 --> 00:22:23,400 So, you have ways of getting consistency of data in a 336 00:22:23,400 --> 00:22:27,300 decentralized network without, you know, practical Byzantine 337 00:22:27,300 --> 00:22:32,300 fault tolerant consensus. I you using something like that 338 00:22:32,300 --> 00:22:37,300 in ceramic as well. Or or or IUI, you actually 339 00:22:37,300 --> 00:22:41,400 getting eventual consistency. We are some other mechanism. 340 00:22:42,000 --> 00:22:44,300 Yeah. So, let's sociology thesis is 341 00:22:44,300 --> 00:22:47,200 something that we're quite familiar with we're not actually 342 00:22:47,200 --> 00:22:49,000 using them. Yet, but it's something we are 343 00:22:49,000 --> 00:22:53,300 intending to use as we improve the protocol. 344 00:22:53,500 --> 00:22:58,300 So right now, if we think about a single event stream, a single 345 00:22:58,300 --> 00:23:03,200 event stream, is only allowed to have one canonical history, kind 346 00:23:03,200 --> 00:23:06,800 of in the same way at watching has like one canonical chain. 347 00:23:08,300 --> 00:23:12,600 And if there is a conflict, if there's a fork in this, in this 348 00:23:12,900 --> 00:23:17,700 event log, then we would basically choose the the fork 349 00:23:17,900 --> 00:23:22,100 Was anchored earliest and this is this actually is the property 350 00:23:22,100 --> 00:23:25,100 that allows us to do key rotation in a secure way. 351 00:23:25,400 --> 00:23:30,600 And that's a whole other rabbit hole, which I have an article on 352 00:23:30,600 --> 00:23:35,100 our block on by the way. But for many cases, we don't 353 00:23:35,100 --> 00:23:37,800 actually need to choose one of these Forks. 354 00:23:37,800 --> 00:23:41,400 We can actually use like do a merge and then do a senior TT 355 00:23:41,500 --> 00:23:45,100 based logic to figure out the complete ordering of these 356 00:23:45,100 --> 00:23:47,600 events. So that's that is an improvement 357 00:23:47,600 --> 00:23:49,400 that we're planning in the protocol. 358 00:23:51,200 --> 00:23:56,900 Okay, so so essentially now the way I'm imagining ceramic is 359 00:23:57,000 --> 00:24:00,100 okay, there's this huge Lake of data. 360 00:24:00,200 --> 00:24:05,300 I can push my event stream to it and by virtue of how my event 361 00:24:05,300 --> 00:24:08,900 stream is designed. And the fact that ultimately 362 00:24:08,900 --> 00:24:11,300 this network will anchor something on the ethereum 363 00:24:11,300 --> 00:24:16,100 blockchain, this kind of going to be eventual consistency in 364 00:24:16,100 --> 00:24:20,800 the network where the network can agree on what events came. 365 00:24:21,000 --> 00:24:23,500 First. And what events came came. 366 00:24:23,500 --> 00:24:26,900 Second roughly. That's, that's, that's my, 367 00:24:27,000 --> 00:24:29,200 that's my picture. Yeah, exactly. 368 00:24:29,200 --> 00:24:31,700 So if you have two nodes in the network and they observe the 369 00:24:31,700 --> 00:24:34,700 same events they even though there might not be talking to 370 00:24:34,700 --> 00:24:38,200 each other, but they have seen the same events they can arrive 371 00:24:38,200 --> 00:24:42,700 at the same conclusion. So let's talk about the nodes in 372 00:24:42,700 --> 00:24:46,900 the network, right? So basically, anyone can what 373 00:24:46,900 --> 00:24:49,100 are the requirements for running a ceramic node? 374 00:24:50,100 --> 00:24:55,200 Yeah, so running, a ceramic node in itself, it doesn't have like 375 00:24:55,700 --> 00:25:00,100 super big requirements because when you start a ceramic node, 376 00:25:00,300 --> 00:25:04,100 you don't have any data on it and then you have to tell your 377 00:25:04,100 --> 00:25:07,300 node that hey I want to subscribe to this particular 378 00:25:07,300 --> 00:25:11,500 event stream and so if you're familiar with With something 379 00:25:11,500 --> 00:25:15,500 like ipfs, where you have to, like, pin individual objects, 380 00:25:16,000 --> 00:25:18,300 you have to subscribe to individual event streams and 381 00:25:18,300 --> 00:25:22,600 ceramic. So, for most users of ceramic 382 00:25:22,600 --> 00:25:29,000 right now, you actually or the developers that are building on 383 00:25:29,000 --> 00:25:31,600 ceramic, they are running their own nodes to support their 384 00:25:31,600 --> 00:25:36,400 applications and and right now and ceramic, there's no like 385 00:25:36,600 --> 00:25:43,000 built-in redundancies one thing that's we're doing with this 386 00:25:44,100 --> 00:25:46,300 database product. Composed, the be that I 387 00:25:46,308 --> 00:25:50,100 mentioned is the ability to synchronize data between nodes 388 00:25:50,400 --> 00:25:53,400 so that they can have the same view. 389 00:25:53,700 --> 00:25:57,700 For example, if you have like a blog post model, we can have two 390 00:25:57,700 --> 00:26:00,400 different applications that build on this blog. 391 00:26:02,700 --> 00:26:09,100 So that's like kind of Allowing nodes to use like, subscribe to 392 00:26:09,100 --> 00:26:11,700 the data which they care about now. 393 00:26:13,200 --> 00:26:17,500 That's fine, kind of for developers but if I'm an end 394 00:26:17,500 --> 00:26:21,000 user I don't have any guarantees that like these two blog 395 00:26:21,000 --> 00:26:25,800 applications will be online. So one thing we are going to add 396 00:26:25,800 --> 00:26:30,000 in the future is a network incentive where you as a user or 397 00:26:30,000 --> 00:26:32,300 you as a developer can pay the network. 398 00:26:32,700 --> 00:26:37,800 And pay I said up Notes to keep this data available in the 399 00:26:37,800 --> 00:26:43,000 network. but right now nodes are run mainly by application 400 00:26:43,000 --> 00:26:45,400 developers that wants to leverage the functionality of 401 00:26:45,400 --> 00:26:51,700 ceramic You kind of everyone kind of stores their own data. 402 00:26:52,400 --> 00:26:55,900 And there's no way to kind of say I would back up, someone 403 00:26:55,900 --> 00:26:57,600 else's data or someone else will backup. 404 00:26:57,600 --> 00:27:01,400 My data is just basically all in my own ceramic node know, you 405 00:27:01,400 --> 00:27:04,300 can definitely, it's a public open network. 406 00:27:04,300 --> 00:27:06,900 So anyone can subscribe to any stream in the network. 407 00:27:08,200 --> 00:27:13,800 So I could, for example, subscribe to to your stream and 408 00:27:14,300 --> 00:27:19,600 provide like a redundant copy of the Stream, So as we kind of 409 00:27:20,100 --> 00:27:27,000 alluded to earlier, this is for very specific types of data. 410 00:27:27,000 --> 00:27:34,200 It's kind of not, it's not a general storage solution, you 411 00:27:34,200 --> 00:27:39,600 kind of we already talked about social networks for a bit, but 412 00:27:39,600 --> 00:27:44,000 what I kind of the articles that kind of what, what what, what 413 00:27:44,000 --> 00:27:49,100 kind of data usage is this gear towards So, yeah, so there's 414 00:27:49,100 --> 00:27:56,100 there's around for different niches that we look at being 415 00:27:56,100 --> 00:28:02,100 more common today and one of the most prominent ones right now is 416 00:28:02,100 --> 00:28:05,400 reputation. So we have projects like get 417 00:28:05,400 --> 00:28:07,400 going and disco. There are putting different 418 00:28:07,400 --> 00:28:10,700 kinds of verifiable credentials on ceramic that are associated 419 00:28:10,700 --> 00:28:14,000 with your ethereum address, or your other blockchain address 420 00:28:14,900 --> 00:28:18,300 and then be able to calculate Late some kind of score based on 421 00:28:18,300 --> 00:28:23,400 that so and get coins. Case you have a civil resistance 422 00:28:23,400 --> 00:28:26,800 score but we already talked about social. 423 00:28:27,000 --> 00:28:31,100 So there's a few different applications building different 424 00:28:31,100 --> 00:28:34,600 kinds of web. Three posts, social networks or 425 00:28:34,600 --> 00:28:37,300 business. One cyber connected and other 426 00:28:37,300 --> 00:28:41,500 one. Then another category is 427 00:28:41,500 --> 00:28:47,200 knowledge graphs so there we have mainly projects within the 428 00:28:47,300 --> 00:28:49,200 decentralized, science-based D, PSI. 429 00:28:50,000 --> 00:28:54,300 One of the the most furthest along there is lateral, they're 430 00:28:54,300 --> 00:28:58,400 building, essentially a knowledge graph that represents 431 00:28:58,400 --> 00:29:01,300 scientific discourse and the cool thing there, of course is 432 00:29:01,300 --> 00:29:04,400 like can look at this knowledge graph and since it's stored on 433 00:29:04,400 --> 00:29:07,900 ceramic you can see who actually contributed what to do. 434 00:29:08,100 --> 00:29:10,600 Us Knowledge Graph because it's cryptographically link to your 435 00:29:10,600 --> 00:29:13,200 ethereum address. And what they want to do 436 00:29:13,200 --> 00:29:19,100 eventually is to trickle down payments to people who actually 437 00:29:19,100 --> 00:29:24,300 contribute valuable knowledge. Then another Niche, I think in 438 00:29:24,300 --> 00:29:26,600 the ceramic communities Bell, tolling. 439 00:29:27,600 --> 00:29:32,100 So basically, if we think about the Dow ecosystem, today we use 440 00:29:32,100 --> 00:29:33,700 a lot of, like, centralized tools. 441 00:29:34,200 --> 00:29:39,500 We use Discord, we use hosted forms that Maybe like one guy on 442 00:29:39,500 --> 00:29:44,600 the Dow is hosting and like this seems very fragile. 443 00:29:46,300 --> 00:29:51,000 And so one example here so when we could be used to like replace 444 00:29:51,000 --> 00:29:54,600 these things would like a more decentralized and resilient 445 00:29:54,600 --> 00:29:58,300 infrastructure one place where this is starting to happen. 446 00:29:58,300 --> 00:30:07,500 In particular is the gnosis safe Community where the safe app has 447 00:30:07,500 --> 00:30:10,300 a Centralized back in that. These stores, a bunch of 448 00:30:10,300 --> 00:30:14,200 transactions that are pending and may be signed by some of the 449 00:30:15,300 --> 00:30:19,100 delegates. So there's this company called 450 00:30:19,100 --> 00:30:21,600 thousand systems, they're building a decentralized, save 451 00:30:21,600 --> 00:30:25,200 registry for these pending transactions on in ceramic. 452 00:30:26,500 --> 00:30:29,400 So, those are some of the like use cases, we see today, I think 453 00:30:29,400 --> 00:30:33,500 there's like interesting things in the future that might be more 454 00:30:33,500 --> 00:30:37,500 speculative, but around data provenance that could be like 455 00:30:38,700 --> 00:30:42,300 These new language and image models. 456 00:30:42,300 --> 00:30:45,300 We're seeing in AI, there's a bunch of copyright problems. 457 00:30:45,800 --> 00:30:48,900 Ceramic could be used to like provide attribution to who 458 00:30:48,900 --> 00:30:53,600 actually did what, and how that feed into these systems. 459 00:30:55,200 --> 00:30:59,500 I think we want to have Supply chains have more attribution in 460 00:30:59,500 --> 00:31:02,500 the systems and similar with, with iot. 461 00:31:02,500 --> 00:31:04,700 So that's things. That's worth exploring the 462 00:31:04,708 --> 00:31:09,200 future. Does it have to be public data 463 00:31:09,200 --> 00:31:12,300 by default? I mean, can I put private data 464 00:31:12,300 --> 00:31:15,800 on ceramic and have it? Stay private or only accessible 465 00:31:15,800 --> 00:31:18,600 to some? Yeah, this is a great question, 466 00:31:18,700 --> 00:31:24,200 and it's nuanced, right? So, by default, ceramic is a 467 00:31:24,200 --> 00:31:27,800 fully public network. Now, the first thing you might 468 00:31:27,800 --> 00:31:31,100 want to think about when putting some data on ceramics, it. 469 00:31:31,100 --> 00:31:34,600 Hey, I can encrypt it. So you can certainly encrypt 470 00:31:34,600 --> 00:31:40,500 data put it on ceramic and this will be private, but you have to 471 00:31:40,500 --> 00:31:44,500 think about the future, right? Because in the future, we're 472 00:31:44,500 --> 00:31:46,700 going to have a very fancy quantum computers. 473 00:31:47,200 --> 00:31:49,200 That might break some of our cryptography. 474 00:31:49,500 --> 00:31:53,300 So if you're using any kind of like current asymmetric 475 00:31:53,300 --> 00:31:57,600 cryptography, your private data might not be so private anymore, 476 00:31:59,300 --> 00:32:03,900 and that might be. You might also not be like 477 00:32:03,900 --> 00:32:06,700 satisfied with like ciphers that exist today. 478 00:32:07,500 --> 00:32:09,900 They might be broken, even though they're like supposed to 479 00:32:09,900 --> 00:32:14,800 be Quantum secure, it really depends on like your risk. 480 00:32:14,800 --> 00:32:18,600 And like how private this data really is in any decentralized 481 00:32:18,600 --> 00:32:22,000 system that is publicly verifiable. 482 00:32:22,200 --> 00:32:24,800 You have this problem. So the only way you can really 483 00:32:24,900 --> 00:32:28,300 be safe, that your data is completely secure is probably to 484 00:32:28,300 --> 00:32:32,300 encrypt it and store it on your own machine or you trust someone 485 00:32:32,300 --> 00:32:34,900 to store. For you and then you just that 486 00:32:34,900 --> 00:32:39,100 they don't get hacked and so on it's there's a possibility that 487 00:32:39,100 --> 00:32:45,600 we could explore in the future. Some kind of Access Control 488 00:32:45,700 --> 00:32:49,200 logic in ceramic ware. Only if you have an authorized 489 00:32:49,200 --> 00:32:52,700 Identity or like account you're able to synchronize certain 490 00:32:53,100 --> 00:32:57,400 subsets of data but that's not something that we really focus 491 00:32:57,400 --> 00:32:59,600 on right now. We think there's like a lot of 492 00:32:59,600 --> 00:33:05,200 exciting things in the public. Data or public but encrypted, 493 00:33:05,200 --> 00:33:11,200 data ecosystem. So yeah, so my imagination of 494 00:33:11,200 --> 00:33:14,400 ceramic is now okay, so there's a network, there's lots of nodes 495 00:33:14,400 --> 00:33:18,700 on the network. I can publish my event stream in 496 00:33:18,700 --> 00:33:21,700 the early days of the network. It's probably nice. 497 00:33:21,700 --> 00:33:26,200 If I publish my event stream, either way that it doesn't 498 00:33:26,200 --> 00:33:29,600 contain my private data or it rather contains data that I am 499 00:33:29,600 --> 00:33:33,700 comfortable sharing with the world and there's eventual 500 00:33:33,700 --> 00:33:37,100 consistency in the networks and network will agree on what came 501 00:33:37,100 --> 00:33:39,500 first. Eventually. 502 00:33:40,500 --> 00:33:44,300 Okay, understood. So we have that basic primitive 503 00:33:44,600 --> 00:33:50,200 but allude to the fact that, okay, you want to allow people 504 00:33:50,200 --> 00:33:57,100 to build applications on top where, where ultimately 505 00:33:57,600 --> 00:34:00,800 ultimately their interoperable with each other, that's on your 506 00:34:00,800 --> 00:34:03,700 website. So what is the meaning of 507 00:34:03,700 --> 00:34:07,600 interoperability for applications on top of ceramic 508 00:34:08,199 --> 00:34:11,199 and And what might be some of the tools you have built on top 509 00:34:11,199 --> 00:34:16,600 to enable it. Yeah, so at its core like 510 00:34:16,600 --> 00:34:20,900 ceramic is an event streaming protocol. 511 00:34:21,400 --> 00:34:24,300 And this is not something that like most developers are 512 00:34:24,300 --> 00:34:27,400 familiar with in web to like, there are few different events 513 00:34:27,400 --> 00:34:32,199 streaming Solutions, but it's more of like a thing that 514 00:34:32,900 --> 00:34:36,400 experienced back. End, Engineers used to really 515 00:34:36,400 --> 00:34:41,500 scale to applications to like, handle a lot of load. 516 00:34:41,900 --> 00:34:45,699 And so we need some tooling to Actually usable and easy to use 517 00:34:45,699 --> 00:34:49,800 for developers. And so, what we created for this 518 00:34:49,800 --> 00:34:55,900 is composed DB to compose DB is a graph database that allows 519 00:34:56,300 --> 00:34:59,700 developers to Define data models, which is basically a 520 00:35:00,600 --> 00:35:05,100 schema for your data. And this model you can, it's 521 00:35:05,100 --> 00:35:10,200 kind of analogous to a Smart contract where you define the 522 00:35:10,200 --> 00:35:13,800 data model and then users come to an application. 523 00:35:13,900 --> 00:35:20,000 They create objects or documents that conform to this schema and 524 00:35:20,000 --> 00:35:24,300 then the developer can query this data and read like, hey, 525 00:35:24,300 --> 00:35:28,700 here's all the objects that conform to the schema and buy 526 00:35:28,700 --> 00:35:31,200 all these different users or query like subsets of that. 527 00:35:31,900 --> 00:35:34,500 And you can also have relationships between different 528 00:35:34,500 --> 00:35:36,500 models. So, if you have a blog post you 529 00:35:36,500 --> 00:35:40,100 might have a comment that points to the blog post and you will be 530 00:35:40,100 --> 00:35:42,300 able to query like hey give me all blog posts. 531 00:35:43,600 --> 00:35:46,000 We're like this subset of blog post and also all the comments 532 00:35:46,000 --> 00:35:49,100 related to that subset of blog posts. 533 00:35:49,500 --> 00:35:53,600 So that's kind of big, the graph aspect of that and this tooling 534 00:35:53,600 --> 00:35:58,100 is built in something that's familiar with too many 535 00:35:58,100 --> 00:36:00,900 developers called graphql. So you actually Define your data 536 00:36:00,900 --> 00:36:06,200 models and graphql and you query read and write the data using 537 00:36:06,200 --> 00:36:11,000 graphql as well and compost, it be So, I understand that, 538 00:36:11,000 --> 00:36:14,700 basically, when I write data to my own data stream, I have to 539 00:36:14,700 --> 00:36:20,200 choose a data structure. But how, how is the knowledge 540 00:36:20,200 --> 00:36:24,400 about which data structure? I'm using percolated in the 541 00:36:24,400 --> 00:36:26,200 network? Because as I understand that 542 00:36:26,200 --> 00:36:32,900 today, I you I host my own data. So how is, how is the lateral 543 00:36:32,900 --> 00:36:38,900 connection made? So, you can run an indexer by 544 00:36:38,900 --> 00:36:42,000 spitting up your ceramic node and towing it to index and say 545 00:36:42,000 --> 00:36:44,100 like, hey, what are all the data models in the network? 546 00:36:45,800 --> 00:36:48,700 Or if you have some application that you really like, and you 547 00:36:48,707 --> 00:36:51,000 would like to use like, oh, I need that data, then you can 548 00:36:51,000 --> 00:36:53,100 just look at if their application is open source. 549 00:36:53,100 --> 00:36:56,000 You can look at their application code and it's like, 550 00:36:56,000 --> 00:36:58,500 pull, pull in the data model from there. 551 00:36:59,000 --> 00:37:03,200 So don't like, this is the early days, I think what, what we're 552 00:37:03,200 --> 00:37:07,500 hoping to see in the future? There is some kind of Explorer 553 00:37:07,500 --> 00:37:11,700 or catalog of data models where people can use browse the 554 00:37:11,700 --> 00:37:14,900 different data model, see the popularity and how much usage 555 00:37:14,900 --> 00:37:19,300 they have. And so on and so that experience 556 00:37:19,300 --> 00:37:21,000 should become much easier over time. 557 00:37:22,400 --> 00:37:25,400 And that is also what happens. If there's two competing 558 00:37:25,400 --> 00:37:28,700 standards for the same data model that basically you just 559 00:37:28,700 --> 00:37:35,500 check what gets more usage or what people are more because you 560 00:37:35,508 --> 00:37:38,200 kind of, there's a lock-in effect. 561 00:37:38,500 --> 00:37:41,600 I mean, if you want to be composable the number of things 562 00:37:41,600 --> 00:37:46,500 you can put, composable with is super relevant, right? 563 00:37:47,000 --> 00:37:49,400 Yeah. So there might be two competing 564 00:37:49,400 --> 00:37:51,200 standards for like a user profile. 565 00:37:52,500 --> 00:37:55,500 And you might want to choose two, most popular one, or you 566 00:37:55,500 --> 00:37:59,400 might just want to have a super application that can include 567 00:37:59,400 --> 00:38:03,600 both profiles in this, like, kind of display the information. 568 00:38:03,600 --> 00:38:07,100 That's, that's best it because then you have like reach to more 569 00:38:07,100 --> 00:38:11,600 more existing users but really it's like enabling the developer 570 00:38:11,600 --> 00:38:14,100 Community to figure out what's best for their needs. 571 00:38:15,600 --> 00:38:19,000 So but data models are by default open source, right? 572 00:38:19,000 --> 00:38:22,000 So I can use any data model that's out there. 573 00:38:23,100 --> 00:38:26,800 Yeah, exactly. Okay so maybe let's talk about 574 00:38:26,800 --> 00:38:28,500 the economics of everything a little bit. 575 00:38:29,200 --> 00:38:35,200 So if at the moment I kind of i-i'm not actually guaranteed 576 00:38:35,200 --> 00:38:40,800 any redundancy is there any way to actually monetize data that I 577 00:38:40,800 --> 00:38:44,800 make available? Yeah. 578 00:38:46,600 --> 00:38:49,500 So right now is there any because it fully peer-to-peer 579 00:38:49,500 --> 00:38:53,400 Network and anyone has been up a node and replicate the data. 580 00:38:54,600 --> 00:38:59,600 So I think the the primary use case right now is not for people 581 00:38:59,600 --> 00:39:02,700 who want to monetize their data, it's more for like, hey, where'd 582 00:39:02,700 --> 00:39:05,100 our community. We want to make sure that are 583 00:39:05,100 --> 00:39:08,500 pending transactions or discussion governance, Forum 584 00:39:08,700 --> 00:39:11,100 doesn't disappear and then you can have like, multiple 585 00:39:11,500 --> 00:39:14,600 individuals in this. Wedding in this style, like 586 00:39:14,600 --> 00:39:16,200 providing redundancy for this data. 587 00:39:17,800 --> 00:39:20,300 I think monetization of data is something that's really 588 00:39:20,300 --> 00:39:23,600 interesting. It's not our core Focus right 589 00:39:23,600 --> 00:39:28,400 now and ceramic is primarily a Data Network right now. 590 00:39:28,400 --> 00:39:31,600 I think there's a lot of interesting combinations that 591 00:39:31,600 --> 00:39:37,500 could be made with financial systems, like ethereum and other 592 00:39:37,500 --> 00:39:41,900 blockchains where we can Leverage The Best of Both 593 00:39:41,900 --> 00:39:45,200 Worlds. Like maybe like N ftes and 594 00:39:45,300 --> 00:39:50,500 Jersey 20 tokens for doing some of the financial aspects of 595 00:39:50,700 --> 00:39:55,200 social media or knowledge, graphs, or something else. 596 00:39:55,200 --> 00:40:00,200 And then using ceramic for that really high throughput, scalable 597 00:40:00,200 --> 00:40:05,100 data system, Okay. Yeah, I think I understand where 598 00:40:05,100 --> 00:40:06,900 you're coming from. I'm still kind of, I think I 599 00:40:06,908 --> 00:40:09,100 still have a couple of mental disconnect. 600 00:40:09,100 --> 00:40:18,000 So if basically, if currently people kind of replicate data, 601 00:40:20,100 --> 00:40:26,200 you know, altruistically and are not compensated for this. 602 00:40:27,000 --> 00:40:30,900 How do I protect myself against censorship? 603 00:40:30,900 --> 00:40:34,600 How do I protect myself? Against kind of having people 604 00:40:34,600 --> 00:40:41,200 replicate my data either in complete lie or you know 605 00:40:41,800 --> 00:40:48,100 maliciously differently than I, I wanted it to be sword. 606 00:40:49,700 --> 00:40:51,300 Yeah. So you can certainly not. 607 00:40:51,300 --> 00:40:53,900 If you have your data, you're running your own ceramic note 608 00:40:53,900 --> 00:40:56,700 and have that data there. You can certainly not like 609 00:40:57,100 --> 00:41:00,200 guarantee that other nodes in the network right now can like 610 00:41:00,200 --> 00:41:02,400 are providing exactly the same data. 611 00:41:03,900 --> 00:41:07,900 But however, if there is one on as node in the network, any 612 00:41:08,900 --> 00:41:11,800 honest, no disease. Like is wanting to synchronize 613 00:41:11,800 --> 00:41:15,200 data, your data, would eventually be able to get up to 614 00:41:15,200 --> 00:41:18,800 speed and and find all of the data that your Note is 615 00:41:18,800 --> 00:41:21,000 providing. So, - there's one on us node. 616 00:41:21,000 --> 00:41:25,200 The data will be in the network, but how do I decide which one 617 00:41:25,200 --> 00:41:28,600 the honest version is right? So say my I was one of the 618 00:41:28,600 --> 00:41:34,500 hostess for my Dau community and my computer went up in flames 619 00:41:34,500 --> 00:41:37,500 and there there's like a couple of people who kind of hosted the 620 00:41:37,500 --> 00:41:40,800 same content and now they are in disagreement about which the 621 00:41:40,800 --> 00:41:44,200 real content is. Hmm. 622 00:41:44,400 --> 00:41:47,900 So the only thing that these nodes can do is to remove data 623 00:41:49,100 --> 00:41:52,600 and if your note that you know, as honest disappears, yeah. 624 00:41:52,600 --> 00:41:54,700 Then you can have to trust that they are providing all the data 625 00:41:54,700 --> 00:41:59,400 that was there before but they can't like say that hey this 626 00:41:59,400 --> 00:42:03,800 data is in Compton completely different or here's a bunch of 627 00:42:03,808 --> 00:42:08,700 new data like they can only say here's all the data or like a 628 00:42:08,707 --> 00:42:11,800 subset of the data because all the data is signed by the end 629 00:42:11,800 --> 00:42:14,700 users that are participants in the Darwin. that's not really 630 00:42:14,700 --> 00:42:19,700 something you can fake and so, Yeah, it's be clear like this is 631 00:42:19,900 --> 00:42:22,300 this is the current state of the network. 632 00:42:22,300 --> 00:42:26,700 We are planning to add a network incentive where either 633 00:42:26,700 --> 00:42:30,700 developers or communities or individuals can pay to make sure 634 00:42:30,700 --> 00:42:33,200 that that data is kept available in the network. 635 00:42:34,700 --> 00:42:38,300 Could you add something like a proof of completeness or so? 636 00:42:39,900 --> 00:42:45,600 yeah, I mean I think that's like kind of wood block chains to 637 00:42:45,600 --> 00:42:47,800 like they have this completeness because they have like this 638 00:42:47,900 --> 00:42:51,700 Global state in an end eventually consistent system. 639 00:42:52,200 --> 00:42:54,800 You can't really know if there's like some piece of data that 640 00:42:54,800 --> 00:42:58,400 someone's been hiding for a long time and then eventually reveals 641 00:42:59,600 --> 00:43:04,200 because there isn't like a the same completeness or time you 642 00:43:04,200 --> 00:43:08,200 kind of have to let go of some of those guarantees to get this 643 00:43:08,200 --> 00:43:13,300 more scalable system. Okay, that, that that's fair. 644 00:43:13,600 --> 00:43:18,000 So we kind of talked about potential ways to kind of 645 00:43:18,200 --> 00:43:20,700 generate revenue from streams as a user. 646 00:43:20,700 --> 00:43:22,400 What about Ceramics? We see how it does. 647 00:43:22,500 --> 00:43:26,300 How's ceramic financier? How's it going to be financed in 648 00:43:26,300 --> 00:43:28,700 the long run? Yeah. 649 00:43:28,700 --> 00:43:31,900 So as I mentioned ceramic is a fully peer-to-peer Network right 650 00:43:31,900 --> 00:43:33,900 now. Anyone can run a node there's a 651 00:43:33,900 --> 00:43:39,000 few aspects that we think it makes sense to introduce some 652 00:43:39,000 --> 00:43:43,000 kind of token model. So the aspect right now that is 653 00:43:43,000 --> 00:43:46,800 the biggest cost of the network as a whole and that three bucks 654 00:43:46,800 --> 00:43:49,800 Labs is currently subsidizing is the anchoring process. 655 00:43:50,800 --> 00:43:53,300 So like actually making the unchain ethereum transactions, 656 00:43:54,000 --> 00:43:59,100 that's something that we were, we wanted To decentralized as 657 00:43:59,100 --> 00:44:02,000 soon as possible. So that it's more of like a 658 00:44:02,500 --> 00:44:06,800 network activity where you participating in the network. 659 00:44:06,800 --> 00:44:10,900 You participate also to this process of anchoring things, so 660 00:44:10,900 --> 00:44:15,000 that's one aspect. The other aspect is the 661 00:44:15,000 --> 00:44:19,900 availability of data. So having the ability for users 662 00:44:19,900 --> 00:44:24,300 to pay for their data to be available and node providers to 663 00:44:24,300 --> 00:44:29,400 get paid by the network. To use like running node and 664 00:44:29,400 --> 00:44:32,900 keep some subset of the data network of data, in the network 665 00:44:32,900 --> 00:44:34,900 available. I think that's. 666 00:44:34,900 --> 00:44:36,500 That's also like key to understand it. 667 00:44:36,500 --> 00:44:43,200 Like once we have this logic and in system for nodes to be 668 00:44:43,200 --> 00:44:48,900 compensated, we're likely we can actually have each node. 669 00:44:48,900 --> 00:44:55,300 Only needs to provide a subset of the network and we can have 670 00:44:55,300 --> 00:44:58,300 this decentralisation without having the Throughput 671 00:44:58,300 --> 00:45:01,200 limitation, we have currently in blockchains. 672 00:45:02,300 --> 00:45:03,700 I hope that answered your question. 673 00:45:04,600 --> 00:45:08,700 Yeah it does answer my question and so you already talked about 674 00:45:08,700 --> 00:45:12,300 kind of the four different niches that you feel could 675 00:45:12,300 --> 00:45:15,100 benefit from building on ceramic. 676 00:45:15,600 --> 00:45:19,700 There's already a large number of projects already building on 677 00:45:19,700 --> 00:45:21,300 ceramic. Can you talk about kind of the 678 00:45:21,300 --> 00:45:24,800 ceramic ecosystem and which projects you excited about? 679 00:45:25,800 --> 00:45:27,700 Yes, I mentioned some of them already. 680 00:45:27,800 --> 00:45:31,500 So I think the largest one right now is get going that they're 681 00:45:31,500 --> 00:45:34,800 building this passport. Functionality on top of ceramic 682 00:45:35,700 --> 00:45:39,600 disco is building their data back back system. 683 00:45:40,900 --> 00:45:44,300 And in The Social Network in each, there is like orbis and 684 00:45:44,300 --> 00:45:46,300 cyber connect. They're both building different 685 00:45:46,300 --> 00:45:49,300 kinds of social networks or braces, definitely doing a bunch 686 00:45:49,300 --> 00:45:53,600 of interesting things there and they are using some other 687 00:45:54,800 --> 00:45:56,800 security. Multi-party compute system to 688 00:45:56,800 --> 00:45:58,900 actually store encrypted data on ceramic. 689 00:45:59,100 --> 00:46:02,000 So that's pretty exciting. They're providing like an SDK 690 00:46:02,000 --> 00:46:07,200 for people to integrate comments and that kind of social 691 00:46:07,200 --> 00:46:12,500 functionality in in similar way that was on the the previous 692 00:46:12,500 --> 00:46:15,300 Omen prediction Market, I believe it was called that we 693 00:46:15,300 --> 00:46:18,700 mentioned in the beginning. So what three bucks JS did way 694 00:46:18,700 --> 00:46:22,700 back. Lateral is a project in the 695 00:46:22,700 --> 00:46:25,700 design space that I mentioned before the building These 696 00:46:26,900 --> 00:46:31,400 scientific discourse graphs and the Dowling ecosystem, I 697 00:46:31,408 --> 00:46:32,900 mentioned that the safe decentralized. 698 00:46:32,900 --> 00:46:36,900 Safe registry. I think I think the Dowling 699 00:46:36,900 --> 00:46:43,500 space is there's a lot of opportunity there once people 700 00:46:43,500 --> 00:46:46,800 realize that this this like resilience aspect is actually 701 00:46:46,800 --> 00:46:50,500 rather important. And what's on the roadmap for 702 00:46:50,500 --> 00:46:52,400 this year? Yeah. 703 00:46:52,400 --> 00:46:58,100 So for this year next up is the release of composed to be on 704 00:46:58,100 --> 00:47:00,600 ceramic magnet. So that's something we're 705 00:47:00,600 --> 00:47:03,800 planning to go live with that if Denver. 706 00:47:03,800 --> 00:47:05,800 So that's the end of February early March. 707 00:47:06,700 --> 00:47:08,500 So that that's kind of what we're in the team. 708 00:47:08,500 --> 00:47:11,600 Are the most excited about right now beyond that, there's a bunch 709 00:47:11,600 --> 00:47:15,000 of improvements that we want to make in terms of developer 710 00:47:15,000 --> 00:47:20,800 experience and performance to the composted be graph database. 711 00:47:22,000 --> 00:47:26,900 And we're also working to make a lot of improvements on the core 712 00:47:26,900 --> 00:47:31,100 event streaming layer. So, right now there's a pretty 713 00:47:31,100 --> 00:47:33,800 tight coupling between the event streaming layer and compose the 714 00:47:33,800 --> 00:47:37,600 be, we want to decouple this. So the event streaming layer is 715 00:47:37,600 --> 00:47:41,700 more on its own and it essentially also enable other 716 00:47:41,700 --> 00:47:45,000 people to build databases or different types of micro 717 00:47:45,000 --> 00:47:48,700 services and so on. So those are like some of the 718 00:47:50,400 --> 00:47:53,500 most eminent Isis over the next year. 719 00:47:55,100 --> 00:47:58,700 I'm trying to wrap my head around this problem, that a lot 720 00:47:58,700 --> 00:48:02,100 of a lot of what ceramic is doing. 721 00:48:02,400 --> 00:48:07,600 Seems very similar to the to the work done by protocol labs in 722 00:48:07,600 --> 00:48:11,200 the ipfs file coin. I coin combo. 723 00:48:11,200 --> 00:48:17,400 So in my imagination of Ceramics, if I think like 724 00:48:17,400 --> 00:48:22,300 ceramic versus ipfs ipfs is similar right, like, I can put 725 00:48:22,300 --> 00:48:28,900 some data into ipfs, but unless I run my node, unless I kind of 726 00:48:28,900 --> 00:48:34,000 replicate my own data, it can get deleted, but nobody can mess 727 00:48:34,000 --> 00:48:37,500 with the Integrity of that data. That's the same seems very 728 00:48:37,500 --> 00:48:42,300 similar across ceramic and and ipfs ipfs. 729 00:48:42,300 --> 00:48:44,700 Does not provide eventual consistency. 730 00:48:44,700 --> 00:48:47,600 So there will be no Global ordering of events, but ceramic 731 00:48:47,600 --> 00:48:51,400 does. So that seems to be a big key 732 00:48:51,400 --> 00:48:55,600 difference, ipfs natively, did Not have. 733 00:48:56,500 --> 00:49:01,300 Yeah, a lot of incentives. Baked into it and ceramic. 734 00:49:01,500 --> 00:49:04,600 As of today, also doesn't have incentives baked into it. 735 00:49:05,100 --> 00:49:10,900 But then protocol Labs build file coin, where They were 736 00:49:10,900 --> 00:49:14,200 incentives. And people can basically be 737 00:49:14,200 --> 00:49:18,100 guaranteed that any data, they put into ipfs, will be 738 00:49:18,100 --> 00:49:21,600 replicated by file called, and made available and ceramic also 739 00:49:21,600 --> 00:49:25,900 seems to make take steps in in that kind of Direction. 740 00:49:26,500 --> 00:49:28,900 I'm trying to understand. Like what's the meaningful 741 00:49:29,100 --> 00:49:34,900 difference between between these two ecosystems and why would 742 00:49:34,900 --> 00:49:37,900 developers prefer one of the ecosystems over the other in 743 00:49:37,900 --> 00:49:39,200 this case, why would somebody prefer? 744 00:49:39,800 --> 00:49:44,200 Take over the other other ecosystem, perfect. 745 00:49:44,200 --> 00:49:48,700 So I will comment on like what these systems do today to my 746 00:49:48,700 --> 00:49:53,300 understanding at least in the protocol apps ecosystem and and 747 00:49:53,300 --> 00:49:57,100 what the differences are today because things think things are 748 00:49:57,100 --> 00:50:00,300 likely to change in the future. So I believe this is really 749 00:50:00,300 --> 00:50:02,300 good. If you have like static files, 750 00:50:02,300 --> 00:50:04,800 right? I can put a file, I get the hash 751 00:50:04,800 --> 00:50:09,300 or what they call a CID of that file and now I can synchronize 752 00:50:09,300 --> 00:50:12,900 that across The network and do a bunch of fun things for that. 753 00:50:12,900 --> 00:50:17,900 And I have integrity proof in this hash But there's no way to 754 00:50:17,900 --> 00:50:20,600 like update this file because if I update the file you get a new 755 00:50:20,600 --> 00:50:23,600 hatch, right? And so there's no way to have 756 00:50:23,600 --> 00:50:29,800 like a an easy way to keep track of updates in. 757 00:50:29,900 --> 00:50:34,900 In ceramic, our core Focus has been actually one important 758 00:50:34,900 --> 00:50:37,900 thing to know is actually ceramic is using the same data 759 00:50:37,900 --> 00:50:41,900 model as ipfs called, I PL D and that's how we represent. 760 00:50:41,900 --> 00:50:47,100 This hatchling event log and the main thing we add on top of that 761 00:50:47,100 --> 00:50:51,000 is that we provide signal like a signature system. 762 00:50:51,000 --> 00:50:55,800 So we have attribution of like who created words and I can't 763 00:50:55,900 --> 00:50:58,100 like let me go in a little bit in how that works. 764 00:50:58,100 --> 00:51:01,300 So essentially when you come to an application that uses 765 00:51:01,300 --> 00:51:05,500 ceramic, there's a session key created in your browser, you 766 00:51:05,500 --> 00:51:09,400 sign sign in with the theory of message with your wallet, the 767 00:51:09,400 --> 00:51:13,100 basically delegates some permissions to this session key 768 00:51:13,400 --> 00:51:17,100 on behalf of your ethereum a This or other blotching actress. 769 00:51:18,100 --> 00:51:23,000 And now the user can actually use the application, like they 770 00:51:23,000 --> 00:51:26,300 would use any web publication without having to like for every 771 00:51:26,300 --> 00:51:28,900 like and for every comment there's like a pop-up that we 772 00:51:28,900 --> 00:51:31,100 need to sign in their wallet like that, the user experience 773 00:51:31,100 --> 00:51:34,900 wouldn't be great. So I think yeah, that's that's 774 00:51:34,900 --> 00:51:38,600 like one of the key differences is that there's like focus on 775 00:51:38,600 --> 00:51:42,400 those making the user experience of how we do attributions really 776 00:51:42,400 --> 00:51:45,400 well. And in ipfs natively, you do And 777 00:51:45,400 --> 00:51:48,100 really have a distribution and in, currently involved coin, 778 00:51:48,500 --> 00:51:52,200 it's really good for storing large files in large chunks of 779 00:51:52,200 --> 00:51:56,200 data, in a kind of backup manner, but it's not right now. 780 00:51:56,200 --> 00:51:59,900 Like something you can easily query and build like feature, 781 00:51:59,900 --> 00:52:03,500 Rich applications on top. And so that has been our core 782 00:52:03,500 --> 00:52:08,200 focus with ceramic. And so we see, we see our, our 783 00:52:08,200 --> 00:52:14,300 technology, as kind of like, it's kind of taking the best of 784 00:52:14,300 --> 00:52:17,300 like ethereum and Ifs emerging that to create a system that is 785 00:52:17,300 --> 00:52:20,600 like enables developers to really build something 786 00:52:20,600 --> 00:52:26,400 meaningful. I also compare ceramic to orbit 787 00:52:26,400 --> 00:52:33,800 a little bit because this this fundamental idea that they 788 00:52:33,800 --> 00:52:38,100 should be data and then they should be lot of, like, people 789 00:52:38,100 --> 00:52:41,700 should be able to build you eyes for for interoperable data. 790 00:52:44,000 --> 00:52:46,700 This actually this value kind of repeats in many different 791 00:52:46,700 --> 00:52:50,900 ecosystems and orbit is another ecosystem in, which this, this 792 00:52:52,200 --> 00:52:55,800 This value repeats and essentially honor, bit the data 793 00:52:55,800 --> 00:52:58,200 you put on herb. It is also such that many people 794 00:52:58,200 --> 00:53:00,100 can build different device to it. 795 00:53:01,700 --> 00:53:05,000 So what? Of course, when you look at the 796 00:53:05,000 --> 00:53:07,500 difference between herb it and ceramic. 797 00:53:08,200 --> 00:53:13,300 I think like the trade-off space here is something like in orbit, 798 00:53:13,300 --> 00:53:17,100 you can push private data to Herb it quite easily. 799 00:53:17,100 --> 00:53:19,900 Like it's, it's designed for for privacy. 800 00:53:19,900 --> 00:53:23,300 That's, that's a strength that orbit offers along with data 801 00:53:23,300 --> 00:53:28,500 interoperability, but then the big big challenge of weakness of 802 00:53:28,600 --> 00:53:33,200 herb it offers on the other side is, It's a completely new tech 803 00:53:33,200 --> 00:53:37,100 stack right from the ground up, starting from operating system 804 00:53:37,100 --> 00:53:42,400 to networking protocol. And so, and to even programming 805 00:53:42,400 --> 00:53:47,500 language. So it it's the case that the 806 00:53:48,300 --> 00:53:52,500 ambition in herb, it is so big that they just might end up 807 00:53:53,100 --> 00:53:57,100 easily out competed by much simpler systems. 808 00:53:57,100 --> 00:54:00,600 That also provide application interoperability like like 809 00:54:00,600 --> 00:54:04,200 ceramic So that's how I tend to view that rid of. 810 00:54:04,200 --> 00:54:09,100 What are your thoughts on how ceramic and orbit differ from 811 00:54:09,100 --> 00:54:12,800 each other? Yeah, so so I'm I'm afraid I 812 00:54:12,800 --> 00:54:16,000 can't make like super neurons comments here because I'm not 813 00:54:16,300 --> 00:54:20,900 intimately familiar with irbid. But from what I understand you 814 00:54:20,900 --> 00:54:25,000 have your kind of own kind of a virtual private server with 815 00:54:25,000 --> 00:54:28,700 orbit, which you could run on your computer or someone else's 816 00:54:28,700 --> 00:54:32,000 computer and that there you have the private data in the way, 817 00:54:32,000 --> 00:54:36,900 which we talked about earlier, where yes, it's private. 818 00:54:36,900 --> 00:54:40,300 If you host it yourself or you trust the person that hosts it 819 00:54:42,500 --> 00:54:46,300 But you don't necessarily have like public verifiability, and 820 00:54:46,300 --> 00:54:49,700 so that's, that's like a core thing that we've been focused on 821 00:54:49,700 --> 00:54:53,400 in ceramic, like how can we have public verifiability and then 822 00:54:53,400 --> 00:54:55,500 add privacy features on top of that? 823 00:54:55,500 --> 00:54:59,400 But since we're coming from like the ethereum blockchain space, 824 00:54:59,900 --> 00:55:02,300 the aspect of public verifiability and that 825 00:55:02,300 --> 00:55:07,500 neutrality that provides is been one of our kind of core 826 00:55:07,500 --> 00:55:12,600 principles. So I've also seen that setup 827 00:55:12,600 --> 00:55:17,400 make raised a quite a big funding around in the in the 828 00:55:17,400 --> 00:55:21,100 recent past. So how was that funding around 829 00:55:21,100 --> 00:55:23,600 structured? And what what what what did 830 00:55:23,600 --> 00:55:28,100 people buy in that funding round essentially and what kind of 831 00:55:28,100 --> 00:55:32,800 incentives? Does, does your funding round 832 00:55:33,000 --> 00:55:37,400 imply for the future? I'm probably not the best person 833 00:55:37,400 --> 00:55:41,900 to answer this question because it was led both mainly by my 834 00:55:41,900 --> 00:55:48,200 co-founders. But yeah, what we essentially 835 00:55:48,200 --> 00:55:54,700 sold is equity in the three bucks Labs company and there's 836 00:55:54,700 --> 00:56:01,100 also a token warrants in a potential token, in the ceramic 837 00:56:01,100 --> 00:56:05,500 Network. Fantastic Joey. 838 00:56:06,600 --> 00:56:11,500 So if someone wants to build on ceramic or on a ceramic node, 839 00:56:12,100 --> 00:56:16,800 where should they go? To kind of find out more about 840 00:56:16,800 --> 00:56:20,000 documentation and speak with people who are already doing 841 00:56:20,000 --> 00:56:22,900 this? Yes, I think the main place to 842 00:56:22,900 --> 00:56:25,700 go for everything as ceramic top Network. 843 00:56:26,700 --> 00:56:32,100 And if we specifically interested in developer 844 00:56:32,100 --> 00:56:34,400 documentation, Ian's, we have a developer portal at 845 00:56:34,400 --> 00:56:36,400 developers.google.com a cloud Network. 846 00:56:37,800 --> 00:56:40,500 Good, fantastic, thank you for coming on. 847 00:56:40,500 --> 00:56:43,700 Joey this is super interesting. Yeah, thank you very much. 848 00:56:43,700 --> 00:56:48,200 This was great fun. Thank you for joining us on this 849 00:56:48,200 --> 00:56:50,600 week's episode. We release new episodes every 850 00:56:50,600 --> 00:56:52,600 week. You can find And subscribe to 851 00:56:52,600 --> 00:56:56,400 the show on iTunes Spotify, YouTube SoundCloud or wherever 852 00:56:56,400 --> 00:56:58,800 you listen to podcast. And if you have a Google home or 853 00:56:58,800 --> 00:57:01,600 Alexa device, you can tell it to listen to the latest episode of 854 00:57:01,600 --> 00:57:05,300 the epicenter podcast, go to epicenter dot TV /, subscribe 855 00:57:05,300 --> 00:57:08,100 for a full list of places where you can watch and listen, while 856 00:57:08,100 --> 00:57:10,500 you're there, be sure to sign up for the newsletter so you get 857 00:57:10,500 --> 00:57:12,700 new episodes in your inbox as they're released. 858 00:57:13,400 --> 00:57:15,800 If you want to interact with us guests or other podcast 859 00:57:15,800 --> 00:57:18,600 listeners, you can follow On Twitter and please leave us a 860 00:57:18,607 --> 00:57:21,400 review on iTunes helps people find the show and we're always 861 00:57:21,400 --> 00:57:24,500 happy to read them but thanks so much and we look forward to 862 00:57:24,508 --> 00:57:18,600 being back next week. On Twitter and please leave us a 863 00:57:18,607 --> 00:57:21,400 review on iTunes helps people find the show and we're always 864 00:57:21,400 --> 00:57:24,500 happy to read them but thanks so much and we look forward to 865 00:57:24,508 --> 00:57:25,500 being back next week.