 So, I'm Alex Carazes, I've been at PL for three months now and just diving into a lot of these things and learning a lot of these issues. I think one of the first things that I did when I got to PL, I was like, when do we start crunching the data, you know, and then that's why I was really fascinated by Baco Yao, and just really a proponent of that, so try to cover a few of the economic issues that we've identified so far. So, you know, in order to do a good job like this, I think everybody realizes that we have these stakeholders, and if we're going to model this system, we would need to understand that. This is probably not everybody, I saw some others listed earlier, but certainly the storage providers, compute providers who initially will be the same people, if I understand it correctly, clients who can be both data scientists, but can also be sponsoring organizations, a lot of different types of clients, and I think that could be broken out further later, validators who check the data, check the compute, and then data owners, and that could also be processed data owners, so if somebody does something interesting to some raw data, stores it on the network, that could be another interesting stakeholder. So we try to do what we call a value flow, try to understand where the value flows between all these participants, and certainly the clients are basically sending fees to everybody, at least in this initial model. The validators are giving the clients verified results, that's what they want, and the clients are sending the verifiers some fees occasionally. Storage providers are exchanging storage and data, and sometimes the compute providers are creating large data sets that would result in a storage contract, and that's an important aspect to this, why they would want to do this, but also they're probably making some money from doing the contract. Stimulus is minting of new coins, but other types of stimuli, that's not just what stimulus can be, it can be reputation, other value that they can inject into the system. So please stop me if you have other arrows you want to list, I think this is a very incomplete set of arrows, incomplete set of value flows, because we're just getting started to understand this, but I think this is a good start. Stimulus could be making new tokens, could also be improving your reputation, or having a reputation system that gives you the stars, it gives you the reputation. Cool, and that's where we're going with this. So, incentives are not just about tokens, but they're also about staking, to signal that you have compute available, so you're saying, hey, I'm here, please pay attention to me for compute validation, so that you could be slashed, or you can show that you're in the game, I can lock drop your storage tokens to join, product market fit, and reputation is contextual, and we need to have strong use cases to build on that. So we looked at the scheduler of the Bakuyao, and I think the way to think of it is a multi-dimensional marketplace, and so there's a lot of components to that, a lot of factors that make the decision to choose one provider, or to choose a series of providers, distance to data, the ability to store your results, if they're large, the compute capabilities, these are very, I know that it's very early in the Bakuyao model, but long-term, I think we need to look at a lot of these points. So price point, obviously, maybe different providers want to offer different prices to do compute, so that'll be competitive, track record slash reputation, and geographic location for compliance, somewhat similar to data, distance to data, but not exactly the same. So then we wanted to look at the performance metrics. So the amount of compute, how do we know Bakuyao is doing its thing? How do we know that it's succeeding? And so if we can attribute to Bakuyao the amount of compute that's being processed, that's being used on the network, which should be pretty easy to do, then we can see what its effect is, what it's giving us. Unique data sets, for example, combining Landsat data with other forms of geospatial data, a lot of data might be sitting on the network not doing anything. If we increase the access and use of those data, that's a success, that's a win. Tokens exchanged, number of nodes offering compute, these are very basic, but they are good measures. And then new storage generated, as I mentioned, a lot of these processes will create new data sets and those can be quantified and we can show that we're having success there. So I think everyone's seen this triangle more than a few times today, and we did a survey of Web 3 COD systems, and I saw some really nice work on that earlier today as well, but I think one of these three corners that's being ignored a lot is the privacy, and this could be a really nice sweet spot for us because of all the protected health information and other types of data that people aren't paying attention to, that aren't secured necessarily on Web 2 type approaches but could be secured more on Web 3 if we can figure it out. I think a lot more of the action seems to be among validation and performance, it seems to be where the focus is. It's not like we have to commit to just one of these models and sacrifice the third corner of that. We could have it tweakable so that you could choose which model. If you're doing biomedical processing, you can emphasize privacy, so we don't have to have one size fits all approach to this, it'll take some flexibility in the programming model. I don't know why that's not moving. One second. Slide show? There it is. I don't think it makes a lot of sense to go over some of these other COD systems. I think we had a good review of that earlier today. I think it would be interesting to start to place them in that triangle pyramid and hopefully we can do that as a discussion point now. I think again most of them seem to go along that validation performance metric. Again, so if we're not addressing the privacy or if no one's addressing the privacy aspect of this, this could be one of our verticals. It would be a nice fit. The pain points. So this may or may not be true. I mean storage providers will have to divert some of their resources, some of their efforts to become compute providers. Hopefully it's a holistic improvement for them that allow them to diversify their revenue stream possibly. Maybe some of their equipment is sitting around unused at times. Hopefully. So if the programming model is flexible enough to allow them to run processes at their leisure or just in time, that would allow them to utilize these unused resources a bit more. So also the compute providers have a different compensation model than storage providers. It's more of an on contract deal for them, right? So they don't get to participate in making new block sets and things like that. The storage providers might get the chance to do. They're just doing the fee for compute. So it's a little bit different. This is one that I've experienced and it's early, but you know, it's hard to find where the data sets are that you want to use on the network. And so I think that alongside the creation of the technology, we need to make sure that people can find these data sets that users can find the data sets and do something with them. So, you know, just going into this blind that you'd be, well, what am I going to do? You know, I'm trying to answer a business question. I want to know where to find the data that can help me answer that. And so it's a big sea of data and it's very hard to boil it down and find what you want, you know? And so, I mean, I did a lot of geospatial stuff and that's why I'm so fascinated by Landsat. So glad that people are talking about that as well. But, you know, I need to find open street map data. I need to find other bits of data to combine with that so that I can do my machine learning workflow and to get something interesting out of this. Another pain point I think, and I wanted to bring that up earlier, it looks like you're starting to address that, but, you know, when I've done data science, usually I submit the job and go, oh crap, what did I just submit, right? And so then you got to crash out of it, you got to figure it out again. And also, you've got to be able to check your results. And so I think that's tough, you know, with the bits of text and things like that. It's easy, but if we're talking about an image data set or something else, you know, you have to have a good way to access those data and to check them out. And then I think that validators may have a hard time distinguishing between, you know, a programmer's mistakes or other types of errors in code and data and actual malicious behavior. So I think that could be a tough one for the validators. So let's talk about Landsat, because I think it's a great initial product or initial data set for us to work. I think people have been talking about it clearly. But I wanted to mention that we get a whole new EarthScan every 16 days. So this is a giant data set that just keeps coming, you know, the pipe is just filling up all the time. And so what people want to do with Landsat is look over time. And so I had a hard time finding the Landsat data on the network. And, you know, then when somebody says we have Landsat, you know, that means that maybe they have one data dump from one, one scan, this kind of thing. But if you really want to store Landsat, you need to store a whole bunch of data over time. And most of the useful use cases are time based. And I'll also mention that 70% of the Earth is covered with clouds at any one time. So when you talk about cloud processing, that's exactly what we're doing here. So people spend a lot of time and a lot of effort pulling out these clouds. It's like, how do you do it? The way you have to do it is go back one time point and hopefully find the same pixels that don't have clouds and then shove those in and then try to make a data set. This really five scans long, you know, by the time you get there. And so we have the cloud belt. Everybody loves this volcanic picture. That's just there for show. But these clouds are a big problem. And then there are a lot of other processes that people do on top of that. So cloud removal, optical corrections. One of the things that's very deterministic and very easy to compute is this vegetation index. And, you know, as a user of Landsat, I just wanted the vegetation index. I wanted to see the disturbed ground. My personal, my use case back when I did use Landsat was to find disturbed Earth and try to find new construction of new buildings. So make a building index. And so this is something that I feel that we could do. Or we could find something that wants to do that too. But these are the derivative products of Landsat that are of interest. So it may behoove us to have Landsat, to have Filecoin compute some of these things and then output these as useful data. You know, like there's no reason for everybody to do cloud removal on the same tiles. We could just do it once. And so, and we had some discussion about how to track these data assets if somebody does cloud removal. They could become a data provider then or a data owner and sell the data. I'm not sure that's quite legal with Landsat. We have to figure that out. But storing it would be really useful. So change detection, another really pretty easy, nothing's really easy in geospatial data. But change detection is just taking two images and finding out if they're different and finding the pixels that are different so you can hone in on where they are. So very easy process could be very useful to the geospatial community as a whole. And then I just also want to emphasize that Landsat is a really good fit for the mission of Filecoin. I mean, it's some of humanity's most important data. We're in an environmental crisis so this is something that everybody really wants.