All right. Hi, everyone. Thank you for coming. Congrats on getting in. So my name is Ily Grigorek. I work on the Google Chrome team where, in my day-to-day job, I focus on making the platform faster. And also, we're working on the APIs and infrastructure enable developers, like yourself, build nice and fast user experiences. Although, I guess I should say fast and resilient, because as it turns out, building the fast path is not enough. And a good example of this is a pattern that I very frequently see across many different teams go something like this. The team really buys in into the vision of performance matters. They understand it. They internalize it. They have the metrics. And they do all the best practices. They optimize their app. They release it. They put processes in place. They have audits. They even gather some real user measurement data to understand how the app is performing. And then, lo and behold, they look at the data and they say, hey, we made everything fast. We did all the things you told us. But despite that, we still have these reports. When we look at our data, there's this really fast device. In fact, maybe even the device that I've been testing on locally, and it's not meeting my frame target, our 60 FPS limit. Or maybe the app is on a fast network, but it's still loading really slowly. What is going wrong? Like, I did everything right. Is there a bug somewhere in Chrome? Maybe it's the carrier. Maybe there's the phones at fault. Do you know of anything that could have caused this? And my answer most of the time is like, yeah, probably. Like, let me tell you, there's a million things that could go wrong. But I think you may be asking the wrong question. And fundamentally, the problem here is that, yes, you've made the app fast, which is great. Congratulations. You're doing all the things right. But you forgot to make it resilient. And this is a subtle shift and an important shift that I think we need to internalize and understand because our intuition fails us. Our intuition as developers often fails us in this regard. So what is resilience? If you look at the dictionary definition, it says it's ability to maintain an acceptable level of service in the face of faults and challenges to normal operation. OK, what's an example of a fault or a challenge to normal operation? There are millions of them. For example, it could be that the capacity within the carrier is limited. Maybe there's just a lot of people at one event, and there's just only so much spectrum that you have. Maybe you have an unresponsive server. So maybe your provider is overloaded. Maybe there's a network outage. Maybe the device is in a low power mode. And as you will see later, when the device is in low power mode, it runs slower. Maybe there's a background process on the user's app or on the user's phone, rather, that just kicked in. And all of a sudden, your app is not performing as well. Maybe it's under memory pressure. The point is there is a million things that can go wrong. And they span from right on the device that you're holding in your hand to somewhere in the network, maybe in the carrier network, maybe out on a public internet to maybe on your server or maybe even in your database. There's a million things that can go wrong. And there is no special carve out here for, hey, but the user is on a 4G network, or the user has the latest flagship phone. It doesn't matter what device you have or what network you're on. These things can happen. And they do happen. And that's the thing that we need to understand. So the message here is that fast is not enough. And I'll try to, I guess, motivate why that's the case. Fast devices are often slow. Fast networks are often slow. Variability in performance, and this is the critical aspect, makes things feel slow. And despite our best intents and best practices and all the things that we do to engineer great experiences, variability is really what kills the user experience because they don't get a reliable performance out of the application. But despite all these things, it is still possible to build great user experiences. And we'll see some examples of that. So there are some simple patterns that we can apply once you understand what these problems are that will help you build much, much better applications. So let's actually take a step back and kind of walk through from beginning to an end, how do we evolve to this point, and what kind of practices we have in place. In my day-to-day work, I actually get to work with many different teams, both within Google and outside of Google. And I kind of, over time, developed this three stages of performance enlightenment, as I call it, where when I go and talk to the team, I kind of see them in one of these stages. First one is performance as a bug. As in, I get to talk to them or they reach out to me because they previously did not care about it, but all of a sudden something has happened that caused it to be such a big issue that it's like, okay, let's fix it, right? Like let's add performance to our app. Okay, that's damage control. The second one is they internalize that performance is a feature just like anything else. So they start work on robustness or adding robustness to the app. And then finally, the third stage, which I'm hoping to convince you today, is this thinking about resilience and what you do have to do to get to that stage. So let's step through it one by one. Performance is a bug, right? So as I said, most of the time this is notable or performance is notable by its absence. You've accrued enough technical debt or something has gone wrong, at which point things just fell on the floor, the users are complaining, the product manager is angry and all of a sudden like there's a fire drill to fix performance. And performance is fixed after the fact in as much as you can actually fix a faulty foundation, right, and I intentionally put the Tower of Pisa as a metaphor here because if you're looking for some fun reading, I encourage you to actually go and read about some of the engineering efforts that have gone in to keep this Tower at just that angle. They can't actually like make it straight. They probably don't want it to, to be honest, right? Because it's a landmark. But they understand that despite all of their engineering, they've literally poured tens of millions of dollars, not hundreds of millions of dollars to try and keep the building upright. And despite all that work, they know that the best solutions that they come up with today will only last 50 years, right? So it's like they're just paying that technical debt and they know that this solution will still fail. And that's kind of like, that's similar to performance. It's very often the case that you can't add performance after the fact, just like you can't add security after the fact or accessibility into your application. You really have to think of it from the very early stages of your development. And that's where you get kind of that second stage. It's performance is a future. The team really understands this from beginning to an end. So if you're building an application, say, for a market where you expect lots of users with limited connectivity or poor connectivity or just very sensitive to data usage, for example, your UX designer, despite the fact that they really want to put that like really pretty and nice looking cover image on the top of your page, because it's just like, it appeals, it conforms with your brand and all the rest. They know they can't do that, right? Because it'll hurt performance. It'll hurt the actual experience of the user. And then once you get to the next stage, developers understand that they need to pay attention to performance. And finally, when you release the app, you have processes in place to kind of complete that cycle, monitor the performance, detect the fact that you may have regressed and change that or fix that. So it becomes a learning curve, right?  And this kind of sets us up on a path to what I call a robustness where you develop a collection of best practices that will help you build great applications and continue delivering great applications. And there's a long list of examples that we can talk about of like what goes into this sort of process. For example, code reviews, like the very basic form of just preventing failure, right? Like we're smart developers, but even the best of us make mistakes, silly mistakes, performance mistakes. And it's just good to have your friend or coworker check your code just to sign it and check it. That's an example of building a robustness. We then also have test suites, which detect when we regress some other component of the app that we didn't even expect to regress when we make a change in point A and something fails in B. We add redundancy into the system. So we do things like duplicate data across data centers. We have backup servers. We develop all these things such that if one component fails, the system as a whole continues to function. We add processes to actually mitigate failure. So for example, you have your spike in traffic. You don't just collapse because you've overloaded all your servers.  That is still significantly better than failing all 100%. It's a bad outcome, but it's significantly better. So you build these things into your process. And then finally, you even simulate failures. So at Google, we take down entire data centers intentionally to make sure that the applications that we run are not built to just run in one data center. And your application should be able to continue working if we just take out an entire data center. And this is a regular far drill that all teams have to go through.   Like as engineers, this is all the best practices that we've been taught to do. Except let's consider this case. So let's say you are building an awesome app, right? And your awesome app is in fact, pretty awesome. You have really good uptime, which you're measuring continuously. And if you look at, say, your response times for your service, you see a 250 millisecond response time for a 75 percentile and two seconds for 99th, which by all means and measures is pretty good. These are pretty tight bounds. You understand kind of the performance curve and all the rest. Now, the app is also fairly complicated. There's lots of functionality. So you have about 16 critical resources. Why 16? According to HSP Archive, the median number of critical resources on the web today for a median web page is 16. So I'm just using that as an example. So let's just go with it. Say we have 16 resources. I have a question for you. What fraction of page loads will take longer than two seconds? It's kind of a tricky question. Let's do some math. I know you didn't sign up for math, but we're gonna do some math. So we know that 1% of the requests will take greater than two seconds. That's our 99th percentile. So let's assume that the requests are actually independent and we're making 16 of them. What is the probability that all 16 requests finish in less than two seconds? And then in order to get our actual answer, the page will take more than two seconds if any one of those requests takes more than two seconds. We can crunch the numbers, you can verify the math and the answer is 15%. This is where I shouldn't start like a really, really long, one minute long dramatic pause because 15% should be pretty surprising, isn't it? Your 99th percentile is two seconds. You have 16 requests and roughly one in six or one in seven page loads will take more than two seconds. I find that very surprising. It does not fit my intuition. I have to do this math every single time just to prove myself that this is actually right. So what can we do to fix this? I have three suggestions. You should reduce the number of critical requests and then reduce them again and then reduce them again, right? Which makes sense. The fewer dependencies you have like this, the better the odds that you will not hit this case. But let's say you actually do take your page from 16 requests to five, to five critical requests. We can repeat the same math and you'll find that the fail ratio for this same test is about 5%, which means that we've taken it from one in six page loads to roughly one in 20. Definitely an improvement, but I think you'll still agree that that's pretty surprising and not very good. We should be able to do better. So one interesting takeaway here is robustness, right? Like we built a system which has very high uptime, very good latency, tight bounds, but it's not sufficient. We still have this experience where one in 20 or one in six, some significant portion of our traffic is seeing this two second load. So it turns out we actually have a lot of experience with this and Jeff Dean, who works on Google search, has given a number of really good presentations and he published a paper that I really encourage you guys to check out after this talk. You can find it, there's recordings and there's also the presentation that he's given. So he basically sets up this very problem and describes the case of a search query comes in into Google search. In order for us to search the web and give you back the results, we actually fan out that query into hundreds if not thousands of servers. So you can think of like verticals. You have images in local and we kind of dispatch those requests. And in order to compose the page and give you back that set of results, we wait for all the responses to come back and then rank them and give you back the top 10 blue links. Seems simple enough, except as you can imagine, this fan out was pretty large. So it's not just 16 requests. In the case of search, it's hundreds if not thousands of requests. And he basically demonstrates in that paper in his presentation that, say you have 100 requests, 63%. He actually sets up the same numbers of two-second 99th percentile. If you make 100 requests, more than half of your search queries will take more than two seconds, which is unacceptable. And he walks through, I think in a very compelling manner for why you cannot fundamentally fix this variability. He can certainly make your latency tells even tighter. He can spend more money on better hardware, but fundamentally you cannot eliminate it. There's virtualization. There's a million reasons why the request may take longer than what you'd expect. But he then goes on to say, but we can still fix this. We can build processes or build additional functionality into search that will fix this problem. As an example, he gives a long list, I'm gonna highlight three. He says, well, you know what? If we only search 99% of the search index in 200 milliseconds, we don't have to wait. We'll just return the results from the 99%. And in this case, the user probably won't even notice. It's not the best outcome, but it is still better, objectively better than waiting multiple seconds to give you back 100% accuracy. So that's one example, right? Just tolerate inexact results. If you're composing a homepage with many different components and many different widgets, perhaps you don't wanna wait for every widget to come back before you display the page. You can set a cutoff and say, every widget must come back in this amount of time. And if it doesn't, I will deal with it and I'll be smart about it. So for example, Amazon has this policy when they're composing their homepage. Hundreds of components, there's a bound on every request. And if one of the components is not responding, it'll just won't show up in a page. And that's fine. So they deal with it explicitly. You can abandon these slow subsystems. You can say, you know what? The spelling correction is taking really long time for whatever reason. Maybe when it's used to bug, maybe there's something wrong. We're just gonna drop that functionality. So it's dropped at runtime. And search knows that the search app and the search infrastructure knows to disable this. And further, it actually is able to adjust to this dynamically. So it's not that some engineer on your team gets paged and says, hey, the subsystem is kind of really, really slow at the moment. Do you wanna do something about it? Instead, the search system says, well, you told me what your latency target is. I'm gonna enforce it. This component does not conform to it. So I'm just gonna take it out. And we've already, before we put it into place, talked about what that means. We talked about the fail case and what it means to disable your part. So this is kind of interesting because fundamentally the message here is you have these unreliable components. Some of them will fail, some fraction of the time. We cannot fix that. But despite that, you can still build a great user experience. So this is great, right? But if you actually think about it, our problem or our problem space as well developers is even more complex because what I just described kind of looks at that green box on the left where Jeff fixated on a search query comes in into the Google infrastructure. But as developers, as what developers, we also have to deal with the other components which is the device where application is running. And then there's all this stuff in between which is the public network. So let's talk about that. Because that's another huge source of variability and performance. So today you can walk in and pick up a couple of different phones in different stores around the world, right? Perhaps around this area you can walk in and get yourself a Nexus 6P which has lots of great functionality, good great performance, lots of storage, lots of memory and all the rest. Just as likely somewhere else in the world somebody will walk into a store and pick up a device on the left which has significantly fewer resources, right? And of course some of us are sitting here thinking like, yeah, you know, it's kind of crazy that we have such a disparity but like honestly, really, more users are buying towards kind of the high end, right? Or like this stuff is an outlier, the $33 phone. And maybe you were sitting in this very room in a previous talk where Tal was talking about building for the next billion. And I think she very compellingly illustrates the problem. So she has a slide where she shows where are the new users coming from? So for example, in the past year the color coding here shows the darker cues represent the density of new users coming online, right? Anything stand out there? Well, we have India and China, right? Like as one example. Four contacts, right? Let's dive a little bit deeper. The number of new internet users that came online in India in last year is a third of the US population. It's kind of crazy, right? Like that's a lot of users. And if you drill into the data a little bit more, you'll find that in terms of where the users are still that are not online and will be coming online, it's India, China, Indonesia, Pakistan, it's all these countries. So it's not just the next billion, it's the next several billion. That's where the growth is coming from, that's where the new users are picking up their phones. And then she basically goes on and tells you about the constraints of that environment. And I think one of the constraints that you'll discover is people there are much more cost conscious. So they are in fact picking up these phones towards the other end. They're not picking up to the Nexus 6, they're picking up the other phone. And that should scare you a little bit, right? So fundamentally, we have kind of two competing trends the way I think about it. We have a trend for features and performance, that's what we hear about as developers most of the time, like every six months there is a new shiny thing with more cores, more cameras, more finger sensors, whatever, right? Smell testers, I don't know. They're gonna come up with something crazy. And on the other hand, there is a trend for price. And there, fundamentally, they're trying to optimize price. They're not, yes, they're upgrading the components. Yes, they're getting a little bit faster, but first and foremost, the question is, can I make this phone cheaper? So the way I think about it is there's an expanding range of performance. The tail or the head of the curve is accelerating because we keep adding these new things, new features and new capabilities and speed and performance. But the other end is only slowly moving forward, right? So the actual range of performance is getting wider and wider and wider, which creates some problems for us as developers. So I call this the performance inequality gap, right? The flagships will continue to accelerate, cost is critical and this range will only get further apart. So, okay, fine. Let's say we actually do have the Nexus, right? We have this great phone. It can do all kinds of amazing things. It can decode high resolution video. It can allocate lots of memory for editing video or doing anything else. It can connect to all the latest 4G infrastructure and get you great performance. It's all great, but I have a question for you. Will it? Because even though you have this device, there's a bunch of constraints that may conspire against you. So for example, on the previous slide for Nexus XP, it's advertised as a octa-core. So there's eight cores in the device. If you actually drill in a little bit further, you'll find that the architecture in these new phones is what's known as big little. So there's actually two different sets of cores. There's the big cores and the small cores. And it's not about eight cores is better than four because you get eight times or two times the performance of the four cores. It's more that we've added these big and small cores because we need to optimize for power efficiency. So it's not the CPU cycles. It's the power efficiency. It turns out that it's significantly better to run a workload on the slower clock rate because it's just so much cheaper on your energy than it is on the fast cores. So these devices actively migrate your workloads between the high cores or the big cores and the small cores. And that's a big source of variability and performance right there. So in fact, the way I kind of think about it and I think the way it's more helpful to think about this is think of the device, like say you have a dual core device, right?  Say the phone needs to preserve energy. It can just say, look, I'm just gonna run at one core. And we'll look at this in a second. When you have a say quad core device, it'll probably have two fast cores and two slower cores. And the way I think about it is almost two separate subsystems. It's not that you're gonna be running all four cores simultaneously. That is a very effective way to turn your phone into a space heater and then into a brick, right? Yes, it can do that. And in fact, it'll do that when you run a benchmark. But that's not a sustainable long-term performance. So the device will can run fast, but more likely than not, you're gonna be seeing your workload on the fast cores that will migrate to the slow cores. And yet, if you actually compare just the slow cores, just for a second pretend that the device is in an energy saving mode or is overheating, it'll turn off the big cores. And all of a sudden this quad core is within spitting range of the one above it, right? It's like it's just slightly faster. So once again, you have this very wide dynamic range just because the device can go fast does not mean that it'll always go fast. Say I mentioned this a few times, if the user is running low on energy, Android, for example, will kick in the power savings mode. Guess what's the first thing that goes when that turns on? It's your big cores, right? And if you actually run your benchmarks or run some sort of benchmarks, I think you'll find a dramatic difference in performance. In my own studies, I see as much as 40 to 50% depending on the device, right? So that's a pretty big range. If the device is overheating, it's a sunny day, you have your phone on a dashboard, guess what? You're not running on a big cores. Kind of silly, but that's what it is, right? Maybe there's a background process. Maybe there's something else to do with consuming the CPU cycle. So there's so many variables you can't control. So expect variability, right? So some of these reports that we started with at the beginning, it's like, hey, I have this fast device, but sometimes it's not getting me the FPS that I expect. It's like, yeah, probably, because there's just things in the world that you have to anticipate that cannot guarantee consistent performance that you get when you put your phone on a desk and you just benchmark it right there with AC on, right? So that's CPU, that's just one example. This same argument applies to memory and, of course, networks, right? Has anybody had a fast or sorry, slow 4G connection, right? Is 4G always fast for you? No, no, right? It's like, just because you have a fast network, it does not mean that you're gonna go fast all the time. There's nothing that guarantees in 4G that you'll go fast. Yes, there's much higher peak performance, and if you're lucky in a good area and with good coverage and there's not enough people and the network weather is nice, and if you're looking right at the tower, you're gonna get really good performance, but otherwise, expect failures. And further, the other kind of interesting and surprising fact is how often the users are actually offline. Sometimes not permanently offline, or in the sense that it actually says I'm offline, but it says I have signal, but effectively, I'm offline. It's the li-fi example, right? I dug up some data in Chrome. So in Chrome, we have telemetry to track how often does the page fail to load? And this number, or these numbers, the first time I saw them were shocking to me, right? Because effectively, what I'm showing you here is stats for failed navigations. This is main navigations. This is user typing in the URL or clicking on a link, trying to open, say, your website, and that navigation fails. This is interesting data because this is the type of request that never even makes to your servers. You don't even know about it, right? Which kind of begs the question of like, if no server was there to hear the request, the request really happened, right? It's like, yeah, it did, right? Because we've all experienced this. And I am showing you ranges here. So what does it mean to be, say, two to 5% failures at a certain percentile? And it turns out the rates do vary between different countries and different continents. So there's just better connectivity in some places. At which point, the first time I saw this graph, I'm like, ah, you know, this doesn't really line up with my experience. Like, maybe it's the problem in those other countries, with the bad connectivity countries, sort of thing. So I started digging a little bit further. So sometime later, I was actually reading a report. So this is coming from OpenSignal. So they published these quarterly reports on performance of LTE in different regions in the world. And there's this really interesting gem in there. Look at the bottom. In Germany, Italy, France, and UK, the chances that a 4G subscriber will connect to an LTE network are a little better than a coin flip. Why? That should be surprising. It was certainly surprising to me. You expect that North America, Europe should have this all covered. Turns out that's not the case. So I started digging a little bit deeper. You can actually go into the OpenSignal data. I'm like, OK, fine. So let me compare, say, Vodafone. I'm not picking on Vodafone. It's just it was a convenient example that I used. So I look at the stats for Vodafone India and Vodafone UK. So let's compare them. Roughly the same. You can see that, for example, the 4G performance in terms of the download, the peak download and upload speeds is definitely better in the UK. Interesting. The latencies are about the same. But then the thing that really stood out to me is this section at the bottom. So the way OpenSignal defines this is they run an app on your phone, which periodically just pings data to their servers. It tries to connect to a server just to see, am I connected? And if I'm connected, maybe I'll run a test just to see how fast I can upload or download data. And this number, the reliability number, is showing how frequently they were actually able to make the connection. So the phone thinks it's connected. It's showing you that bar in the top right of your phone. But the connection fails very frequently. So for example, look at 2G. In Vodafone, say, India, 75% reliability, which means that there is one in four chance that even though you have the 2G symbol on your phone, the request will just fail. And this is the experience where the user clicks and it's just sitting there. It literally even takes a couple of minutes to get to the Chrome dinosaur, which is not a very happy ending. So it's like, OK, this is not looking very good. So I started digging a little bit deeper. It turns out OpenSignal also has kind of a deep dive into UK in particular. And they share some of the numbers in terms of the coverage specifically for Vodafone users and how much time they spend on each network.  How much time do you end up spending on 3G? And then we have the reliability data. So you multiply those out and you say, OK. So if I'm on 4G, which is roughly 40% of the time, and I have 97%-ish reliability, about 1% of time, even though I have the 4G signal, I can't connect. If I'm on a mix of 3G, 4G switching between those networks, it's about 4%. And then finally on 2G, it's about 15%. So effectively, that's my effective offline time.  And if you look at these numbers, they line up pretty well with the failed navigations that I showed you earlier, which I think is shocking. It was certainly shocking to me when I first saw this data and I was able to line them up and say, OK, this is a much bigger problem than I thought. You can repeat this test for North America and you'll find very similar results. There's definitely a range of performance across different countries, but they're roughly in the same ballpark. So there you have it. It's not just those markets, not those emerging markets where this problem is happening. So one takeaway here is offline is not an exception. We keep thinking about it and treating it as like this is an exceptional state. The user is in San Francisco. They should never be offline. As somebody that lives in San Francisco, I can tell you that's definitely not true because I spent a lot of time offline. It's surprising the places where I'm offline. When I go to Golden Park, I'm offline. It's kind of remarkable and scary. So we do have, I think, a better analogy that we can use here. We develop UX personas, right? Like when you develop a product, you try to understand how the user is interacting with the application, what their needs are. And I think you can actually use that persona to also derive some performance insights. So as an example, right? You have two different people with two different needs. One is an urbanite who lives in a big urban city. They have pretty good 4G coverage, as you would expect, right? High density, good 4G. But it is high density, so they actually find themselves quite frequently on 3G because there's just not enough capacity. Surprisingly, they spend a lot of time offline. And why? Oftentimes, one of the most common culprits is public transit.  Sometimes it just does not work. So they actually spend a significant time offline, effectively offline. Compare that to somebody who's living in, say, more rural area. OK, the 4G coverage is not there yet. The density is not high enough. But they spend a lot of time on 3G. And then in the worst case, they fall back to 2G. And occasionally, they're actually offline. So they may be slow, but they're not permanently offline. There's an interesting message here, which is there is no such thing as a 4G user. You got your 4G plan. Somebody sold you the 4G plan, but you're not spending all of your time on 4G. You're migrating between different networks. You're actively migrating between different cells. And hence, the performance variability. And I think we really need to think about that and understand that not only is offline just not an exception, it's a normal state for these networks. But there's a range of performance, and we need to design for it. So we can't just say, oh, yeah, my app is for urbanites. They typically have 4G that live in North America, so everything's going to be nice and fast. Nope, definitely not the case. So coming back to what is resilience, right? I claim that resilient applications must account for the growing dynamic range of performance. They must account for the increase in the actual performance inequality between these devices, and also just the range. And we saw a couple of examples. There's the latency and the variability. There's the CPU. There is the memory. There is the network, right? Between those, all of those combined, that's why you're seeing reports like, why is this user on a 4G network on a fast device having a really bad time trying to load my applications? It's like, well, I don't know. Maybe they're a low energy, and they enable data saving, and they happen to be roaming. That's a very valid scenario, which many of our applications fail today. So performance, I claim, is a combination of multiple things, right? You have to be robust. Performance is a future. You build a whole lot of processes to make sure that you don't regress, that you're able to catch these sorts of things, and you're able to deal with failure. But then also, it's a responsiveness. It's being able to adapt to the current situation, understanding what the capabilities of the device are. And that is what gives you the resilience, where you're able to say, yes, this device smells like a fast thing. The network sounds like it should be fast, but it's not, right? And that's not a problem with the network. I'm like, it is a problem with the network, but it is my problem, and I should be doing something about it. I can't just say, the network is bad, so hence, it's out of my control. So I claim that there are some axioms of what it means to be a resilient application. Performance is not a static characteristic. It's not something that you just say, I curved out the fast path in my application. I eliminated all the bad things. That's not sufficient, because of all the variability. Fast devices actually are very slow, very frequently. You'd be surprised if you actually look at your telemetry. That is probably why you're seeing those long tails in all of your real user measurement data. And this range is only going to increase, so I think this problem will only get worse. You'll find yourself sitting a year later and saying, look, we're doing all this work to optimize the fast path, but which the tails are getting even longer. What is happening here? Devices migrate between different networks, specifically for mobile connectivity. In offline, I keep drilling this. It's not an exception. And I think you've heard many other speakers in the mobile track talk about this. We need to build mobile or offline first applications, because it is a normal state in that sense. So how do we put this into practice? I think once you understand these constraints, it's actually not that hard to change how you architect your applications. There are subtle things that you can do. First of all, once again, offline. It's a norm. We should be able to provide consistent user experience regardless of the type of connectivity. So today, we make the request, we cross our fingers, and we hope that the thing comes back quickly. That's not good enough. We should be able to control that. And that means that we need to be able to render something regardless of whether you're in a fast, slow, or an offline state. And if you accept that and you're able to render something and then say, OK, I'm now making the request, it's the app shell model. You can load the Chrome and say, waiting, like I'm doing something. But it's already significantly better than the user staring at a blank screen or worse ending up looking at the dinosaur. So that's your baseline. Because with that in place, you can do other things. How do you get there with Service Worker? That's a whole topic on its own. We don't have time. But thankfully, Jake is covering this in detail. He's talking later today at 4 PM. So I really, really encourage you to go check out that talk. And he goes into all kinds of detail for what it means to actually build this, and the best practices, and the gotchas, and everything else. But say you do get the Service Worker installed, right? The first thing that you will do, or I suggest that you do, is once you have this thing installed, you should take control of every request that is flowing through your application. Every request should have a bound. They should not be unbounded. I'm not sure when this will come back. So as an example, we intercept. In this example, we're using Service Worker. And we're going to intercept each request. And we're going to pass it along to the network, just as I did before. But at the same time, we're going to set up a race with a timer that just says, I'm going to wait for up to one second. And if the timer fires before the response comes back, I'm going to deal with it. I will fail. This is the example of, hey, the service is slow, and I need to change how my application behaves. Maybe it's simply providing feedback to the user, saying that, hey, I'm still waiting. Do you want me to continue or something else? Or maybe you just take it out entirely. In this example, I'm just returning a request timeout with a 408 status code. And maybe your upstream application knows how to deal with that. That's one example. And note that once you actually have this in place, once you have this race, offline is just an optimization to this race. Because if you know that the user is offline, there's no reason to run the race. You just say, well, I know the request is not going to succeed, so offline is no longer an exception. It's just a natural state. Just like you take entire data centers offline and it's assumed that you'll have to deal with it, here it's assumed that requests will fail and you have to deal with it. Once you've done that, now we've controlled some of the latency tails on the network and we're able to provide consistent experience, we need to actually adapt how the application runs when we bootstrap it or start running it on the device. For example, how many cores does the device have? You can access that. There are APIs for that. What is the battery status of the device? You can query that too. You can actually know if the device is being currently charged, if it's in a low power state, or if it's being discharged. You can access that. You can figure out if the user has enabled a data saver option in the browser. You can check what type of network the device is currently on. You can also find out all kinds of all the properties at runtime, like what's the resolution of the screen? What's the device pixel ratio? And maybe you can adjust how your app behaves. As an example, coming back to our request flow, you can augment it with all kinds of interesting logic where you can say, look, I'm going to intercept the request, but the user is telling me that they want to save data. So maybe instead of fetching a really high resolution image for this product photo or something else, I'll fetch a lower resolution because that's what the user is requesting.  So similarly, you can trigger the same logic and say, like, you know, if I'm a mapping application, maybe I'll download fewer places or lower resolution tiles because it's important that I get a consistent experience back, not that I get a high fidelity experience back in 10 seconds. That's a bad experience. Same thing for low battery and all the rest. You can imagine using the same sort of logic to adjust your runtime, where you can actually say, I'm trying to drive this thing at 60 frames per second, but for whatever reason, the device is in the low power mode or something else, I can't do that. So I'll need to change that. And this is, I think, the crucial part. You have to monitor this. So it's not just that you bootstrap your application, you detect these things, and you somehow initialize the app, and then you just cross your fingers to hope for the best. You monitor this. You've made certain assumptions. You know that what the network is theoretically capable of, but then you start observing. Every request that goes through, we expose data about how long it took. How much data did you download? You can use that to augment your previous assumptions and say, you know what, I'm on 4G, but this 4G is just not what I thought 4G should be. So I'm going to downgrade the experience. I'm going to disable this feature. Or maybe I can't drive this thing at 60 frames per second. So I will disable some other features. This is not new to many game developers. They continuously monitor their Raff loop and say, OK, well, I can't render these high-resolution sprites. I'm just going to drop some of them, because that's fundamentally better experience than delivering a janky experience to the user, which will actually make them nauseous. It's not that far out, and it's pretty simple. So you have to use these signals continuously and adjust a runtime. And that way, when the user transitions from 16% and they're running on their big cores on their Nexus 6 or some other device, and all of a sudden they stop over the 15% line and the PowerSaver kicks in, your application is able to detect that fairly quickly and adapt to it. And the experience is much better. Same thing for the network. So as I said, these things are not fundamentally hard. They're just subtle shifts. And these are the four things that I hope you will take away to help you build faster, more resilient applications, because just carving out the fast path is not enough. So that, thank you. I'm going to be hanging out at the mobile web booth for the rest of the day and tomorrow. So if you guys have any questions, please come on by and ask me and also Twitter or Google Plus. Thank you.


Hi everyone, Joe for Jaspy's Case Breaks.com. Coming at you with a really nice one here. 2021 Panini Flawless Football. Love this stuff. Full case, two both briefcases, two box break. Pick your team number 12. Very big thanks. There's the case right there. 2021 Flawless Football. Big thanks to this group. Thanks to the people who bought their team straight up. I appreciate it. Now before we pulled the remaining team to that big random number block, Nick ended up with last spot, Mojo, with the Patriots. And the 18 team filler, Carl. Bought full spots, automatically got the full spots, and pretty much got all the numbers except for number one. In the words of the rookies and stars fillers as well. So thank you, Carl. And congrats, Carl, for winning those spots in the filler. And congrats to Sean as well. We'll set this to my left right over here, and away we go. We'll use these blank cards. One in the middle, one on the left. I think the gem is on the right. So we'll go from right to left. It's just for, so we can kind of create as much drama as we possibly can. We use that blank card to slow play those hits right over here. Good luck, everybody. First one out of the gate, 13 out of 25, Rondale Moore. Three-color patch for Colin. Picked up the cardinals straight up. And then we've got a four out of five. Out of fives and under, that's a train. Well, so that's Cadarius Tony. Couple pieces of his glove for the New York football giants. And giants are part of that big number block group. So that goes to giants four. And that's for Carl, Carl. All aboard the Big Hit Express. Woo-hoo! Pat Friarmouth. Five out of 15, rookie debut autograph for the Steelers. Steelers also a number block team. And that goes to Carl as well. He's got all the numbers except for one. Next up is Bookit, Ian Book. Eight out of 15, dual relic and autograph for Seaton Flat and the Saints. Got the Saints straight up. Next is another train whistle. Three out of five. That's Boomer Asaisin, cardinals edition. Colin with the cardinals. I don't remember Boomer assigned Cardinals edition. Asaisin put the boom and boomer with his performance in Week 11 of 1996 against Washington. The four-time pro bowler, Signo Cara, began the seventh player to top 500 passing yards in a game. As he set the franchise, a franchise record with 522 yards. He also threw three touchdowns, including two in the fourth quarter to force OT in the 37 to 34 win. Boomer Asaisin, cardinals edition for Colin. Colin, all aboard the Big Hit Express. Woo-hoo! Couple more here. Three out of 20, Rashad Bateman. Some nice color in that patch for the Ravens, Aaron, with the purple birds. Might get some more looks now that Marquis Brown is not there. And the Lat- Ooh! Wow! A one-of-one Dak Prescott, NFL's shield and autograph. Dallas is a number block team. Nobody wanted Dallas straight up. Dallas one is gonna be Shawn Matic with a spot that he won in the filler. Nice, Shawn Matic. All aboard the Big Hit Express. Woo-hoo! Yeah, you would think that this would be encased, right? Well, let's see what's in the encase section then. So on the right side is the gem. These gems are naturally mine, not lab grown. That's what's in the small print there. We have nine out of 20, Leonard Fournette for the Buccaneers. Ruby for the, it's a number block team. So Tampa Bay two, or Tampa Bay nine is Carl. I think this is a patch auto. Quad patch auto, Justin Fields. Nice, just a quad patch that is, four out of 20. Chicago Bears, part of the number block group, that big number block group, and then that goes to Carl on the number four. Hopefully he does well this year and that'll be good for the hobby. And the autograph is Flawless Flyers. Flawless Flyers, Drew Brees. 15 out of 15, look at him fly there. Nice Drew Brees autograph.  All right, one case down, one more to go. Good luck, everybody. So far, so good. Let's see what we got in that second briefcase. And Flawless fans, we got another case of this in the store right now, jaskyscasebreaks.com. It's not part of the current promo we have. The next case, this case is. Promo, no promo, still really nice. Auto in the middle, I'm trying not to peek too much. Gem is on the right side and then the relic on the left side or maybe a relic auto, just a relic. And let's do the slider box first. Use that empty top with the cards on that box instead of the metal. All right, the dual relic on top, that's Jonathan Taylor on the right side, Marshall Falk on the left side, four out of 25. Colts picked up straight up by Sean Matty. Another dual relic, this is a randomizer, 17 out of 20. Kyler Murray, Lamar Jackson, that's between Colin and the Cardinals, Aaron and the Ravens, which bird team will prevail. It's a good looking dual relic though. Nice collar in there. Next up is DeSean Watson, one out of 10 etched in time. Houston Texans, that's part of the random number block group. And that's Sean Matty, has number one in that number block group, get the DeSean Watson. Ian Book, seven out of 20. Oh, hey, Dodger game just started? Freddie Freeman already has a home run. Dodger's on the road, they're in Milwaukee. So another Ian Book for Stephen Flatt and the Saints. We got Honored Ink, there's Boomer Seisen, Cardinals edition this time, that's one out of 10. You're 1988, NFL MVP. Bengals are part of that number block group, and that goes to Bengals one. That's for Sean Matty. Wow, the bus, three out of five, two color patch, on-card autographed Jerome Bedis. Steelers are a number block team. Carl, with Pittsburgh three. Nice. And all aboard, the big hit express. I kind of draws a football right there. Oliver's a, oh, Oliver and Chris, Steelers guys. And a one out of three, King Henry, Derek Henry. And that's picked up straight up by In Koo, with the Tennessee Titans. In Koo, all aboard the big hit express. Thanks for grabbing that team straight up. What do we have here? The gem first, same deal. Good luck everybody, we have, who do we have here? A football player. We have a legend, we have some Raider Joe Mojo, 15 out of 20 Charles Woodson Ruby. That's part of the random number block group, that's Carl. See, this might just be the relic. And it goes this way, landscape mode. Logan, Packers fan, saying better if he was a Packer. That's Patriots colors. That's Mack Jones, nice dual relic. Six out of 10. That's Last Bod Mojo, Nick, with a little something. Nice little number too. He has a nice season. He'd be hashtag good for the hobby. All right, final hit. Got some, got a relic here. There's a peek at the auto. And it's Zach Wilson, six out of 15. Now check that, five out of 15, rookie auto, Zach Wilson. The Jets are part of that number block group. And that is for Carl. Hopefully he gets well soon. That knee heals up quickly. See him back on the field. That'd be hashtag good for the hobby. And there you go, gang. That was flawless, pick your team 12. The case is almost closed on this break. We got a little housekeeping to do here. We got to see who gets that dual relic. So let's go back to random.org, new dice, new list. So on one side is the Arizona Cardinals. On the other side, Baltimore. Let's roll it and randomize it five into one, six times. One happy person, one sad person. One after six, two, three, four, five. Good luck, sixth and final time. After six, Baltimore on top. Apologies, Colin. But congrats to Aaron and the purple birds. You get that 17 out of 20 dual relic. Good looking card here. Now the case is closed. Thanks for watching, everybody. I'm Joe for Jasper's casebreaks.com. And I'll see you next time for the next break. Bye-bye.


There you go. Now you got them. The Police Activities League are here with lots of kids. We're fishing. Have you touched the fish before? No. We're catching lots of fish. Having a pretty good day. We want them to understand ethics. Gonna go get another worm. How to catch and release fish. How to treat each other on the lake. How to bait a hook. That one is moving and sticking me out. Generally all the fishing skills, but also the people skills that go along with being here at the lake. It's interesting to see kids who come out here that have never had this experience. When you fill it by, it's just really fun and exciting. Whoa buddy. Gets kids kind of out of the city, out into the rural area. Just have a nice good relaxing time. It's pretty fun actually. That's slimy. I think every kid so far has at least one fish. I got a lot of fish for now. It's just a great experience for all of us who get to be here with the kids.


In fact, I can say that as of today, our incredible staff has reviewed every tier one outdoor cultivator application. That was our biggest cohort of outdoor cultivators, and they are currently in the process of reviewing the remaining 22 outdoor applications for tiers two through five. If you are an outdoor cultivator, I can tell you that everyone here recognizes we're down to the wire, but we're almost there. And if you see an incomplete letter from the board, please do what you can to fix those issues in recent applications quickly as possible. Watch in this market. As an aside, when it comes to banking and insurance, I need to clarify that the bank account and the insurance policy has to be specifically for your cannabis business. It's not sufficient that you incidentally have a personal checking account or, for instance, a homeowner's insurance policy. Financial institutions need to know that the source of your deposits is from the cannabis business. And insurance companies won't cover most incidents unless you have a cannabis-specific policy. I mentioned our incredible staff.  He will be our director of compliance. He probably doesn't need much of an introduction. He interacted with the agency of agriculture at all in the past 30 years. You likely know him. But for those who don't, he's got a chemistry and a botany background. He essentially set up the agency's pesticide program, the hemp program, and the state lab just to name a few of his accomplishments. He served on our advisory committee and led the public health subcommittee. And you know, when I think about Vermont's reputation for quality, it's hard to overstate Kerry's role in setting up the systems that allowed our farmers here to flourish. And honestly, after my wife, he was literally the first person I called when I was offered this job. And I probably wouldn't have accepted, but for his assurance that we could do it and we could do it the Vermont way. I promised him I'd keep my enthusiasm to a seven out of 10. So I'm just going to end by saying that we're very grateful for your willingness to take on this challenging role. Finally, I just wanted to address a question that we received in public comment about a vote that we took at our meeting last week. The board added an agenda item to discuss whether an applicant's proposed operating plan violated the one license per location rule. Just as a refresher, our rules will require that a licensee may operate across two distinct parcels, only if they share a common border. The issue that the board needed to decide was whether two non-abutting parcels that were connected by a privately owned easement across another property would violate this one license per location rule. Just to be clear, both parcels and the easement were all held by the same person. Given the likelihood of litigation, depending on how that issue resolved, the board went into executive session. We heard the advice of our general counsel and we returned to our regular meeting and really voted two to one that the proposed operating plan did in fact satisfy our one license per location rule. Otherwise, I don't have anything else to add. This week, Kyle, Julie, do you want to say anything? Yeah, I'll say a couple of things. One, I've gotten a couple of messages from folks at AG that are certainly sorry to see Kerry go, although, you know, they're certainly excited for him and his new role after 30 years. I'm so ditto on keeping the level of enthusiasm to a seven. I wanted to quickly talk about our packaging waiver request and some general observations that I've seen. We've got about a dozen waiver requests in the pipeline right now.  And, you know, one of the things that I think is really important for folks to remember is that our goal with this is trying to reduce plastic waste. So, you know, for instance, I've seen a couple requests come through that have simply made the argument that their plastic, their traditional petrochemical plastic container weighs less than metal and glass alternatives and therefore, you know, it's it's it's promoting less greenhouse gases from a transportation perspective to get from a supplier to your to your business. And while I think that's true in isolation, it's not necessarily looking at the full lifecycle analysis of a petrochemical manufactured product. And so I want folks to remember that we're trying to reduce plastic waste and to just tell us that the greenhouse gas emissions from the transportation portion that those that scope three of an LCA isn't going to pass muster as it relates to trying to grant or seek a waiver. And the other thing is, you know, folks are not taking the right initiative to think about how these issues relate to what Vermonters are paying attention to, which is plastic waste issues, PFAS issues, so on and so forth, and are instead just copying and pasting sustainability, sometimes marketing claims of a specific brand or packaging company into the questions that we're hoping that you're taking a good faith crack at answering. So just, you know, from my perspective, I've worked in the environmental policy making world for my short career, environmentalism is about tradeoffs, depending on the issue that you're trying to address. It's hard to address and correct every single issue out there, because there's a lot of them and it's like whack-a-mole.  And I certainly understand and respect the argument that, you know, the transportation sector of glass and its weight per unit can output more GHDs, but that doesn't take into account so many other things from a primary pollutant perspective and, you know, what we're, you know, what we're focused and tasked with right here. So if anybody wants to come and talk to me, I'm sure you can find my contact information, we can talk about environmental policy. Happy to always do that, but please be a little bit more intentional with your request as it relates to packaging. Just add that I'm excited to have Kerry join us as well. I've only known him for a short time, but my every interaction has been a good one and a positive one and very informative. He's been willing to educate me on things about agriculture that I did not know and I very much appreciated that, that body of knowledge. And then also kudos again to our staff for the just absolute huge amount of discretionary effort that they're applying to their work every day to do all of this review and the time that they're taking while also hiking a very steep learning curve. So it's very impressive. Great. So all we have before we turn to the agendas to approve our minutes from our last meeting on June 22nd. Is there a motion? So moved. Seconded. All in favor? Aye. Aye. Okay. So next on the agenda, Executive Director remarks about Act 158. So unlike the title of this bill suggests, it's not actually about regulating small cultivators as farming. It does apply some agricultural exemptions to small outdoor cultivators, but really this bill became the vehicle for a separate bill that included a number of miscellaneous amendments to the cannabis laws. You have a full summary of everything that it does up on our website. But given that some of these amendments impact how licensees may want to set up their business, we thought that it would be good for Bryn to walk through some of the more substantive changes. So if you're prepared to do that. I am. Yep. And just to be clear, I am doing a high level overview of those aspects of Act 158 that are going to have an impact on people who are setting up their business and plan to be a part of the market this year. I'm not going to do a deep dive into everything with those. And there is an act summary as the chair mentioned and find it on our website under the laws, rules and regulations tab. And that provides a pretty comprehensive summary or an explanation of every section of Act 158. So just five points from the bill that I want to touch on. So first, prior to the passage of Act 158, both delivery and online ordering were prohibited specifically by the statute. So now after passage of 158, online pre-ordering of cannabis from a licensed retailer for in-person pickup is permitted. So delivery remains prohibited and all online ordering customers will need to go in person to pick up their products. So that means that all of the requirements that are found in our rule regarding age verification and cash management requirements and transaction limits will still apply to anyone who's making an online pre-order and going into a retail establishment to pick it up. Second, previously all retail licensees were not permitted to package cannabis for retail sale. Other types of licensees were allowed to package. So it's sort of unclear if that was an oversight or not. But Act 158 clarifies that licensed retail establishments are permitted to package cannabis for retail sale. So the practical effect of that is that there is a benefit to cultivators who will now not have to package all of their flour for retail sale. And there may be less consumer waste generated because cultivators can ship their product in bulk to retailers for them to package for retail sale. Third, licensed cultivators and wholesalers can sell seeds and clones now to other licensees, but not to the public. So prior to the passage of 158, there wasn't a legal path for licensed cultivators to purchase seeds and clones, as there is. Fourth, so this is not specifically from 158, but it's actually from the Cannabis Fee Bill and 158 made a little amendment to it. But the Cannabis Fee Bill established a product licensing process and an associated fee for licensing product with the board. So this process is going to ensure that all consumer facing products go through a review process here within the board that will include a review of product ingredients, labels and packaging. And that way the board can ensure that all of these consumer facing products are in compliance with board regulation. So Act 158 clarified that all cannabis producers have to register their products that they create and package for retail sale. And I want to make it clear that every licensed cannabis establishment that plans to produce and package products for retail sale will need to submit information to the board about their product in order for the board to review it and register every product that will be available for retail sale. So this is currently in development. So we are currently developing our product licensing portal, which will ultimately be a part of the license application portal. Until that is available, it will be a web form. So that web form will be available for licensees in the coming weeks. And that form is going to allow you to input information about your products, including the strain of flour or the ingredients, if it's a cannabis product, the label and details about the package. So that is a requirement. And your ability to satisfy that requirement will be available quite soon. And we will provide more information as it's available. Lastly, Act 158 gave the board regulatory authority over hemp testing, hemp infused products, and all synthetic cannabinoids. So that product registration process that I just described is also going to apply to hemp products. Given the emerging issues around novel psychoactive cannabinoids like Delta 8 and Delta 10, the board's plan is to prohibit products containing these synthetic cannabinoids until there is reliable research about their safety. And lastly, the Agency of Agriculture is going to be shifting their regulation over hemp cultivators to the U.S. Department of Agriculture at the end of this year. And they will be shifting the regulation of hemp producers and hemp products to the board. So the board is going to have oversight of hemp testing and hemp infused products that are going to be sold to the public. So more information about all of that will be available soon. But I wanted to provide an overview of these new changes since they will have a direct impact on folks that are going to be participating in the market this year. And I imagine that questions will be reserved for the end of our meeting during public comment period. Great. Thanks for that, Bryn. Are you now prepared to shift gears and review the recommendation? Wait, can I ask you a question about that real quick just to make sure that you have a question for us? That real quick just to make sure that we all understand. Are there any changes that we'll have to make to our rules to make them sort of align with the with the act? Yes, so there will be some additional detail that we will need to add to our rule in our next cycle of rulemaking regarding the oversight and regulation of the hemp producers and those products and also the product registration process. Thank you. Any other questions for Bryn about this? All right. Thank you all on. Nations on social equity, pre-qualification and license application. Hey. So as always, the numbers that you see in the tables in the form are up to date as of Monday, so two days prior to the meeting. Here are the pre-qualification application numbers. The board has five that are recommended for pre-qualification today. You can see the total numbers here that we've got 210 who have been approved for pre-qualification already. We don't have any that are complete and under review. 330 were submitted, been incomplete, and the majority of those have been withdrawn. So the pre-qualification approval process is really wrapping up. There will likely not be, if there are any more, they will just be stragglers. So these should probably be among the last that we're reviewing for now. So we have five up for review today. Staff are recommending pre-qualification for these five applicants because they've demonstrated suitability for pre-qualification and compliance with the rule. So we have submission 287, which is a tier one outdoor cultivation. Submission 401, tier three manufacturing. Submission number 590, retail. Submission 594, tier one indoor cultivation. And submission 607 for retail. I think kind of a question just comes to my head. It's not related to that, but originally when we drafted our rules, we had like tier one product manufacturer, the kind of the solid base extract and the kind of the most heavily regulated, right? Is that right? And then the legislature flipped it in our fee bill. Are our rules reflective of that change? In almost every place, our rules are reflective of that change. I think there may have been one spot, and I don't have it memorized, where we didn't flip it, but legislation controls always. So even if we didn't flip it in every place in our rules, the legislation controls, the law controls, it is tier one is the lowest, tier three is the most complex, and that's gonna be true in every instance. So if there's ever any confusion, check with us. It's right almost everywhere, but there may be one spot where we missed it. I only mentioned it because those license types are about to open. I don't want people accidentally applying for the wrong license type. Yeah, so if you look at, I am very certain that in rule, the main part of rule one, where it describes the tiers, that's all correct. I believe there may have been another spot, may not even have been, I think it may have been in rule two, where the reference was backwards, but the main part of rule one, correctly reflects the legislation. So if you follow rule one, you're doing the right thing, you'll be fine. Okay, next up are the license application numbers. Sorry, can I just add one more thing? So for those of you who are getting ready, it's rule 1.3.3 and that does have the correct listing of what the various tiers are permitted to do. So if you're thinking about being a product manufacturer, please refer to that section of the rule, that you know what you're applying for Friday. Sorry, keep going. So here are the numbers for the applications for a full license. You can see we've added two columns here for approved and issued. So this approved status means that you have, your application has been officially approved at a regular board meeting. An issued status means that we have actually sent you to the link to your cannabis establishment license because you have complied with any additional requirements and you have paid your fees. So we've licensed, so we've got about almost 40 people in that status have either approved by the board or actually have issued, have their license has been issued to them. And we have 12 folks up today for review, those recommendations. So as always, each of the applicants that are appearing on your register today have demonstrated compliance with all the requirements for their license that are contained in both our rules and in the statute. So I will go through them one by one.  So that is your list for today. I'll move on to the social equity license application. So here is a summary of where our social equity applicants fall in the process. We have two that are up for their license review today, nine approved and eight issued. So just under 20 social equity applicants that have been approved for a license. So we have five applicants that are being recommended today for social equity status. Submission number 234, that for recommending social equity status for this applicant as they meet the criteria for a social equity individual applicant that's defined in board rule. Submission 701, also recommended for social equity status as they meet the criteria for a social equity individual applicant. Submission 646, meets the criteria for social equity business applicants that's defined in board rule. So staff is recommending social equity status for them. Submission 635, meets the criteria for social equity individual applicant. And submission 484, this applicant also meets the criteria for social equity individual applicant. So staff are recommending social equity status for this applicant also. We have one applicant whose staff is recommending social equity status denial as they don't meet the criteria for a social equity individual applicant as defined in board rule and that submission number 641. So is there a motion to approve? I move that the board accept each of the recommendations for pre-qualifications, social equity status and licensing approval as presented to us by staff and the community. Second. Any discussion about any of these? All in favor? Aye. Aye. Okay, great. Then next on our agenda, public comment. We'll do this kind of the same way we always do. If you join via the link, feel free to just raise your virtual hands. We'll do our best to call on you in the order that you raise your hands. And then if you join via phone and like to make a comment, we'll move to you after we've kind of gotten through people that joined that video. So Nellie, would you mind helping us out just with the order? Absolutely. We have Marie first. Marie with grow. Marie, we can't hear you if you are commenting. There we go. There you are. We got you. Okay, can you hear me now? Okay, great. Thank you so much. First, I want to thank all of you for everything you've done and everything you do. I've had some great conversations with some of the workers there and just truly appreciate it. So that's first. Now I do have a new question with the whole thing of product registration coming up. As this isn't the first question I have, but actually I'll make it my first question. With the product registration process, does a manufacturer tier two have to do that? Or is that strictly in retail? So Marie, we don't traditionally answer questions during this period. We do appreciate your question. And they will know, I don't know, please feel free to ask because we are developing guidance around all of these issues. And any question that we hear is a good one for us to kind of help draft our guidance. So do feel free to ask. It's just, we won't be answering questions directly today. Okay. Well, I'll keep my eyes open for an answer on that somewhere. This other issue though is more of a comment. I'm hoping there's something y'all can do to help because my concern it has to do with the banking and insurance. It's very frustrating where I'm coming from because I'm gonna be your typical Vermont standard, small craft, licensee. And what I find we're up against is many of us have cleaned out our retirements to pursue something that we didn't even think we were ever gonna see in our lifetime. And now I realize you guys cannot control what the federal status of cannabis is, hence the financing and insurance issues. But if there is some way to alleviate the stress upfront for licensees, that would go a long way because what I'm up against right now is I cannot, it's basically like we're seeing price gouging as a small business going out there trying to get these checking accounts. They're going to charge us astronomical amounts and right now every dime I have is going into trying to start up my business. And I'm a one-man show. So everyone hears cannabis and they immediately see dollar signs and they don't see the single mom or dad or the mom and pop business. So the fee structures right now that banks and the policies that the insurance companies are going to be giving us, they're looking for really extravagant amounts of money from us to set up these accounts. And it puts me right out of the running if this holds true. So I have yet to see what the whole manufacturing application process, I started the prequel with Drew. So now I'm gonna be doing the whole thing come Friday, but I'm a little nervous about whether I'll be able to follow all the way through based on those type of hindrances. Thanks, thanks, Mary. Okay, thank you. Next we have three frog farms. Hey guys, I know you probably can't comment on it now but maybe for the future meeting. I was just wondering if, because you always mentioned tier one outdoor. I was wondering if you're considering tier one mixed as an outdoor because for a lot of us, we're solely really going for the outdoor portion to get started. And I'm wondering if that, that tier one mix takes precedent over the outdoor twos and tier threes that you're beginning to issue. And that's all I got. Thank you very much. Thank you. Pito is next. Hi everybody. I'm just, I just wanna address an issue today as a PSA to any indoor growers that I just got off the phone with Dan from Efficiency Vermont earlier this morning. And I was surprised to hear that a lot of growers initially reached out but are not following up with them and they literally have money to give away. My tier two indoor grow got $53,000 from Efficiency Vermont. That's actual real money they're gonna put just straight into the project. Granted, you definitely gotta switch from your old HPS lighting, which I think it's definitely time to do anyway. And so for anybody out there that thinks that the modern LED lighting hasn't caught up yet, it has surpassed HPS lighting. So please switch over, call Efficiency Vermont and get your money. Thank you. Thanks Tito. Thanks Tito. Chris. Yes, I just wanted to thank you guys for all the work you're doing. Imagine how hard it is on you all to be the intermediaries between the people and the government, which is a lot of us have been battling against a long time. And some of us would even say it's been a war. I just wanna point out the fact that there's a lot of greed showing up on that side of things. We're all in this position here of trying to do what we can do to make our businesses happen. And we're jumping through all the hoops, we're getting the packaging right, we're getting our inspections done. And then we see these licensing fees. And I understand that the licensing would be expensive for this first time around. But for it to be that same fee going forward for everybody really seems like we're getting gouged. And it just doesn't really make sense. The Vermont way is a farmer's market. And as a tier one farmer, I wanna be able to take my product to a farmer's market. And I don't wanna have to pay $10,000 a year to have a license to do that. Now, it's only up to people like you to step forward when somebody says we need to get money from these guys. We need to take them because they're gonna make so much money. We're gonna get the money from them. You know what, we're just, some of us are just little farmers doing what we can as a side job. And there's really nobody besides people like you to step up and say, no, we're not gonna accept that kind of greed. And when there's taxation without representation in this country, people get pissed. And it wasn't that long ago that people were dumping plant material into the Boston Harbor. And it started off a whole chain of events that led to our freedoms. Now, we just need to keep that in mind as we move forward and realize the frustration level that we could all be having. How we all wanna be a part of a legitimate system. But when we get pushed, it pushes us to not wanna be legitimate. And I hope you can do your best to be that intermediary for us. Thank you. It's Chris. Yareem. Hello, how are you guys? Thank you again for everything you do. And I wanna applaud you for two things. One of them is the work that you're putting through you and your staff getting these licenses out. But one thing that I wanted to comment on and applaud you on is that I wanted to hear about the hemp program being transferred into the CCB. And one of my main reasons of coming in today was to ask about those things. And being able to hear you guys speak about it before I could even inquire for it. It's really, really commendable and really great. I am still looking for a bit more of when it comes to the medical side of things because it does affect our business overall and how we run ourselves. So it would be nice to be able to hear some things about the medical program as we move along. But nonetheless, thank you for everything that you guys have been doing so far. And we keep hoping for more. Thank you. Have a good day. Yareem. Dave. Hey, following up on a couple of earlier comments, and sort of in the spirit of Tito's comment, just got noticed today that Vermont Federal Credit Union is significantly revising, lowering its fee structure. And I just wanna make a PSA about that. For manufacturers, their fees are actually like super low. Tier ones is 75 bucks a month. You're not gonna find anything lower anywhere in the cannabis industry. So they're still high for retailers or still high for wholesalers, but for growers and manufacturers, I really recommend that everyone check them out. They're even now talking about fee waivers in the initial months, realizing that folks won't have money until they have sales, which will take some time. So Vermont Federal Credit Union. That's all. Dave. Anyone else who joined via the link, please raise your virtual hand. And in the meantime, we'll go to people to join via phone. If you wanna make a public comment, you can hit star six to unmute yourself. Now, are you seeing any phones on muting over on your end? I, someone not on the phone just unmuted, but I can't see whose hand that was. No one put up a hand, so I'm not sure. Jeff, stop. Hello? Yeah, we can hear you. Yeah, Jeff, stop. I have a question. Number 641, social equity. You guys voted to not approve me today. 641, is that correct? Just one sec. Yep. Yep. So, you know, I'm a convicted felon. I was not incarcerated in jail, but I was at home. And I'm just seeing what it was based on, that I was not eligible. We can't answer that directly right now, but we can follow up. All right, I'd appreciate a follow up on that, because it has definitely negatively impacted my life. And it seems that all the questions that were asked, that I would qualify. And I'm just a little confused as to why not. All right, thanks, Jeff. I appreciate your help. Thank you. Any other public comments before we close? We'll close the public comment window. Just a few just reflections on some of the comments. Marie, you know, we hear you like, you know, insurance and banking, the fees are high for no other reason than the federal status. It's really not more risk to anyone. It really is just a reflection of kind of the federal illegality. Insurance is a statutory requirement. The legislature here in Vermont demanded that we ask that you have insurance. We try to kind of limit the kind of negative impact that that might have by saying you need commercially reasonable levels of insurance as opposed to stating a specific amount. And there is a waiver request that you can make if you can really demonstrate that your risk is low. If the specific business type that you're looking to start has a very low risk, you can kind of set aside some money in escrow that can cover insurance amounts in lieu of insurance. Tree frog, yeah, as soon as we're done with the outdoor, exclusively outdoor, we're moving on to the mixed years next. So that's the next step. Fees, yeah, the fees, we don't get to determine what these are. All we can do is try and keep our footprint, our fiscal footprint here at the board, as low as possible. We did kind of tell the legislature that the fees need to be low if you really truly want kind of a craft, small cultivator ethos here in Vermont. And they kind of met us halfway, I should say. And then the medical program, I think we all agree here. We've had a lot of discussion about the medical program. The bill that we proposed did not get taken up, but I think next year, or later this year, we'll be having some in-depth discussions about the future of the medical program. Any other comments, Julia or Kyle? Not today. I guess I should say I wasn't any can on Saturday and I met a lot of you in person, I think for the first time, it was a pleasure to meet you on your turf. And hope to see you again. All right, well, I will adjourn this meeting then. Thank you all for attending.