Hello friends, Osiris here and the Seven Star Terrorite Event for Charizard is now live in Scholar and Violet in today's video. I'm going to go over all of the details as well as the best solo build for you to beat this with in your game. So on the back of the Blastoise Seven Star Terrorite Event ending we now have the Seven Star Charizard in Scholar and Violet. We'll be returning, this has been an event in the past but it's coming back so those of you that missed it that first time around are going to have the chance to get this event in your game for the next few days. The event itself is running from March the 13th as of recording this video until March the 17th. The Charizard is going to be level 100, it will have its hidden ability, solar power and moves. It will have a dragon pulse, a fire blast hurricane, focus blast with additional moves of overheat, terror blast, sunny day and inferno. It will have the mightiest mark, it will be a dragon terror type, it can never be shiny and it will have a modest nature and it can only be called once per save file. So like I've mentioned, if you caught this in previous events where this has been live you're not going to be able to catch it again. Now the notable turns that you're going to keep an eye out for during this raid are going to be 98% of the time remaining so very shortly after the raid begins it's going to fire off an overheat and then immediately after that it's going to reset its stat drops on its side of the field, that's the only time it does it throughout the raid. The next turn to keep an eye out for is when the Charizard's HP hits that 70% mark. It will nullify the stats and abilities on your side of the field and that's the only time that's going to happen throughout the raid and then it's 65% of its health remaining, it will set a bit shield and that will be the three notable turns that I would say you're going to keep an eye out for in this raid. When you've beat the Charizard of course you have the chance to catch it if you haven't before but alongside that you're going to get a lot of good item drops, level up candies, calcium, you're going to get dragon, terror shards as well as ability patches but alongside this unlike previous raids you're going to get the chance to have Herbomistica dropping with this raid so even if you have caught it in the past it's worth going in and farming this raid just for the chance of getting those Herbomisticas every time you beat it. So like I say the Charizard will be running not as long as the previous Venusaur and Blastoise raids but running from today as I record in this video on the 13th until Sunday March this 17th. Now to access this event in your game you're going to need to make sure you are connected to the internet then come down to your poker portal once you're in this screen come down to your mystery gift and then come to check poker portal news this will just update all of your dents in the area you'll get the 7 star turret event for Charizard appearing on your map then you just need to locate it and head over to it. Now the builds that we're going to feature in today's video are going to be the most consistent ones to beat the Charizard with these I've tried and tested from previous events and also tested by myself again tonight with the other ones that we may have suggested in our preview article going to be the best ones to go in and farm for Herbomistica over this weekend. The first one I'm going to feature is the Silvian it has got the fairy terra typing it has got the held item of the covered clock that just avoids any burns as well as those confusion chances that the hurricane carries with it will be level 100 make sure that your IVs are all hyper trained and then a move set of hyper beam our mind fake tears and draining kiss with the hidden ability pixelates then an EV spread of 252 EVs in special attack 252 EVs in special offense and a modest nature of course all of the builds that we feature in today's video will be down in the description below so you can take a look at those after the video and then we've got the flutter main it is going to have that fairy terra typing as well obviously is a scholar exclusive so that's why we're going over two builds today just in case you are playing on violet and you don't have access to a flutter main the Silvian is going to be just as good an option but the flutter main very solid if you do have one in your games again going with a cover clock item for the same reasons that we've got it on the Silvian level 100 hyper trained and the move set is going to be moon blast fake tears calm mind and draining kiss product synthesis is the ability and the EV spread is going to be 252 EVs in special attack 252 EVs in special defense and a modest nature so that is the flutter main and we'll jump into the raid now and I'll show you how easy this can be with that Silvian you first come into the raid against the Charizard the first turn it is going to launch off in overheat that's going to go into any random target on the field if it does go into you don't worry about it because it can happen sometimes especially if you are farming for the herbomistica raids the one thing I would say about this raid in general is it's pretty easy but it's very RNG heavy so it can really go a lot of different ways every time you come into it as you can see it's gone into the Haxros here then it nullifies the stat drops on inside of the field resetting those but we're in a nice position here turn one always go for that calm mind that's just going to give you that special defense boost to get those fake tears off as you see it does go for a hurricane and hit and like I say very RNG heavy this raid because it's got very low accuracy moves and most of the time they do hit but sometimes you get away with it and they do miss next turn we're going to go for a fake tears the idea here is to get the Charizard special defense down to minus six before the shield goes up because as soon as the shield goes up fake tears isn't going to be used but we know the Charizard only nullifies its stats on its side of the field once in this raid and it's already done that so we're going to be safe if we get it down to minus six to be able to kind of just maximize our damage output for the rest of the raid you get pretty fortunate here with a hurricane and a fire blast this there but I mean you take it because it is going to happen where you go into a raid and it's going to hit everything but there's the third fake tears and the Charizard special defense will be down to minus six if there's any point in the raid where you have taken a lot of damage and you feel you're not in the best of positions just go for a draining kiss in between getting those three fake tears off and just recover the health because any draining kiss that you're going to get off at any stage here is going to get you back to full health so you're going to be in a really good position to kind of set up for the rest of the raid so I'm going to activate the shield as we see here and it will nullify the stat boosts on our side of the field so we're going to have to set up that calm mind straight after this and then chase down our tracelization that's pretty much what we want to do but the first thing after the shield goes up and our stats are nullified is go for that calm mind straight away just to get that special defense boost because we don't really want to have to be contending with these big powerful attacks coming out from the Charizard so there's the plus one in our special attack plus one in special events and now like I say we're just going to concentrate on getting to the point where we can tracelize so we'll take another hurricane go for another draining kiss that's going to be our second draining kiss we'll get some health back while we do this and chip down the Charizard as we go and take another fire blast for our troubles here so you can see we're still in a pretty healthy position as we go for that third draining kiss after this we're going to be able to tracelize but rather than go for another attack and just tracelize we're going to do is set up another two calm minds because we're going to be able to end this raid pretty quickly with that hyper beam once we do tracelize and get that tracelization boost here so there a blast coming out from the Charizard dragon type not going to affect us because of our fairy type in which is really nice as we take another hurricane but that cover cloak coming in super handy here because it is preventing us from getting confused and that is one of the real drawbacks if you don't have that item going into this raid one of the reasons why a zoomer all is not as reliable as some of the other options that we've got they can rely on the draining kiss for recovery and then obviously avoid any of those confusion turns that you can be subjected to so we'll go for that third calm mind here we're still in a pretty healthy position as we sit here as we might take another fire blast our hurricane from the Charizard which we do when such a healthy position with our special events here you can see we are plus three across the board on a special attack and special defense Charizard mine is six and we are at the point where we can tracelize raid timer in a good position we'll just tracelize and click in with that hyper beam and that will be more than enough even if the Charizard's got more health at this stage you're going to be able to knock it out with those plus three boosts and the minus six on the Charizard once you have to rasterized you're going to be in this position to just close it up the raid timer is pretty good here you're going to be able to run through these raids really quickly to farm for those Herbomisticas over this weekend which is really nice and probably one of the biggest reasons for doing this raid over the weekend if you are taking part in it of course you have called the Charizard in previous events in the past so there is the Charizard done with the Sylvian and it is as easy as that it will disappear and see if we get any Herbomistica drops and we get three this time so that's really good so we've had good drops so far but like I said the Sylvian is super easy to use and accessible to everyone in the game because it is available as an EV in the base games and if you come into the raid with the Flutermen we first turn with the Flutermen a lot like the Sylvian we're going to go for that calm mind the advantage that Flutermen has over the Sylvian of course is that it is faster so you're going to get that calm mind up before the Charizard goes for an attack taking less damage meaning that your setup is a little bit more seamless going forward of course you can take critical hits throughout the raid so you need to be a little bit careful with those turn two we go for that fake tears and again I'm going to try and get that Charizard's special defense down to minus six before the shield goes up like I said at any point that you are using these fake tears over the next three turns if you are pretty low health at any point just go for a draining kiss at any stage and just recover the health that you've lost to put yourself in a better position going forward in the raid because you don't want to get knocked out it does slow you down and especially if you are farming for those Herbomisticas throughout the weekend you want to be doing it as fast as possible so here's that third fake tears as we go through it and the Charizard's taking pretty decent damage so far from our partner in Pokemon just with the support from that fake tears we do take another hurricane our health isn't in the best of positions here so we'll go for a draining kiss like the Sylvian we're just chasing that tracelization here where we can tracelize and then close this Charizard raid out probably will nullify our stat boost on our side of the field after this turn because it is at that kind of HP number and then set the shield up as well like we're seeing here so we're going to be able to have to get at tracelization up before able to do any big damage but the first thing after our stats are nullified on this side of the field is going to be go for another calm mind I can say we've got the speed advantage against the Charizard so always going to be able to get that up to get that special attack boost and more importantly against the Charizard the special defense boost as well but we can go for a couple of these yeah or even three of these if you want but you probably only need two to really have a big impact going through on the raid because like I say this stage we are just kind of concentrating on getting a couple of these up and then chasing that tracelization where then we can close the raid out very quickly after that stage but like before if you're getting into a really dangerous position with the HP just use a draining kiss heal it all back up and then kind of carry on the raid from there so like I say we've got a couple more of these draining kisses to use before we can tracelize but you can see the raid timer in a really good position here probably going to run through this very quickly and one draining kiss even with the shield up is healing us back complete normal and you can see we get a bit lucky with our raid partners because we've got something the belly bolt that's paralyzing the Charizard so we do dodge a turn there but like I say so RNG heavy this raid it really is different every time you come into it and sometimes the RNG is going to go your way sometimes it's not but the cover cloak item that we've got on here definitely helps out once you get to the position where you can tracelize and your health is in a good position you're not in a good position health wise use a draining kiss but if you're in a good position health wise just lock in with that tracelization and then the moon blast and that's going to be the more powerful attack and move that you've got access to and it might be pretty close to us taking this Charizard down we've only got two calm mind boost so we're plus two at the minute but more importantly the Charizard is done to minus six special defense that we set up at the start of the raid and it's so important to get that up like I say the raid time is in a very good place at the moment so yeah there we go nice and easy and it is that easy with the flow man and of course as always if you want to respawn your dens you're going to need to come in to your home menu and then down in the system settings and down into system down into date and time make sure you synchronize clock where the internet is off pick in your date and time options and then just toggle through don't change anything hit that okay and then come back into your home menu back into your game and you should see all the dens respawn and you can find that seven star turret event for Charizard and then head over to it and then farm away for those Herba Mysticers over the weekend so friends that is everything for today's video I hope you find the two bills that we feature in today's video very helpful especially for farming those Herba Mysticers over the weekend if you have caught the Charizard for the first time because you missed the previous events that's great to let me know down in the comment section below what pokeball you got your Charizard in but good luck with the Herba farming over the weekend if you have found it useful do drop a like on the video to subscribe to the channel as well to stay up to date with all of our Pokemon content and I will see you all in another video very soon so until then friends take care of yourselves and bye bye


Welcome to the ContainerD introduction and deep dive session. I'm Derek McGowan, maintainer on the ContainerD project at Apple. I'm joined today by fellow maintainers Phil Estes from IBM, Michael Crosby from Apple, and Wei Fu from Alibaba. We're going to give you a brief introduction to ContainerD today and deep dive into various parts of ContainerD. First, we're going to discuss what ContainerD is and why to use it. Then we will give an overview of its architecture. We will deep dive into the new node resource interface, also called NRI, and ContainerD's other plugin systems. Then we will discuss ContainerD's most recent release and what's coming up in future releases. So let's start off by handing it over to Phil. Hey everyone, I'm Phil Estes, one of the maintainers of ContainerD, and I'm just going to take you through a brief introduction to ContainerD, mostly focusing on things that are new or that we didn't get a chance to touch on since it's only been a few months since the virtual KubeCon EU. So let's take a quick look at ContainerD and a few new items, and let's get started. So we always try and start out giving a little bit of background on what ContainerD is. Obviously, we're a CNCF project. We're one of the graduated projects as a container runtime. And really, maybe the best way to see that is to see us below higher-level platforms like Docker or Kubernetes, but above lower-level runtimes like OCI's RunC, or the various sandboxes like Cata Containers or Firecracker or Google's GVisor. And so, really, ContainerD is that resource manager that can sit between a higher-level platform, like the two we mentioned, and manage things like the processes, the images, the snapshots on the file system, all the metadata about containers and their dependencies. And I think the important thing there is that we don't just manage those resources, but the way ContainerD is designed. It's a very extensible system, and so a lot of the projects that we've seen use or grow out of ContainerD have used this extensibility to great advantage. It's also a tightly-scoped project, so we don't change the scope of ContainerD often. The only thing we've really done in the lifetime of the last four years is bring in the CRI plug-in so that Kubernetes had a natural plug point to use ContainerD as a runtime. There are a lot of new governed sub-projects within the ContainerD repository and organization.  So that gives you a quick snapshot into what ContainerD is. Now we've walked through ContainerD's history in more detail just a few months ago at KubeCon Virtual EU, and you can find that talk on YouTube already. But just for a brief history, ContainerD came up alongside Docker. It's not a fork or it doesn't inherit any part of the Docker code base, but effectively it grew from a container supervisor used by Docker into a full runtime in the 2016-2017 era. During that time, we created completely new interfaces for managing containers and images, and then after defining those in GRPC, we also created a Go client API that's used heavily by the CRI, for example, as it implements the container runtime interface for Kubernetes, and many other projects use that clean API to manage containers and images and container lifecycle. Now you might ask, okay, so I see how ContainerD came to be and how you designed it. What are the use models or patterns that we see as ContainerD has matured? One very common use case, mentioning the CRI, is that if you're using Kubernetes, ContainerD is the most stable, best supported, and mature runtime in use today underneath Kubernetes. Every major cloud provider has a managed Kubernetes offering. They either use Docker or ContainerD today, and many of them have switched fully to use ContainerD. If you're a developer, you probably aren't going to use ContainerD directly, but if you're using Docker, by nature you're already using ContainerD and BuildKit, which also can be used separately or within the build system for Docker, heavily uses the ContainerD API and can use ContainerD as the runtime for build. On the edge, which is getting a lot of focus and interest these days, ContainerD is seen as a memory efficient and stable runtime used in popular projects like Rancher's K3S. Functions as a service has also been a growing area and even has some blurred lines with pure containers as a service offerings like Google's Cloud Run or Fargate. And again, ContainerD is seen as a fast and efficient runtime used in projects like FASD or IBM Cloud Functions, or even IBM's new cloud code engine service built fully around ContainerD. Now, we don't have a lot of new information on ContainerD adoption across the ecosystem, since we just shared many of these numbers and percentages just a few months ago. But there is a CNCF survey that's now out capturing some of the 2020 changes to that information. And we're hoping to see very soon, ASSISTIG's latest usage report, which should be out by the time you hear this or maybe in the next month. Now, the CNCF survey update did show that ContainerD usage grew by over a third since the last time the community was surveyed. Production use of ContainerD is also growing. 36% of respondents noted that they were directly using ContainerD in production. And so again, without a lot of new data, we definitely see continued growth in the use of ContainerD, and we also see in our community project a lot of new activity from people utilizing ContainerD, maybe in scenarios that aren't going to be shared publicly, but obviously show a growing use of ContainerD across the ecosystem. For example, we've already mentioned major cloud providers. You can see many of their logos on this slide offering Kubernetes as a service where they use ContainerD. And again, we've already mentioned Docker's use of ContainerD. Many of the isolators and sandboxes have written shims directly for ContainerD so that you can use things like Cata or Firecracker or GVisor or others right within ContainerD using the same API to access these sandbox isolation technologies. Containers as a service is a very interesting area. Obviously, we already knew about Google Cloud Run and AWS Fargate. Azure has container instances and IBM just announced the Code Engine project, which also effectively is like a serverless containers as a service offering. And so almost all these projects, at least where we have public information, are directly using ContainerD to build these as a service technologies for their customers. And then many developer tools like we've already mentioned BuildKit, but Ignite and Kind are also using ContainerD. And then new on the scene in the last few months, maybe you've heard of LinuxKit, but Amazon recently released Bottle Rocket OS as an open source project that again uses ContainerD for a containerized Linux OS idea that they've now shared with the broader community. Now, we've given you a lot of information on how ContainerD is used, who might be using it, various products and development tools and offerings that we know use ContainerD, but maybe you're interested in getting involved directly to our open source project. And of course, we're always looking for those who'd love to come contribute, who have issues that they found using ContainerD, that they join in our discussions. We're on the CNCF Slack in the ContainerD channel and ContainerD-Dev for those who want to help with the development of ContainerD. And of course, we'd love to see many people get involved. We'd love to improve our documentation. That's an area we've been talking to the CNCF about. And so no matter what skill level or what your interest is, we'd love to have you join us in the ContainerD community and reach out. If you can't figure out where to get involved, definitely reach out to us and we can find a way to get you involved. Thanks, Phil. Now let's take a look at ContainerD's architecture. In this diagram, we have broken down ContainerD into three main components. The client is ContainerD's go client, which contains most user-facing container logic you may be familiar with. In the middle is the ContainerD daemon, broken down by API, core, back-end and plug-in. This is where ContainerD's service interfaces live and handles all data storage and resource management. The shim is what owns the container processes and communicates low-level operations to and from ContainerD. The shim is responsible for interacting with the lower-level Container Runtime. As a user of ContainerD, the client is the first place you will interact with. If you are building a system on top of ContainerD, the client is what you will be working with. You can see in this diagram that some core functionality that is often associated with Container Runtimes is implemented here in the client, such as container management, which handles creation of the OCI Runtime spec, preparing the container snapshot, as well as starting individual container tasks. Image polling is also completely implemented inside the client. Because of this approach, clients are mostly limited to using our go library. Even though Python, Java, or another language could talk to the ContainerD API using gRPC, basic functionality would need to be re-implemented to use the full runtime. The CRI interface is probably much easier to work with if you are not implementing your project in go. One of the first things you will come across in the client is the options pattern. With ContainerD, we chose to keep the core as simple as possible. By defining clean, simple interfaces in the core, that meant that the client had to have more functionality and configurability. In the ContainerD core, there may just be generic variadic options on a core type, but in the client, you will see with options used on these types implemented feature. You will commonly see this used for labeling and filtering on types. We were also hoping this would allow clients other than be forced to work around opinions in the ContainerD daemon. The core of ContainerD contains the components we consider most critical in terms of stability. Here we define the main data types and interfaces used by ContainerD. If you think ContainerD overuses interfaces, this is partially intentional. We want data and operations flowing through the core and everything else wrapping those types or using data that is tracked by the core. The core has a main implementation of these interfaces, and these interfaces are extended all the way to the client. The design is such that all data flows through the core so that plugins and other components don't need to store data. This is important because we have implemented garbage collection inside the core metadata store. So if data is being stored somewhere else, it is really hard to track that data and make sure it is removed when it is no longer needed. This makes ContainerD more stable by keeping storage and memory usage stable. It also avoids data inconsistency and crashes. We don't expect as many change in the core relative to other parts of ContainerD. Features generally aren't implemented inside the core. However, some features will require small changes inside the core. So for example, we recently added a feature to support remote snapshotters. The high-level feature of remote snapshotters is not something that the core knows anything about, but one functionality we did add to the core was the ability for the snapshotters themselves to report that they already know about a snapshot as it is flowing through the core. So when you create a new snapshot, you can pass information that says this is the target snapshot that I'm trying to create and it will pass that to the backend. The backend now can actually communicate back up to the core to let it know it already has that snapshot. That allows the client to know the snapshot is already available as a remote snapshot when it sees the core report the snapshot as existing. Meanwhile, the core has no knowledge of what a remote snapshot is. It is really important for us to keep the core of ContainerD un-opinionated and to make sure we don't get feature creep showing up in the ContainerD daemon. We also don't want opinions showing up in the daemon where new features or requirements are limited by previous opinions added to the core. One thing you may notice is that there are no tasks in the metadata store. Even though tasks are considered a core type with a core service, the data associated with the task is completely ephemeral and only related to the actual running container. This data may be something like process information or Unix sockets. When a node is restarted, all the process information will be gone as expected. However, all the metadata associated with the container including its specification and snapshots are consistent in the metadata store. This information can be used by clients to recreate the container and tasks. The disk service is another core service without any state. It operates on snapshots and content but does not store its own information. Notice that the CRI plugin sits inside of the ContainerD daemon. In current versions of ContainerD, the CRI plugin exists as a single imported plugin. In ContainerD 1.5, we are merging the CRI code base and integrating CRI's components Today, CRI operates by using the ContainerD client package directly and calling out to separate plugin interfaces such as CNI and NRI. Let's take a look inside the CRI plugin. CRI consists of two gRPC services, Image and Runtime. Both of these services share a service backend in the plugin today and call into the ContainerD client. The CRI plugin is responsible for defining the pod by sharing the namespaces and cgroups between all containers in a pod. It is also responsible for managing the pods container that is responsible for holding namespaces open. In the future, the pods container will be able to go away since there are other ways this could be accomplished today. The CRI plugin invokes CNI for setting up container networking. This call is invoked after ContainerD creates the first container so that CNI can set up networking using the container's namespace. The CRI plugin also calls into the new node resource interface. Let's hand it over to Michael to discuss the node resource interface. Alright, I'm going to show you some of the work node resource interface for ContainerD and Kubernetes. When you think about resource management, we have different workload requirements. You have customers that are running batch workloads and also customers that have latency since the workloads that may be in the request response cycle for various users interacting with the service. Both of these type of workloads, we need to be able to co-locate these but they have very different performance requirements that their users expect. Also, various user requirements such as priority and SLAs and SLOs for how eviction happens on these nodes is something that we all have to manage. When you think about resource management, we have various resources on a compute host. You have CPUs which you may want to dedicate CPUs or restrict access to CPUs depending on the workload. You also have NUMA on multi socket systems. Then we can expand out into L3 cache, use pages aligning making sure your workload runs on the same NUMA node that your GPUs are connected to. The current solutions, Kubelet does have a CPU manager. There's a few steps improving this, expanding into the NUMA support case and like pinning a CPUs but when I was looking into this, I found the UX was a little weird. It wasn't very explicit. I started looking at prior arts in the container space and one of the interfaces that I like the most is CNI, so the container network interface. I believe the way it uses plugins and the interface of how a CRI container runtime interacts with CNI to set up networking for your containers is very elegant and it makes it very composable as well. So I thought let's make CNI for resources. And this is where NRI comes in because CRI was already taken. I would rather it be named the container resource interface but we'll stick with node resource interface for now. So myself and some others in the community, we felt like the Kubelet's not the right abstraction for things like this. The lines between the Kubelet and then the lower level CRI is a little too blurry and we think that being able to hook into the life cycle of containers at the CRI level is the right way to do resource pinning and topology on a node. CRI implementations like container D, we know how to interface with the underlying host systems. We can get the information for what devices are available and this is where things like CNI for networking also hooks in. So that's why I wanted to start with building out NRI and with this we can do various things such as managing the topology and quality of service for different workload types. We can have latency sensitive workloads pinned on CPUs with very simple plugins as well as batch workloads that execute across multiple cores and then also get their cores taken away if more higher priority workloads enter the node. Inside the container D org we have an NRI repo that we've been working on the API and interface of NRI and you can see how it takes a lot of inspiration from CNI where we have a config you can chain plugins together there's a specific order in which these various binary based plugins can be executed. We have a clearly defined input and output to these plugins so that they're able to get the access that they need to the underlying pod or container information that they're setting up resources for and then they have defined output and what points in the container lifecycle that it hooks into. So go ahead and check it out at github.com slash container D slash NRI and let us know what you think as we build out this interface. Thanks Michael let's go back to the diagram. For the underlying runtime there's a component in the container D daemon and an external shim for managing container processes. The runtime in the daemon is responsible for starting up new runtime shims. It will pass the OCI runtime spec and commands to the shim. The runtime shims are the boxes on the right side. These shims are what actually own the container processes. The containers are parented directly to the shim. The container D daemon will talk to the shims about container D. We use this lightweight RPC to reduce the memory footprint of the shim. If container D gets restarted it will connect to the shim in order to send commands to the container. There are many different runtime shim implementations. The run C implementation is the most common. There's run HCS for running on windows. There are also sandbox shims such as firecracker and cota containers. Since the shims only implement this RPC interface anyone can implement their own shim to be used by container D pretty easily. Container D just needs to know about the shim in order to use it to run containers. Plugins can call into the core of container D and the core can call out to different back ends. The back ends themselves are also pluggable. For example, Snapshotters are all implemented as plugins. Each plugin can define their own configuration which gets concluded with container D's global configuration object. If you have a gRPC service it can be added as a plugin and call into the core services directly. In the client there are many options for customization. By default the container D client will use the gRPC API to communicate with the container D daemon through the gRPC API. However, a client can be instantiated with any custom implementation of a service, even allowing clients to operate completely without a daemon. You can also add your own resolvers. Resolvers are what are used to push or pull images between container D and registry. The default implementation communicates with a Docker registry using the standard OCI distribution API. However, you can implement your own very easily if you have a different or faster way to distribute images. Including your own plugin is pretty easy. You can compile in the Snapshotter and register it as a plugin just like every other built-in Snapshotter or you can implement your own Snapshotter as a proxy plugin. Let's hand it over to Wei Fu to deep dive into container D's plugin system. Hello everyone, thanks for joining me. My name is Wei Fu. I guess you all learned so many things about container D's architecture from Derek. The core of container D constructs a plugin mechanism about how to manager OCI image and how to run a container. For common cases, container D has some built-in plugins as default functionalities. In Linux platform, container D can download image with GZ format and unify it as a bundle on overlay FS file system. And then we can run it by run C. But it is just one common case. With OCI perspective, OCI spec outlines how to run and unpack file system bundle. For example, the file system bundle can be built and unpacked in various ways. And OCI runtime spec describes the lifecycle of container which can be handled in guest kernel for additional isolation. For different scenarios, there are still so many combinations here. But don't worry about it. You don't need to put your special implementation into container D call base. The container D can work with your external binary plugin as one of the backends. So let's see how it works. The first one is generic image layer support. As we know, each OCI image layer is tough file. We can compress all in captive tough file. OCI image spec use media type to describe image layers format. When you pull image by container D, the workflow is like that. The container D diff service reads the image data from the content service and then unpatch it into the snapshot file system. By default, container D can detect a layer is in GZ format. If the layer is not GZ or tough file, the container D will need string processor plugin. The string processor is a binary plugin to be a media type converter. Look at the configuration for Z-Standard string processor. When container D detects the media type is Z-Standard, it will call Z-Standard binary for decompression and return the media type streaming. The string processor allows one plugin to accept multiple customized media types. But, it depends on your own implementation. The last step of pulling image is to unpack the tough streaming into special file system in order to support different file system for image. The container D export the Snapshot Prophecy API for the third-party plugin. The Prophecy Snapshot plugin is a long-running process and the container D can talk to it on GRPC channel. After pulling image, the container runtime can run the file system bundle. The container D use the container D stream way to as control layer for different kinds of runtime which runtime has their own values and different designs. It's not good to use one connected stream to integrate different kinds of runtime by command line. So, connected stream way to provide general control API for the container life cycle hiding the implementation of running runtime manager. No matter what kind of runtime it is container D can communicate with third-party runtime implementation by stream way to API and connected stream way to also provide binary name convention to locate your own stream. For example, run C way to name we translate into the binary name, connected stream run C way to In RIS 1.4 run C way to stream is the default stream in connected D. Connected D also improves the logging plugins. At the beginning the connected standard I always redirect by the name pipe. But it requires the data receiver must be alive. Otherwise the pipe channel will be full and it will impact the running container. So, connected D enhance the container log by URI schema. Right now connected D can support the file redirection. The connected standard IO can be read into file directly. And then the schema also supports the binary plugin. It can set up a background long running process to handle the IO. So, with the file binary log schema the connected IO goes through the connected D so that the connected D will not be impacted by the logging flow. So, that's it. This is all about the external plugin. It is easy to integrate with connected D, right? Thanks. Now let's do a recap of the container D's architecture real quick. Going back over the whole container D diagram, you can see how operations flow from the client on the left all the way to the run time and back end on the right. The components on the left tend to be more stateless, the components on the right have more state. Even though our garbage collector is in the middle, it tracks resources used by all the back ends, but it operates completely invisible to the client. Our end goals to track any resource which may be used by container D to guarantee the long term stability of the run time. Now let's go back over to the container D, released back in August. It includes support for C groups V2, improved SE Linux support, support for remote snapshotters, and support for CRI on Windows. We are about to start the beta process for container D 1.5. A significant change in this release is the merging of the CRI code base into the main container D code base. This is not a significant change to the end user, but allows us to better integrate CRI components into container D. It will directly tie into container D's core services. The new sandbox API will not only allow for better integration with virtual machine sandboxes, but also allow us to clean up the way pods are managed by container D. This will also be the first release with support for NRI. Feel free to join the discussion today for container D 1.6. This release will continue the effort of integrating CRI into container D's core and improving resource management. We're also looking into ways to improve the API between container D and Kubernetes. If you are a container D user, please file issues. We're also looking for feedback from end users on our roadmap and documentation. We know our documentation is lacking for a project as widely used as container D. If you have a passion for documentation on the user journey, we would like your help. If you are interested in being a maintainer, we encourage you to get involved in contributing and reviewing code. Continuity is a high quality threshold for code contribution and any extra help reviewing code is appreciated. The maintainers also recently launched a security advisor role. This role is intended to help get individuals who have a vested interest in container runtime security involved in our security release process. As the cloud native community has adopted container D, our users have a greater need for access and communication within the community. We have been doing the best we can as maintainers, but we would really appreciate having additional support in managing the community. If this or any other role interests you, please reach out so we can help you get


Agent K-7 returns. Workers number one adventurer, K-7, form a United States secret agent who operated in 22 countries on land on sea and in the air, brings you a story of today. We take you to secret agent K-7's headquarters. This is K-7 speaking. Send in special agent M for assignment. That's one K-7. Special agent M reporting for duty. At M, last night, a girl described only as a beautiful blonde crossed this country's border and entered Switzerland. She carried a dispatch case full of valuable information. Intelligence officers who had been following her reached the border within a few minutes after she had passed. They discovered only that her destination was the city of Basel, just over the border. Her name is Ona Lajos. The document she carried must be recovered. An arrest on the soil of another country will probably be impossible. Keep me informed. The next day, a man whom the border guards would have recognized as Ona Lajos chauffeur, knocked on the door of her hotel suite. Who is it? She read ma'am's head. Come in. Is anything wrong? I am not sure. I overheard some information in the cafe that I thought might interest you. Special agent M is here in Basel. Special agent M? I have never heard of him. Why should his being here interest me? He works with K-7. Oh, I see. And what is more, he arrived but a few minutes ago. He came here from the city we left last night. So, that is interesting. He is here at this hotel? Yes, ma'am, sir. I inquired at the desk. He's in room 401. Do you know what that means? Yes, come for us. Perhaps. Hand me the telephone, please. What are you going to do? Hello? Would you please bring room 401? Yes, thank you. What are you doing? I am calling this special agent. I'm going to invite him to come here and talk with me. Come in, special agent M. I hope you would accept my invitation. I don't understand, ma'am Waselle. I don't believe we've ever met. No, that is true. Yet you agreed to come to my suite to talk with me. That at least proves you are interested. Is it not so? Do you invite me? Sit down. Now should we talk of the weather and the political situation first and then gradually come to the topic in which we are both interested? Or should I come out bluntly and ask, why have you followed me here? Miss LaHose, I admire you for your directness. Thank you. I have been admired before. And why should I not be direct? You cannot arrest me on Swiss soil. That's true. You did follow me here? Yes.  You may have them on my conditions. What are those conditions? That you pay me 500,000 francs before five o'clock this afternoon. My ma'am Waselle. That is my price. Accept it or not, agent M. I suggest that you telegraph those who employ you. Unless the money is paid to me before five o'clock, it will be too late. They'll never pay. Perhaps they will. It has been pleasant meeting you, agent M. I hope we shall remain friends. Goodbye. While agent M talked with the amazing spy, his assistant, Yvonne, waited for him in the desertered cafe downstairs. A man approached and tried to engage her in conversation. As he did, Yvonne saw M return. He signaled her to talk to the man. Oh, Miss LaHose, you're alone? So am I. Why should we not be friends? I suppose there's no reason. Well, it's better. You have a beautiful smile, ma'am. You have been here alone? Oh, I only arrived today. What a coincidence. I have been here only since yesterday myself. I think we are going to get on. You have seen the view from the mountain top. Oh, it must be beautiful. You must let me show you. Or perhaps you are with someone, your husband, perhaps. I'm not married. Oh, it is my lucky day. Tomorrow I will drag you to the top of the highest peak. I'm coming. I will meet you here. Well, why not this afternoon? Oh, if it only were possible. I am here with my sister this afternoon. I have promised to take her north. Say you will go tomorrow. Promise. I have just seen my sister go through the lobby. She will be looking for me. Then, tomorrow. I'll be here. Oh, thank you, ma'am Zelle. And now I must leave you. Goodbye. Goodbye. Well, Yvonne, you seem to have made a conquest. M, why did you signal me to talk with him? I was just going to send him away. Yvonne, that man is the one who was with Ona Laus.  What did he say? Oh, the usual thing. He wants to show me the beauty of Switzerland from a mountaintop tomorrow afternoon. Ah, then they're going to be here tomorrow. Yes, but they're going somewhere tonight. He said that he was here with his sister. That tonight he had promised to drive her north. North? It all fits in, Yvonne. What do you mean him? What did you find out upstairs? Ona Laus is a very clever spy, Yvonne. She introduced herself, said that she knew that I was following her, and offered me the documents back, if I paid her 500,000 francs before five o'clock this afternoon. She wants to sell them back to you? Before five o'clock.  He's driving her north tonight. She offered to sell to me before five o'clock. That means just one thing. Unless I buy the documents, they will be sold to the officials of an aggressor state to the north. The border is less than 20 miles from here, like before tomorrow. Then you'll have to buy them from her. You can't let the documents fall under the hands of... Yvonne, I have a better plan. You wait here. I'm going to get a roadmap. A roadmap? Yes. Ona Laus is very clever. But I think that perhaps a very simple trick will prove her undoing. A few minutes later, agent M drove away from the hotel. A short time later, Yvonne, driving a rented car, followed him. Shortly after five o'clock, the spy, Ona Laus, and her chauffeur, also took the road that led to the northern border. As they drove, the spy talked. I don't understand. After he visited me, the special agent disappeared. He's not at the hotel. I was sure he would get in touch with me before five o'clock. The documents are worth more than 500,000 francs to the country that employs him. What does it matter? We know that others will buy them. Yes, but they will not pay us that much money. We will be fortunate if we get 100,000. What's that blocking the road ahead? Something is wrong. Wait. Yes. See? The arrow points left. Oh, there has been a landslide. The sign reads landslide. Take left turn to Main Road. Oh, it would delay us. It is a no-road, but not bad. We will probably be back on the international highway in a few moments. I was sure he would meet my terms. Yeah, it is the luck of our business, ma'am said. This road is not bad. Well, I suppose I must forget it. After a time, it seemed that luck had played into my hands. See? The car on the ditch. Someone is waving. A girl? You would never miss a girl waving, would you, my friend? It is the girl from the hotel. Wait. I've seen her before. What is wrong, ma'am said?  I can't get it. Oh, this is your sister. So you know her, and I am your sister. Perhaps you will let her send back assistance from the next town. No, please. If it's not too much trouble, I'll drive with you. When we reach a town, you can drop me off. It would be easier to send a garage man back. What time will we take her with us? Here, you'll get in the back seat, ma'am said. Thank you. You'd have missed you if it had not been for the detour. Would have been too bad if you had missed. What did you say? I didn't hear. I said the road was bad. I wish we had missed it. Wait. Stop the car. What is that ahead? It's the French border, Miss Lajos. French border. You turn left at the barricade. We put across the road. Now, drive across the border. I have a gun. The French border? No. Don't move either of you. You are again in France. Stop the car. I'll take the dispatch case you're carrying. No, you don't. Turn the car around. I've got her hand. It won't work, Miss Lajos. Oh, no. Agent A, me ask two guns.  You step out of the car first. I have the dispatch case, then. Look out there, getting away. It's estimated that during the World War, the central powers had more than 25,000 agents in the field, while the Allied forces employed approximately 20,000 agents. Today, it is estimated by reliable sources that the number of agents employed by all powers now exceeds the combined figures. If these figures are correct, there are now close to 50,000 active spies and agents in Europe. Listen to for my next story. This is K-7 speaking.


OK, hi, everyone. Just getting acquainted with this. OK, no speaker's notes. That's fine. But I do have a timer, so I don't need this. OK, so back to my title slide. So I'm going to talk to you about faster product creation and fashion enterprise with serverless. What that actually means is we worked for an American shoe company that's been in business for several decades. And with my team, we've worked over the past couple years on how to help them make new products faster, bring them to market faster. And for that, we've leveraged Blender. That's why I'm here. And this little bit quirky part is that we've leveraged Blender on serverless services. I will explain what that means a little later. I will talk a lot about Amazon Web Services, maybe not that much. Just keep in mind that everything I tell you about Amazon Web Services in this context, you could also leverage other cloud platforms to do that. Mostly, that would be Azure Functions or the replacement for Lambda Functions. Or Google Cloud Platform also has their own way of doing it. So that would be possible just in this context. We were working with Amazon Web Services. So I'll start by talking to you about the way at that company. Until recently, they were designing new shoes.  You happen to be attending a wonderful Blender conference because that's something you like.  Maybe I would like to create a new variant of that product for next year. So this is how you would do it the old way.  You try to find the vector drawings for that shoe. You load them into probably a couple of views, like side view, top view, maybe other sides. You load that into your 2D drawing favorite application. And you start picking the color because you really like that color. So you apply that color to the different parts into every view. And now you're like, actually, you know what? Why don't we create a limited edition for next year's Blender conference? And we add a Blender logo on those shoes. And that starts getting really tricky because you're like, OK, I can put it on the top view, but what would it look like on the side view? You're not so sure. But you like the idea. You like it so much that you want to take it to your boss and you want to pitch it. Hey, why don't we create a limited edition for next year? And now it starts getting very expensive because if your boss likes it, you're going to start going through the physical prototyping process where you're going to create a more technical description of that concept you had in mind. And you're going to ask a factory somewhere around the globe to create that product physically and then send it back to you. So it's going to take months. And it's going to cost thousands and thousands of dollars. So you really want to be sure that that's a good concept. But it's really hard to visualize, to imagine what this is going to actually look like. So you really have to be very intuitive about it. So there has to be a better way, right? So now let's look at the new way, what we implemented for that company to create new shoes from now on. So there's a little bit of blender here, but this is a website. The shoe designer connects to the website. They load a blank 3D model created by a 3D artist of that specific shoe. And you have access to a palette of colors, all sorts of materials. So you apply colors to different parts of the shoe as you see fit. You can look around it. You can add graphics just the same way in that 2D drawing application. You could load any drawing. In this one, you can also upload a drawing and SVG file or PNG. Apply it to a certain part of the shoe. And you can play around with it. You can change the aspect ratio, rotation position. You can get crazy and create like a psychedelic blender pattern. You never know. I like that. But I'm not a shoe designer. Don't hold your breath. It might not happen next year. But let's say you like that. Now you go see your boss. And they're like, oh, OK, now I see what you meant. And you actually, because you had this real-time feedback and it was not such a pain to place a graphic on different views, you actually had better ideas. You iterate more. You iterate faster. You can show your boss something. They can give you feedback like, no, it's too small or maybe you should space those logos out. Because right now I can't even see it's a Blender logo anymore. So the fact that you have a better view, like fosters collaboration, and already improves the process a lot. If you're wondering, the technology we're using on this part of the website for 3D viewing is the SketchFab viewer. Maybe there are some SketchFab people in the room. I know there were SketchFab people in the room not long ago. So you probably all know SketchFab for the content library, but also for the viewer that's online. And they have a commercial product that companies can buy to embed it in their software. So it's very optimized. It looks really good. It's quite performant, even on lower-end devices, which means that our shoe designers here, they can just log into, let's say, this COVID and they are working from home. And maybe they don't have such an amazing workstation. This works really smoothly. So now you're wondering, like, what about Blender? So there was actually, oh, sorry. Oh, this is going to be painful. There you go. There's a Save button at the top. When the shoe designer clicks Save, Blender kicks in. We're going to trigger with Cycles in the back end a bunch of renderings of the shoe to give you a much more photorealistic look. A much more photorealistic feel of what that shoe will actually look like. So it's one more step further. You had this three of you could play around with. And now you have the real feel of, hey, depending on how we like it, you see how the material reacts, you get just a better feel of what the end product might look like. So maybe you can get more additional feedback if you have shiny materials. They have libraries and libraries of materials that are very accurate scans of the fabrics that are actually available in the factories. So they can load those high fidelity scans, apply them to different parts of the shoe, and get as realistic as we can a view of the shoe using those materials. Whereas in the web 3D viewer, maybe some materials would not be rendered as accurately. So we render one view and different views. And for each version, let's say we call that a shoe project. Like today, I met this person. I like their shoe. I create a new shoe project. And I have several versions of that project. You can render many versions and the same sets of views for all your projects. What this enables is now at the company level, you can very easily browse and look at all the projects that your whole design team has in progress and have a general, like a global view of what's happening in the heads of your designers, basically. And because it's consistent, it makes it really easy to navigate. But kind of like accidentally what this enabled is we have these very nice pictures of shoes. And what we would usually do at that company is create physical samples like prototypes, expensive ones of the shoes that are selected for the upcoming collection. You make them, ship them to your designer's office. And then you make pictures of these shoes. And out of those pictures, you create catalogs. And those catalogs are going to be used by the sales team to sell the shoes to distributors. Now you have 3D renderings. You can skip all that. You can decide, these are the shoes we want. Let's generate that catalog already. And maybe let's get feedback from our potential buyers off of a completely virtual catalog to see if there are actually any products they might like more than others before we start prototyping. So really having this adding blender to the loop allows for use cases that we didn't have before. So let's get a little bit technical. How do you get that shoe exactly? From when that designer clicked the Save button, we have a JSON representation of the configuration of the shoe, what we call the configuration of the shoe. So it's a set of parameters that basically says, this material is on this part of the shoe. This graphic is here, position like this, et cetera, et cetera. The Lambda function grabs those parameters. It then loads a container image. So it's a Docker container. It's a way of packaging applications to allow them to run almost anywhere on servers, so in the back end. There happens to be a very helpful container image of Docker that is maintained by the R&D team at the New York Times Go figure. And that's available to anyone to try. So that's what we use. So the Lambda function takes this image of Docker. It loads into it a blender scene containing that shoe. And with a Python script, we apply the configuration to the shoe, and we start rendering. And then we output that shoe and store it in the cloud and the Lambda function dies. Why did we use serverless? Because usually, when you think about rendering 3D things in the cloud, you think, well, render farm, big machines. This is what a typical load profile of our servers look like during a normal work day of the design team. Most of the time, nothing happens. And we're not rendering movies. The scenes we're rendering are pretty simple. But we have spiky loads. So at some point, we're going to need to render six views of one shoe. Maybe there are going to be two designers who saved projects at the same time. So we have very spiky loads where we need a lot of computing power at one point. And then five minutes later, we're not going to need anything for the next eight hours. So we chose serverless because it scales to zero. This is really important to remember. You don't pay for anything if you don't use it. And that can be very valuable. But also, it starts very fast. Like, we could say, OK, we have a render farm. And outside of work hours, we shut it down. Or during the lunch break, we shut it down. But when you want to spin up instances, they take a minute to start. But it takes our Lambda function a minute to just render the image. So the big advantage of Lambda functions here is that they start in just an instant. Basically, between the moment when the user clicks Save and the moment when Blender starts rendering, it just has only one second passes. You click Save. Amazon Web Services provides you with however as many lambdas as you need. Loads Blender starts Blender, loads the scene file, and starts rendering in just one second. So it's really, really blazing fast. There's also no maintenance because there are no machines that you manage. You're not going to have to upgrade the Linux version or apply a security patch. I don't know, check if you have malware. There's none of that because you just tell Amazon, hey, run this compute task. I don't care how you do it, just get it done. And they do that. It's also quite easy to set up. Initially, when we were given this task, we thought, oh, my god, yeah, we feel like we can render a scene with Blender in the cloud. I happened to know, oh, yeah, there's the Vpy, the Python API, for Blender. And surely we can do a lot of automation with that. But does it mean we're going to have to deploy a server farm for this, like a render farm or a big machine? And when we realized we could actually do that with Lambda Functions, what a big advantage is that, in just a few files, and I'll show you a little bit more about that, in just a few files, you can describe this workflow to say, when someone does this, load this container image, run this script, save the output over there, and shut down. It's also highly scalable. If you need 100 Lambda Functions in one instant, they will be there. And it's very reliable. If it ever fails, it will retry instantly and succeed. So Lambda Functions are really a painless way of building highly scalable and reliable systems. But more importantly, why we picked that is that it's powerful enough for our use case, which is really a niche use case. And I attended presentations where you render movies. I would not recommend rendering a movie on this. So this is how we built it. Basically, there's four files. I'm not going to walk through them too much. But I'll just name them. So there's the Docker file. That's the red arrow. It says, go grab that image that's maintained by the New York Times. And that's what we're going to use to execute our code. There's a serverless.yaml file. It's leveraging a framework, open source framework, called the serverless framework, which allows you to describe by code serverless architectures in the cloud. It's insanely, insanely valuable and helpful. And basically, we say, hey, I want Lambda Function with this amount of memory. I wanted to have access to some cloud storage over there. I wanted to run this command when it's executed, et cetera. And then we have two Python scripts. One that just says, hey, when the Lambda Function wakes up, just make it run BPY with this script, so the Blender API in headless mode with this script. And then that's the last script, script.py. That's where we say, and that's where you would add all the logic you want to do automation. Here, we're doing rendering, but you could do, like I said, like we're applying a configuration to a model. You could generate new shapes with, I don't know, geometry nodes. Anything you can do with BPY. You could do at that stage. If you want to try this at home or at work, which I encourage you to do, just search with your favorite search engine, Solace Blender. The first result should be just a nice recipe that I wrote where you can see all the code and play with it. Why you may not want to try this at home? This is really not for everyone. This is not a render form. If you were to try and render a full movie using this, you would go bankrupt. You have to bear in mind that serverless are a very smart allocation of compute resources sharing between all the Amazon users.  One way to solve that problem is to say, hey, we're going to rent virtual machines that run on actual machines, and we're going to increase the overall usage of compute power around the world. And the next step is to say, we use serverless functions where we share, actually, even more customers share the same pool of resources. The trade-off is that one second of compute on serverless costs orders of magnitude more than one second of compute on a machine you would have under your desk. It's just that if you don't use that machine all the time, you're paying for nothing. So with Lambda functions, you only pay for what you use, but what you use is actually more expensive. So if you need compute power all the time, like rendering a movie over two weeks, don't do that. Very bad idea. So that's about it. I would be happy to discuss it after this presentation with all of you. Just a few words about myself. So I'm Jean-Rémy Baudoin, or JR. I live in the US. No one gets Jean-Rémy if you live in the US. I'm French. I live in New York City. I grew up doing a lot of 3D. Somehow got into web development instead. But I end up doing 3D, which is pretty nice. And I work for Theodore. We're a software agency. We build web applications. When I say that, people think websites. We do build websites for big names. But a lot of what we do is actually invisible to the public. We build a lot of applications that have very few users, like the designers at that company. We're based out of Paris, London, New York, and we're about 600 people. And that's about it. Thank you very much.


ID token, access token, ID token, access token. What's the difference? All right, maybe the difference between ID tokens and access tokens is not quite that dramatic and stressful, but you probably do have questions. Maybe you've worked on applications where you're building authentication or incorporating authentication with a third-party platform, and you've heard these terms, ID tokens, and access tokens, and you're not exactly sure what they are, and most importantly, how they are to be used, and most more importantly, how they're not to be used. So let's talk about all that in this video today. There's also a cheat sheet that will break down the difference between ID tokens and access tokens to recap all the things that we say in the associated blog post. You can find that and download it for free with the link in the description below to the blog post. That said, let's go ahead and dive into the difference between ID tokens and access tokens. All right, for ID tokens, let's start by talking about OpenID Connect. OpenID Connect is an open standard for decentralized authentication, and the good thing is this is used by many or all of the most popular identity providers out there, things like Google and Facebook and Twitter. So this is basically a workflow for a user to authenticate themselves and the output of this, what OpenID Connect provides as an output artifact is an ID token that proves the user has been authenticated. Now for ID tokens, these are specifically encoded as a JWT or JSON web token, also referred to as JOTS, although I still don't quite get that. So I'm going to use JWT in here to refer to JSON web tokens. So ID tokens are required to be in the format of a JWT, and JWTs typically consist of three parts. They've got the header, the payload, or the body, and then the signature. For reference, if you ever have a JSON web token and you want to see the information that's inside of it, you can head on over to JWTIO to decode that information and see all the stuff that's right there. Now inside of the payload or the body with the JSON web token, you'll have several different claims or pieces of information. You might have a sub property, which is the unique identifier for a user. You might have an audience, which is basically who the intended receiver is to use this ID token. This will be important. We'll come back to this in a second. You might have the issuer, the identity provider who created the token, and you might have the name or other pieces of information about the user themselves. Now I mentioned this audience property would become important with ID tokens and here in a second with access tokens. So the audience property is defining which application is meant to be the final recipient of an ID token. In most cases, that's gonna be like a client application because we might do things like this. Inside of an application, you log in, you then get redirected back to your application and after you've completed the login in the top right corner, you might see your username and your profile image or something like that with a dropdown button and it's got logout and settings and dashboard and things like that. So that ID token is being used to grab that information about the user like their name and their profile image. So who is the intended final recipient of this ID token? Well, it's the application that the user is currently logged into and that ID token can be used to display their information on the app. Now, let's transition over to access tokens. Access tokens are specifically designed to allow you access to a resource. A resource could be a file, it could be a database or most likely it could be an API that you can call to do CRUD operations on some sort of data. Now, where do access tokens come from? ID tokens came from OpenID Connect. Access tokens in this case come from OAuth2. OAuth2 is designed to allow an application to access specific resources on behalf of a user. So let's talk about an example here. Let's say you log into your LinkedIn app and you start to post on LinkedIn frequently and you realize, hey, I might as well cross-post these things to Twitter so that I get that much more exposure for the content that I'm creating. Well, maybe LinkedIn could add some sort of ability to do that for you. So the way this would work is LinkedIn would redirect you over to Twitter. You would authenticate against Twitter and in addition to regular authentication, you will also grant access to certain scopes or things that the original application, LinkedIn, can do on your behalf with the resource server, which in this case is Twitter. The resources are reading your tweets, posting to your timeline, things like that. So you'll have to grant access to those certain scopes and embedded in that response is the access token that has the authorization to do those very specific things. Now, unlike ID tokens, access tokens don't have a specific required format. They can basically be in any string format, but you will often see them in the format of JWT's JSON web tokens the same way you will for ID tokens, although it's not a requirement. Now, one thing to note is there's currently a specification being worked on and formalized now that will define how to structure your access tokens as JSON web tokens, but we're not quite there yet. So in this case, access tokens can basically be any format of string. Oftentimes you will see them in the format of JSON web tokens, and that's what we use at all zero when you're making calls to a specific API. So let's go back to this idea of audience or who is the intended receiver of a token. For the ID token, we said it was the application that the user is logged into and we use that to display information about the user on the page and do a few other things. Access tokens are a little bit different. Access tokens are meant to be sent to a resource server to access some sort of API or data or something like that, which means if I'm inside of LinkedIn and I do that redirect over to Twitter, let the user log in and grant access to those scopes and redirect the user back to LinkedIn and then want to make a call to Twitter, Twitter as the resource server is the final intended recipient of this access token. So that is where that access token is supposed to be used. All right, so let's take a little bit of time to recap this first by starting with what these different types of tokens are not intended for. ID tokens are not meant for authorization. They are strictly for verifying that a user has logged in or authenticated themselves, which means they should not be sent to an API. Remember the audience claim, that audience claim is the application that the user is logged into, not a separate API that we will send a token to. So we do not send ID tokens to separate APIs. ID tokens also do not have any authorization information included inside of them. So they would basically be useless to send to an API anyway. So we don't send ID tokens to APIs and we don't use them for any sort of authorization. On the flip side, access tokens are not used for authentication. The interesting thing about this is that based on an access token, you can't actually make any assumption about the user's identity or the fact that they're logged in or not. Think about it, if you log into an application, if I logged in to LinkedIn, I go to Twitter, I do the redirect, I get the access token and then I log out of Twitter, that access token is still valid and still can be used. So the access token itself doesn't actually guarantee me that a user is logged in at all. So let's do the whole recap here. ID tokens are required to be in the format of a JWT or a JSON web token. They are the output of a workflow called OpenID Connect and they are strictly for authentication. Access tokens, on the other hand, do not have a required format, although there is a specification in the works for formatting them as JWTs, JSON web tokens. But access tokens are specifically used for delegated authorization and access, not for authentication. So oftentimes you'll see that these access tokens are sent to an API of some sort and embedded in that token is some sort of information that expresses its ability to do certain things. If you're looking for a quick recap of this and a really nice cheat sheet, again, you can get that for free in the link below in the associated blog post with this video. We hope you enjoyed it. If you have any other questions, let us know in the comments below. Thanks for watching and we'll catch you next time.