First, thank you for coming. I tend to move a lot, so I will try to keep closer to the mic. Well, thank you for coming to this session. This time we are not going to talk about Drupal console, so you are in the right session. I think we're not even talking about Drupal this time. We could churn if you weren't. Yeah, it's this is a really fancy name with a lot of boss words, creating a modern web application using Symphony API platform, React, Redux, and WIMS something, right? Yeah, we have a bonus we didn't promote, so this is a surprise for people who sacrificed your lunch for here, so we are going to talk about a little bit GraphQL. How many people are excited about GraphQL? We shouldn't be. You are my friend now. Okay, let me introduce us. This is Jesus Manuel Olivas. He is our head of products in a company called Winno. You can contact him on Twitter and GitHub as GM Olivas and Drupal user, and this is his blog website. And Eduardo is joining me this time. Eduardo Garcia is our CTO from Winno Company. Again, this is all of places where you can find Eduardo. So, about what we give, as we say, we are the Winno and us as persons, we are the maintainers of Drupal Console. So, thanks to the community last week. Okay, thank you to the community last week. Sorry? Yeah, closer. Okay, so as we mentioned, we are the company and the main maintainers of Drupal Console. So, thank you for the community. Last week we reached this number, two million downloads since we started the project. Maybe the most interesting thing about this number is like eight months ago, we reached our first million. So, now we are in two million, so let's talk about the reception of this project about the community. So, if you are interested in more details about the things that are coming about Drupal Console, please feel free to try to contact us. Like, for years, getting the first million, which is the hard one, the first one. Where we are? Yeah, so we are a distributed company, we are fully remote. As you see, we are basically in America, but we have a couple of resources in Europe, France, myself in Australia. This is basically going with it, we are 36 resources. And what do we know about? Yeah, so as we know, as maybe you know, and you think we are a Drupal company, but actually we do more than that. This is why we are creating this session. So, basically nowadays, every Drupal company is a 80% Drupal company, but actually it's doing more than that because Drupal is an integrated system. So, you can see the map, the CMS is 28 resources about that. But we also have people working in React, working in Angular, working in React Native, working in Angular. And also, people are having different interests. So, people are doing crazy stuff, like trying to connect Drupal or Symphony with artificial intelligence with Python of this kind of stuff. So, this is the mesh that we have been talking about for the last two, three years. It's like a create bridges, live in the island. So, now we are using these bridges to try to get connected to everything, and this session is about that. Yeah, well, again, we're going to, topics that are going to mention is API platform, the Symphony API platform, which is a framework that will allow you to create out-of-the-box and rest endpoints and graphical endpoints. So, we are also going to talk about GraphQL, and this is the tool we use for the API part, for the front-end part. We use React ES, Redux, and Saga, and for the components part of the UI we use and design components. And this is most like a recipe we have for building projects. Whenever we need to create a project that requires to be in API and there is not content-centric, there is not content management, there is no revision on the data. It's mostly like we need to put data on it and then somehow interact with that data from different places, like from the mobile, from the ZLI, from a web app. So, this is what we tend to use instead of going to Drupal and use headless or decoupled Drupal. It's kind of like decoupled Drupal on the Symphony way of doing things. And how we reached this solution of this recipe, as I mentioned about the bridges to leave the island. So, actually we started using Drupal with React, then we noticed we could use React with Symphony, then we noticed we could use React with Node.js, and then we noticed we could do Node.js with GraphQL. So, we were really far away from Drupal, and now we decided to say, hey, we could do the circle. We're going to use Drupal and Symphony with GraphQL. So, that's really, even if you are not using Drupal, you are not at the factor, right? So, you are trying to reach the technology and close the circle to try to integrate the solutions to provide the best solution possible for your clients. Yeah, in talking about Symphony, this project is based on Symphony Flex. I don't know if you are aware of this. There is latest version of Symphony, Symphony 4, but they also have a project they call Flex, or Symphony Flex, which is basically a Composer plugin that allows you to automate some of the most common tasks. Kind of like, you know, it makes changes and improves the Composer Require, Composer Update, Composer Remove commands, adding in, whenever you enable a module, copy some configurations to your project. And, well, the main difference you will find out with Symphony Flex is, as the director structure is a little different, you will find out a config directory on your root project and the root of your project, and this is where all of the bundled configurations are located. Other than that, it's pretty standard Symphony installation. Yeah, let's talk about the platform itself. So, API platform. As I mentioned during the beginning, it is a REST, a GraphQL framework, allows you to build modern API projects. And a good benefit of using a tool, the same reason why we use Drupal, we use Drupal because there is a community, there is a lot of modules that we can take advantage of, same thing with Symphony. By using the API platform project, we can take advantage of other modules to interact with the project. It means if we're required to login, there's a bundle for that, like user login, if we require authentication, or extending the authentication using a JWT tokens, there's a bundle for that. So that's the big benefit of using a project like Symphony Flex in this case. And the project, it's breaking into four pieces or four components. The API, which is the piece that we will be talking about, there's a schema.  So you can use, I mean, automatically out of the box, use those and, you know, populate your database, doctrine database. It also includes an admin interface. It react fully, I mean, functional, create, retrieve and update and delete the interface. So you, without doing nothing used by exposing the endpoints, you will be able to interact with this. It allows you, like, a form for adding and editing fields. It also adds this crew generator. It's a JavaScript scaffolding tool that allows you to create, I mean, react components. And in order to use the API platform, it's way too simple. I can say, you don't need, I mean, like, 30 something clicks like Drupal. It's just git clone. And you are all set. The minimum adjustments that we tend to do is change the route. So we point to API, something. And since we are changing this configuration, then we change the data entry API endpoint for the client application. And once you git clone the project and make that change, the only thing you need to run is compose, Docker compose app.  I mean, out of the box is fully functional.  This shiny page that is telling you that it's installed and it's fully functional and it's worked. It might be what you, the first thing you want to do, it's adding more format. By default, it supports LD JSON and JSON format are pre-configured for you, but you can add way more formats. And those are the available formats that you can use. And as in any symphony configuration, when you have an array of values, the first one is the default value. So if you want to use LD JSON as default, you just put it on the very top. If you want to use JSON, just move JSON on the very top of this list and you are all set. And everything is configurable through YML files. Well, might be, since you are building an application, the next thing you're going to do is to start adding entities. In order to add a new entity, as in, like, you know, something like an entity in Drupal or a content type if you want to, you need to, in this case, you need to create a class, a PHP class. So this is, you know, source entity directory is the place where you store your classes. It's a plain PHP file. The only thing you need to add is annotation. You know, this is an entity allowing doctrine to discover this new entity. And that's it. And I highly recommend, we highly recommend you to remove the default entity that is part of the project, which is great. So let's say for the purpose of this example, we are going to add these three entities, post, post type and user. I mean, we're not trying to build in a CMS.  So we're going to try, we're trying to use those concepts here. And remember Drupal hook update? Well, Symphony has something called doctrine migrations model that allow you to, to store on your, on the file system, all of your changes, or your database schema changes. So by running, let's say if you add a new entity file, you know, post that PHP entity or post type that PHP entity file, you just need to run migration doctrine migrations diff and this will create a new file for you. And this file will contain the schema changes.  So it's basically like updating, allowing you to store on the file system and commit on your, allowing you to commit on your repo all the databases schema changes and, you know, translate and move easily between environments. Well, and as I mentioned, one of the reasons of using Symphony is because there's a lot of bundles for adding an extra functionality. Since we're building an API tool, we require to have a login user login, I mean, interface or using login functionality. So in this particular case, we are, I mean, we suggest you to use false user bundle. If you don't want to, like, grow and write all the integration yourself. And if you are using false user bundle, you need to be aware of this to blog post. I'll share, I'll post the, we'll post the slides on the, on the note page of the session. The first one is the official documentation of the bundle. And the second one is a bundle that is telling you that you should not use the bundle. And it's, in the end, it's not, it's not telling you you don't use it. It's telling you, I mean, the benefits, the pros and cons about using it.  So good, I mean, a good, I mean, having a better understanding of what you're doing when installing a module or a bundle for extending your, your project is a good idea. So this is a really good read. I mean, you can have a better understanding of what you're doing. You're adding legacy code to your project. And then you can decide either to use it by knowing what is happening or use write one yourself. And another thing we tend to use a lot is creating commands. We like to automate things, you know, within, or at least I think whenever it's human involved in a process, there are chances or errors. So we like to automate things. In this case, we create, I mean, one single command to initialize the whole project in symphony. Same thing we use in Drupal, Drupal console. So we create one command, which will take care of running the database migration and executing all those migrations and populating data on their, on the entities. And for populating data with fake data on your project, you can use Alice bundle and basing, basing a faker bundle. Let's move to something more interesting. Yeah, let's take a look how the, how they, I mean, the project looks like, remember what I told you, use Docker compose app and just create those three files for the entities. Once we have that, and if we do something like this, so this is how the project looks like. So whenever you go in for the initial page of your, or your endpoint, which is in this case, well, API, API, you will see something like this. All of your entities are listed here, and you can start playing around with those. So it means if I go to post and want to try out, I can try out here, and this will execute. What I will see here, they will show me the result, the result of all the data. Well, this is really important because when we install those system, we spend a lot of time to try to figure out how to access and what results we have to have. So visually and quickly to try to have a better idea about what is going on and what specific data you already have, or you could do compared with your database to try to be sure that it's the same. And if you want to change the format that you are interacting with the endpoint, you can just, I mean, change it here and just execute it again.  If you want to load the JSON format, you can go post.json. If you want to try the JSON-LD, then you can try post.json-LD.  Now I'll show you how it looks like. And if you want to load one post, I mean, one single post, you can do something like API, then entity, name, and then the ID. And for making calls from your CLI, remember what I told you about the reason for us, for us to building an API project is because we know we want to interact for different clients, in this case CLIs could be a client. So you will do a get, you know, you can use curl or wget and then using get and you call the endpoint URL and you can specify the content type that you are accepting or you are requiring for the endpoint to give you back. In this case, you can use JSON or LDJson. And for adding posts from the CLI, it's the same thing, you can use post, the post method and then you just pass the post, the URL, and you can start iterating here. As you can see here, we are passing the data we want to insert. So in this case, we're telling, you know, let's post in this URL using JSON format. I mean, and I want to use JSON and LD for passing the data and we can specify fields or, you know, property and value that we are passing to the endpoint. And for updating and removing posts, same thing, you can use HTTP commands like put, delete. So I mean, everything is there, it's out of the box. You don't have to do nothing other than just make your entity, enable your entity. It's a matter of adding an annotation in your entity and that will be automatically discoverable by the framework for you. And when you're using REST, as you can see here, when we are calling an endpoint, let's say like post or a single post. And you have entities and you have nested entities, you know, like in Drupal, we have relations, we have a field who is pointing to another entity or content type, which is related by an ID. In the case of REST, most of the time what it happens is you need to do like two calls. The first one for getting the main entity and another call, another REST call for getting the relation. In order to fix this problem, the API platform allows you to use the serializer component of symphony. And by using an annotation and something they call normalization context and denormalization context, you can create your own groups and say, you know, when I'm reading, when I'm using the endpoint for reading data, I want to enable this relation and instead of showing me the ID, please go and, you know, pull the data related to this entity. You know, it's like a relation, but it tells you, so it brings you back, not the ID, it brings you back the data from the related entity. The downside of this is you need to add, I mean, a single annotation to every single field that is an entity, I mean, is an entity relation or one to many relation, which is kind of, I mean, could be kind of cumbersome, so we decide to instead do something else, which is GraphQL. Exactly, so it's not like the other solution is not working, so it's totally usable, but we were thinking about exploring another option to try to do things easier as possible. So GraphQL, if you're not familiar with that, you could think about like a middleman or is an abstraction layer between your client or your backend, in this case, is symphony. So that's the solution we're going to explain here. You could take which part you want, if you like the server side, key with that, or if you like the client side, key with that, and you could use GraphQL on them in the backend, could be anything, because GraphQL is an abstraction to allow the client to decide exactly to take whatever they want from the server. Instead of to try to be aware about how many fields are going to receive, if it's going to work or not, so this is especially good for GraphQL.  So the idea is that GraphQL, the foundations are in two concepts. First is types, so you just need, types is something like a unit to define, so maybe in the other side of the server is a FORTRAN system, it's a database, it's a text file, so you just define what are you going to return to the server, to the client from the server. And the other thing is the resolvers, which is how it's a function to help you to combine all the sources to try to return the specific type you want to return to the client. The good thing is using this package, the Webonics GraphQL PHP, integrated with API platform, all this matter is resolved for you. So using this doctrine schema, so you don't need to be worried about that because in other GraphQL implementations, obviously you have to write by yourself because we are using a symphony solution, you just, you take the solution you already have, you install this, and then GraphQL is ready to use, easy as symphony. So the whole process we have covered until now could be the outside the Docker part, could be five minutes or less. And the composer part. So the same way REST endpoints are automatically discovered by the platform for you, same thing for the GraphQL endpoint, so you don't have to do nothing other than adding an annotation, which is like, you know, and again for the endpoint, and that will be for the entity, sorry, and that will be automatically discovered by the system. Yeah, so after installing the package, as the same way we did with the API platform, you need to define what you, if you want to expose, this is GraphQL, what I am going to show in a minute, the theory is only for development, because this is a helper for you to try to build the queries you are going to execute with the client into the server. So when you are going to production, please disable. Yeah, make sure you're disabled, unless you want to expose your endpoints of the world. Yeah. Okay, so the idea, this is a typical query that you could do with GraphQL, so you have, you need to provide what resource you want to do. So in this case, with, because it's symphony, so in theory, GraphQL, no, in theory, no, it's real. So with a regular rest, you have many entry points, and you could attach and then a sequentially request, but in GraphQL, you only have one.  In this case, this is a call for a specific post, and we are getting three fills, right? So you could think about this, like maybe you are doing a mobile application, and this is the fill release. This is something for iPhone, all version, and then you get those three fills, and everything is working. But later, you can add more fills. Okay, but later, maybe you do an next I direction in your application, maybe you're more rich content. And then remember what we do with serialization, like I use the reference with entities. So in the resolver part, which is, is already did for you, because for the component, you could decide to try to get more rich information. So imagine you have two clients, two different versions of the mobile application. The one client, they have the last one, but the other guy, for any reason, he already have the old one. The idea with GraphQL is that both will be functional, because the client is deciding what he really wants. So this is the second version, and then you decided to provide information about the machine name of a related entity, and now we are getting more information from our server, if we want. And if you see the ID in this case is the resource you want to try, it's the same. It's just like the way I like to think about GraphQL is like the client is the boss, right? So the back end is just, is just to provide whatever you need. So as you can see here, we have two, two different calls to, to the GraphQL endpoint, we are fetching some fields in here. And in the other one, we are fetching different fields, as Andrew mentioned, you can even take like, you can fetch related data, any field that you want to, you can remove fields from here. So you are not fetching the whole data that you, that your REST, as REST is doing it for you. And well, if you want to use the CLI for doing this, or in your project, you can make sure you also, you can specify the content type, which is the type that you want to get returned, like in this case, I'm asking for the GraphQL endpoint to return data in using JSON format. And I'm passing a query. So this query that you can see here is the same one we have on the, on the Graph, Graph, GraphQL part. Okay, remember what I told you about users, so we enable that false user bond, right, which just allows me to interact with the system by providing a user in files where it also takes care of creating the database that require tables and all that for me. Might be, I mean, but in this case, we're building a decouple application. It means we have an API in one part, and we have the client in a, in different part. And in this particular case, we are using JavaScript for using the client, which is a totally different technology. For this particular case, we use JWT will allow you to log in a user by providing a user and password and return you back a payload of data. And that they include a token, which is like an ID. And you can use this, this, this, or that ID for the, I mean, following interactions with your client. It means you set your user and password, read the value that returns for you. And that value has a time, I mean, time to leave like, say, like an hour or 30 minutes, it depends up to you, how do you configure. But basically, you keep using that ID, instead of keep passing your user and password for the upcoming request. And in order to do this, we use those bundles. So again, same as RuPaul, there is a, there is a module for that. When using symphony, there is a bundle for that. We're using those bundles for the first one is for providing the authentication, what allowed me to expose an endpoint that I can call and will return me data. And the other one is the refresh token bundle. So we introduce this bundle to avoid forcing the user to reenter his user and password credentials whenever the token expires. So this bundle allows you to send the old expire token to the application and returned you back a new valid token. When using JWT, I mean, you might want to change the payload data that it returns to you so you can create a new service. I mean, same as in RuPaul, fortunately, because RuPaul is in symphony components which register services, creating a class and then registering a definition on a YML file. So what we tend to do is creating a service, tagging as a listener, and we on the on create method that we implemented, we can change the data that by default the JWT2 project is returning. So you can add, let's say you want to add the organization ID of the user, you want to add the role ID of the user, and this will return you that data the first time when the JWT token is created on the system. And sometimes what it happens is you can probably create specific data for your token, but you don't want to fetch all of that data. You can change the payload that it returns for you when asking the token data or the values that contains that token for you. So you can use the same thing, you create and register an event, you tag as a service, and you change the payload that is returning it for you. But maybe when we talk about server side, now let's talk about the client side. So we want to talk about some combination with React, Redux, Redux Saga and Andesign. Maybe the less popular here is Andesign, we will talk about a little later. When you're in here, it's in video games. Are you aware of Overwatch? Yes? No? Okay. So this is a framework created for Alibaba, the Chinese e-commerce company. So they are investing a lot of technology in open source. So how we ended up here, we ended up here because we are starting using Andesign. And then we found that like we want to have all these products with React, with GraphQL, with everything. And they create a micro framework to try to wrap all technologies in order to create a rapid development using all these solutions. So check it out later, the URL. So the good thing is when we started this, everything was in Chinese. And then we learned Chinese. Yeah. And now it's in English. Now we are learning English. Actually, I found it because I, yeah. Yeah, I mean, last year, a year and a half ago, every single issue was Chinese. Actually, there's a pose on Medium. You know, this is a great project, but all the issues are Chinese and documentation. And they really took it on the good way and they improved a lot. So now the issues are Chinese and English, documentation is English. Two years ago, when I started, everything was in Chinese. But it was so good that I said, okay, Chinese is not a problem. I could use the translator to do that, but it works like a charm. Yeah, seeing a lot of people is using it. It's pretty awesome. So as I say, the travel is like in this side. It's circular. We started with React, which is famous for everybody. And at the beginning, I would try to find a set of components to allow me to create a complete solution. It's like Drupal for CMS because there are too many dispersed components. Maybe we reduce our development time in terms we don't need to redo the code, but you need to spend a lot of front end to try to make all of these components look similar. Like it's your complete application. So you are losing and gaining. And also you need to learn any specific API for this specific component. So the inputs were different than the slider. The calendar was different and blah, blah, blah. So what this guy did and designed is they have components for almost all the things you could imagine. They have a consistent API, a consistent user interface. And it's easy to try to replace the look and feel using less. A consistent naming convention for parameters and properties, which is just great. It's just awesome. So we started using React. We started with design. We say, okay, we could use Redux, which is to React itself have a simple state system. But if you want to create a complex application, Redux is the best to try to have a complete state system across the application. And Redux Saga is the evolution to try to easy access and managing your state to facilitate your development process. Yeah, because when you're calling end points from your grading actions, then you end up adding reducers and creating namespaces for your state. Because in the end the state is just an array, JavaScript array that you interact with. And we find out using Redux Saga help us to do the API calls and then doing calls to update the state. So basically the whole recipe here is pretty straightforward to use. I'll show some code. Don't worry about if you don't understand what you see because it looks pretty darn thing at the beginning. But once you find out, I mean, start getting like, use is pretty straightforward. It's like Drupal when you start, it's like, wow, what is this thing, it's monster. It works, it works great. Yeah, so the DBA project, the Overwatch stuff, so they provide a solution on, as usual, it is not a perfect solution. So they use something Rode Ho to try to automate stuff. Which is another Overwatch character. They have, but we found that it was difficult to try to create like a global configuration or something. So we disabled that and we use Webpack, which is pretty famous, pretty famous for that. So we use Apollo Fetch, which is created by the creators of Meteor.js in order to get the connections from the GraphQL in this case, the symphony server. As you say, we use JWT, the code in order to do the login to the application. We use local storage for simple storage, obviously, and for more complex objects and interaction in the application, we use indexDB. Also, there are other solutions. Yeah, indexDB, it's pretty much like the definition or the standard and there is like, you know, same as in Drupal. Like hundreds of packages on NPM that you can use. I mean, just pick your weapon of choice. And it basically allows us to store or even for encrypting data on the client and also for more complex structures. And the last part is something that I like a lot. So at some point, unfortunately, the symphony GraphQL implementation or the symphony platform GraphQL implementation, it doesn't support subscriptions for GraphQL queries. So we end up adding to the recipe Redis. So we use Redis on the PHP side for queuing messages using emitter, so emitting messages on Redis. And then we use WebSocket on the client side to reading all the messages on the client application. Because again, fortunately, it's not supported yet. There is an issue for that. We'll probably jump into the issue and try to help if we can. And if you can as well. Yeah, so the theory about all this solution because every single point of here is like a, it's a nightmare for a lot of people because there is not a cohesion we could find in Drupal or symphony. So only the socket EO is like, oh, I need to start as preserver.  But using these solutions with the DVA and all this, everything is getting better and better. So we take a lot of these techniques, socket EO and Redis and everything in another implementation we have with Meteor.js and using React. So as I said at the beginning, the idea is like a you could jump technologies and you could reuse the logic you use to solve in other projects. So before to use GraphQL, we use DDP from Meteor and words for front solutions to connect with .NET, with Java, but in PHP, no. So we have to jump.  Yeah, and then that's what we find out about GraphQL. So we were like, how we expose an endpoint from this MongoDB and meet your application. You know, guess what? You cannot create an endpoint. And then why don't we use, I mean, and arrest endpoints. We find out about GraphQL. We start playing with it and we love it. So we start using it as well. How the application looks like, it's kind of like this. You have a directory structure, SRC, where all your code is located. The most important files here is the index.js file, which is the main entry point of your application is like your phone controller. Like your index.php file. And we also have, we also use to a constant.js file. This is where we replace RedHot for Webpack in order to be able to define these variables to be used by the client application. Yeah, because we have configurations on the application to behave on different on development and production on our stages. So we use, do a heavy usage of, I mean, EMV variables. Well, we also have the index.js file, which contains your application definition. We create any object here, like app equals to DB object. You can pass, I mean, initialize your state values here. And then we register the global models. In this case, we have out, which is the model who takes care of the authentication, login and refreshing token. The local model, which is basically any data list that we are showing on the application. That is not controlled by the user, if not provided by the application itself. Let's say there's a list of something, which is default by the application we provide. We use a local storage mechanism for doing that, for avoiding too many fetches to the endpoints. And we... Maybe you could think this is a structure. So obviously this is pretty, is far away from a simple JavaScript file to load your application. So remember, when you create Node.js application, it's more than a single jQuery file. So you are creating a pretty complex solution for the client. When I saw bigger projects, it looked like a very professional, like a symphony of big application. Because from the client side, you have to resolve many complex things that in our side, in symphony and PHP, it's easy to solve. Another important file is the router file. So the way we manage, we create objects for routes, and we register those routes dynamically. We separate the object, the login object, and in the next slide I'll show you why. So we have a login object and then the route object. And as we can see, this array takes care of... It's for dynamically loading the different application components. Let's say this is the component for the entity. So we dynamically load it here. And then we have this iteration where we are using, you know, routes map function for iterating the values and then rendering my component for the routes. As you can see here, we separate those because we have the login route outside of this out route. So this is an custom component that we wrote. I'll show you how it looks like. This component, it uses or extend the route, the default route component. It also allows you to asynchronously call a promise function, which is basically the one who takes care of review. Is your token valid? Then the route gets loaded. And if it's not, as you can see here, I mean redirect you back to the login. So this is only calling a promise, a unit's promise, this, then something, right? So if this is true, then let you go. If it's not, then let you drag it to the login. Well, we have the component looks like this. This is how we interact with the state. We have a function. We define the namespace for the entity we want to interact with. In this case, pose. We define the default initial state here. And then we have the reducers section here. By using Redux and Saga, this is how you interact with your state. We have this class with the reducers function here. And this is how we interact with the state. And make sure when you are interacting with the state and react, you don't change the state itself. You create a new state every single time. It allows you to move back in time and see how your whole application is behaving and changing while using it. And then this is a section on your class definition. It's called effects. So this is the place that you will be, or the function that you will be calling in your system. So your system will be calling something like pose.fetch function. And this is the place where you have the proper code to calling your endpoint. As you can see here, we have a GraphQL query. So we're calling pose. We're telling GraphQL to return me back the first 10 values. And I want to see those ID, ID, title and body and the type. Remember the GraphQL query we showed you before? So it's the same thing here. And finally, once you return this data, you create this object list for returning the value. What? Yep. You end up using the put function to update your state or to create a new state in your application. So we basically go here. Pose equals to calling the fetch function. Right? Remember the fetch function that we created before? And you call it here. I mean, you return this and return this as a list. So we create this map functionality to extract some data and manipulate some data from the GraphQL endpoint to create a plane array for us and then store it on the state. And then your components will be looked something like this. You will have different directories within the components directory. Different directories for a specific group of components. And for one entity, we tend to use something like project base, which contains all the logic that could be functional. You have that controller base in Drupal. And then edit list in new. I think we can show some example. The idea is we are going to show you an internal application we are working on. So this is... This is how the GraphQL work looks like. The idea is you could use the download, the documentation explorer in order to inspect what items you have available to search. You could use the search area in order to try to build the query. So this is connected with the specification. If you are trying to write something that is invalid, immediately you will get the error.  So actually this is the idea of how they call Graph, right? For me at the beginning it was a little complete weird. This is GraphQL. Why GraphQL? And it is because it is everything GraphQL. So this is a symphony application using all the techniques we mentioned. This is how looks and design out of the box. Let's see if the internet allows to login. Because internet... Yeah, it is login. This is going to create... This is a system who is connected with Bitbucket, the Jalosha, and others. So we are enabled the integration with this website with GitHub. Maybe you explain that. Yeah, it is a system that allows you to deploy your application. So basically the recipe we talk about is the one we use for building this tool. Internet is so slow. So it allows you to connect your project with GitHub, Bitbucket, or GitLab of your own. And then from there you can start... Once you connect with GitHub in this case, it automatically... I mean, add a web hook, mean URL, and it also add the... So what happens now is we are trying to get the handshake with GitHub to try to enable the web hoops. It is taking too long. But yeah, automatically add this SSH key for you so you can start using the project for deploying your site. So basically it allows you to create temporary stages of your project I mean dynamically create servers for you and all that. Dynamically you don't have to worry about it. It is like a CI MQA tool. And also allows you to build your artifact and deploy to your production server. In this case it could be Accha, Pantheon, or your own servers if you want to. Well, Internet is terrible. Let's wait one more second or two. We have five minutes. So the idea is obviously after we do the connection we use socket.io to try to improve the user interface try to do the interaction, enable the user to request some tasks do everything in background, continue doing something else and when the process was finished then you get a notification using the UI. And we use GraphQL and notification and socket to try to create a smooth application. Nah, never finished. Well yeah, this is the components that we mentioned on the site so it provides you with this sidebar, the layout component it allows you to form, let's say I can start just typing things here and making things and all these forms and fields and anything here is based on those components. What we tend to use is create our own components in top of those components to interact with them and as you can see here the value was created the form was rendered again and this is how it looks like I mean let's say we can probably go back to activity and this is how a table looks like once it's filled with data you can see here but I mean you don't have to do nothing other than take advantage of those same as Drupal, you know like Drupal form then they have forms, I mean there's lighters, they have like tabs. So the idea is to try to use the tool to invest your development time in the important things. Notifications here? It's logic. You see the notification there? That means the application get the connection with the GitHub and then we create a SSH that will be allowed into GitHub to allow to create the integration with the code itself. Yeah basically what happens, yeah do something you know call the GraphQL endpoint, the endpoint do something call the server, everything here is a synchronous, nothing happens I mean we have like message brokers so the message brokers go to the back do what it has to do and then put the message on the Redis emitter and as you can see we use the WebSocket to refresh the interface and send those messages here as you can see the notification was also pushed via WebSocket. So again this is the recipe we use for this. It also notifies you on a Slack, I mean whatever you want to. That's it. Yeah and that is for all so if you have any questions before to go launch go ahead, this is the mic. Could you go to here? Because we wanted to, okay the question is why don't we use, why we don't use Drupal? I mean we love Drupal, we use Drupal whenever it's a right solution. The thing here, this is not a content centric, there's no like no revision. We don't really need bootstrap Drupal for this. We can, this is light, I mean symphony API platform is lighter for bootstrap. The addition you mean the... Oh well yeah I mean but in the end it's like this is not a content centric, it's more like putting data and fetching data. So we don't really need the full Drupal. We don't need like build content types there, we don't need widgets, we don't need formatters. So it's like for this case we didn't know Drupal. So whenever we are building an application and there is not content centric we check the solution instead. Instead of going Drupal and then turn on JSON API and GraphQL and build something in top. Because I mean in the end you can use the same front end solution or recipe and use anything you want to like Drupal or Django REST or Go or build your own in JavaScript if you want to. Any other question? I can probably, I mean I can add, I mean it feels like with the code, I mean that won't be a problem. I can add this, I mean on the slide and when I upload it it will be updated. You can do that by using the group roles and then you use the, so whenever you're logging with JWT you have access to the user on the PHP side of things. So based on the role that user belongs to you can define, you can change doctrine queries on the fly and select what you want to see or want not to see. And creating those groups is how you define. Yeah, you declare some reason and annotation on the entity. Any other question? Thank you so much. In fact, in the example of when I changed the JWT, we added the organization ID or the role ID. We added the role ID in the login. The dates and you have it with the JWT code. Sorry. When you use JWT code you can, I mean because the JWT token from there you can access the role in this side. But I mean really with that on the client it's a little dangerous. I mean I really like to pre-fetch the data. That's what I want. But I want you to see the value itself. But you can, I mean definitely you can do that. Some people say the storing data on the client is dangerous as well. So this is, then just figure it out. Yeah, but remember whenever you call the API from the back end and you can, there is a lock train. You can use the lock train to change the code. You have access to the user that's locked. Because you pass it on to the back end, you pass it on to the token. You know which user is in with the user. You know the roles and all that. So you can solve that on the back end if you want. I find a lot of these things. They tend to use tools, same-round, role-building, other sort of role-building. These companies put out these amazing solutions. To me, I understand that we're going to hurry. For example, this one actually. Yeah, that's awesome. Every website in one single user. Yeah, I mean you know, that's for central. Central, that's for central. That's for the website, right? That's all that I was exposing the user. We put in the data and it's closing in. Then we have some very large applications. Different, meaningful endpoints. Then you can create this graph. Yeah, like million. So I was just like, I wasn't through this training. Provided by, you know... We don't need to record it. Have revisions for me. In this list of minutes, I mean, in green, it's actually how you do it. It's like... You know...


Two papers. We start with the paper analyzing block-wise lattice algorithms using dynamical systems by Guillaume Arne, Zaviel Puyol, Damion Stella. The speaker is Zaviel. Thank you. So I will present the paper, analyzing block-wise lattice algorithms using dynamical system. As you say, it's joint work with Guillaume Arne and Damien Stella, through the context. Lattice's mathematical objects that provide art problems that can be used to build various cryptographic primitives, such as encryption, hash functions, and so on. And the best known attacks against lattice-based cryptosystem rely on what is called block-wise lattice reduction algorithms. That's why we want here to study these algorithms to assess the security of lattice-based cryptosystems. The most widely used reduction algorithm among the lattice-reduction algorithms is called BKZ. And that's the one we will study in this talk. It's the widely used because in practice it's the most efficient. And despite the fact that it's not well understood in theory, that is, no reasonable time bound is known on the running time of BKZ. Our contribution is to give a first worst case analysis of the BKZ algorithm. And to do that, we use a new technique. We introduce a model of the algorithm, which in itself can be interesting to understand other things on this algorithm and other lattice-reduction algorithms. So the talk is in two parts. I will first give a few reminders on lattice-lattice reduction and give the main result. And then I will explain the main ideas behind the result and the model that we used to obtain it. A lattice is a grid of points. It's a set of all integral linear combination of a fixed number of linearly independent vectors of n linearly independent vectors. So here we have two vectors that generate the lattice represented by the black dots. The two vectors are called a basis of the lattice. And as long as the dimensions, the number of vectors is at least two, all lattices have infinitely many bases. The problem of lattice reduction consists since finding a basis of the lattice made of rather short and rather orthogonal vectors. For instance, more reduced basis of this lattice would be these spaces. So when the dimension is two, it's easy. When the dimension grows, that it becomes harder. So finding reduced lattice is hard when the dimension grows. Now all bases of the same lattice have the same determinant. It's an invariant of a lattice. And the ratio between the determinant, no, between the first vector of a basis and the determinant, gives a measure of how well a base is reduced. So this ratio will be called the Hermit factor. To make things simple, our goal is to find bases of lattices with small Hermit factors. It is known that the Hermit factor can always be made as small as the square root of a sequence that grows linearly in n, the lattice dimension. A more precise way to measure the lattice reduction consists in considering the Gram-Schmidt's orthogonalization of the bases. I will keep this the same notation during the wall talk. x i is equal to the log of the norm of the i th Gram-Schmidt vector of a basis. And considering the shape of the x i's shows how well the lattice is reduced. There are various notions of lattice reduction. The strongest reduction is called HKZ reduction. When a basis is HKZ reduced, its Hermit factor is optimal, its square root of gamma n. And the shape of the x i's is very flat, which means this is a strong reduction. On the other hand, it takes exponential time to compute a HKZ reduced basis, so it's impractical. On the opposite, the LLL reduction is a weak reduction. It achieves only an exponential Hermit factor. There is a big gap between the x i's, but it can be computed in polynomial time. What we are studying is a compromise between the two. So it's BKZ. And it's not an algorithm. In fact, it's a hierarchy of algorithms that takes a parameter beta. And when beta is equal to 2, BKZ is equivalent to LLL. When beta is equals to n, it's equivalent to HKZ. Between the two, BKZ achieves an exponential Hermit factor. But the constant of the exponent can be made as small as we want by increasing the parameter beta. BKZ makes use of HKZ in small dimension. If we apply BKZ on a n-dimensional lattice with a parameter beta, it will make use of HKZ in dimension beta. So it takes at least time exponential in beta. To have something continuous between BKZ and LLL, we would like to have something polynomial in n. But as I said, we have no bound on the complexity of BKZ. So we don't know if this question mark can be replaced by poly of n. So a brief history on BKZ and other algorithm of the same family. The definition was given in 1987, and the algorithms a few years later. And an experimental result, in particular, by Gaman and Guyen, shows that it's very unlikely, in fact, that BKZ is polynomial in n. That is, it's unlikely that this question mark can be poly of n. On the other hand, there are block-wise algorithms, still between HKZ and LLL, that do have a complexity polynomial in n. However, in practice, BKZ is the most efficient algorithm and achieves the best compromise. That's why it's really worth trying to optimize the complexity of BKZ even if we know other algorithms. So what does the BKZ algorithm do? BKZ is just a loop, and at each step of the loop, we do a small part of the reduction. During the small part of the reduction, the strong HKZ reduction algorithm is applied at most n times in small dimension, in dimension beta. So this is the main step of the algorithm. One step of BKZ takes time polynomial in n. The problem is how many times is the small reduction step applied? In the standard version of BKZ, it supplies until the whole HKZ reduction do nothing inside the loop. But it doesn't work. So what can we do? Here is a curve that shows the evolution of the quality of the basis during the execution of BKZ. So it's the time, and it's the quality. It's when the limit factor on decrease, the quality improves. So during the first tools, during the 100 first tools, the quality improves quickly. But after that, there are many 1,000 loops in this dimension. And between loops 200 and the end, nearly nothing occurs. That's the basis of our result, which is we didn't prove that BKZ aren't in time polynomial in n, but we have proved something which is nearly as good, which is we can just stop BKZ after our polynomial number of iterations, a polynomial in n. So n power 3 times something which is nearly negligible. And after this polynomial time, the quality of the BKZ output is nearly as good as what we can prove for the standard version of BKZ for which we have no time bound. In red, it's the bound for the standard version of BKZ. And we have just some epsilon and some small constant. That's the only difference. So that's the main idea, just stop BKZ earlier. I will now explain the model that we use to prove this result. For most lattice algorithms, the analysis rely on a potential function that is a numerical function of the input that decreased during the execution of the algorithm. And it cannot go below a certain value, so the algorithm must stop. With BKZ, it doesn't work. We didn't manage to get it to work. So we used a different technique. Instead of having just one number, we have a full vector. This is the vector of the Xi, that is the norms of the Gram-Schmidt vectors. And we are first analyzing a model in which we made only one assumption, which is HKZ reduction always follows a fixed pattern, which corresponds to a sort of worst case HKZ reduced basis. And this implies that knowing only the Xi's, not the complete basis, but only the Xi's, we have all the information to simulate the algorithm. I will show how the model works on this animation. So this is a small basis of dimension 9 that is very, very weakly reduced at the beginning. And I will apply the model of BKZ. It consists in doing HKZ reduction at each position in small dimension. Say the parameter is 4, we'll do HKZ in dimension 4. I start in position 1, and it flattens the first block of Xi's. Same thing in position 2, and so on until the end. So this is one loop of BKZ, and then it starts again. And the main hypothesis in the main assumption of the model is that the shape of the HKZ block at each step is exactly the same. And I have said that it's now a linear algebra problem because the first steps consist in taking the mean of the first four vectors, which is a matrix multiplication, and then adding a fixed shape, which means we add a constant vector. Same thing in position 2, same thing until the end. So a full loop of BKZ, just a combination of matrix multiplication and vector addition, and can be itself expressed as multiplication by one matrix A, the expression which can be computed, and a constant vector gamma. And this is a linear algebra problem, the analysis of which is merely technical. It's in two steps. There's a fixed set point of the system, and it can be shown that this system has a fixed point which is nearly aligned, and the slope of the fixed point is directly related to the Hermit factor. So it corresponds to the Hermit factor that is given in the theorem. And the second step of the study of the model is proving that the model has an eigenvalue smaller than 1 to prove that it converges in polynomial time. So it's not as simple, but it's nearly as if up to small details, the largest eigenvalue is 1 minus something 1 over polynomial of n. And this is enough to prove that the dynamical systems converge to the fixed point in polynomial time. This leads to the claim complexity bound. This was the analysis of the model. So but our result is a result not on the model, but on the real algorithm. So this can not be transposed directly to the real algorithm. We have to do a bit of some transformation and some averaging. But in the end, a rigorous adaptation of what has been done on the model, which was a sort of worst case analysis, can be transposed to the real algorithm. And it's enough to obtain the result on the quality of BKZ output. So in conclusion, we have the first analysis of BKZ. We don't prove that it ends in polynomial time, but the idea is just stop it earlier and it works. The output is a good quality. And for that, we used a new method, which rely on a model, which we all can be used to prove other things on block-wise algorithms. So we hope that it will lead to better strategies to reduce lattices and to improve block-wise lattice algorithms. Another problem is that in practice, this is a worst case algorithm, and the real BKZ algorithms behaves better than what is proved in the worst case. So there is still a gap we would like to explain, and we expect we could improve the model to make it more predictive. Thank you. We have time for a short question. No, this is a worst case analysis for we don't know anything for the standard BKZ. We know things only for the BKZ interrupted. So we have a worst case analysis of that, but we can prove that it's as good as the original. Yes. So there is a small gap, and that's what I was saying here. We would like to improve the model to fill this gap, but yes, there is a small gap. OK, thanks, Dothan again. The second talk is pseudo-random knapsacks and sample complexity of LWE, search-to-decision reductions by Daniel Michensio and Petros Moll. The speaker is Petros. Do you hear me? OK. So my name is Petros Moll, and today I'll be talking about search-to-decision reductions for knapsack families and the LWE problem, and this is joint work with my advisor Daniel Michensio. Is the timing correct? Really? OK. So OK, let me start by recording the LWE problem. So in the LWE problem, we have a secret vector s n dimensional with coefficients from zq, where n and q are public parameters. And in this problem, we are getting m samples, which each sample is a pair. The first component of the pair is a vector from the same dimension as the secret, randomly and uniformly chosen from zq to the n. And each bi is a noise-inner product of each random vector with a secret, where the noise is some small scalar drawn from a publicly known distribution. OK, and the goal is to find this secret s. For the rest of the talk, I'll be using this more succinct representation of LWE. We group all the samples into m by n matrix a with random entries. And b represents compactly all the bi's. OK, so a little bit of background information about LWE. It was introduced initially by Oded Regev in 2005. It is a generalization of the well-known learning parity with noise problems in larger modules. And since it has been introduced, it has been very successful in cryptographic constructions. And as you can see here, especially the last three years, it has served as the underlying hardness assumption for many fancy primitives, especially in public crypto. OK, a little bit more formal look at LWE. The parameters is n, the size of the secret, the number of samples m, q is the modulus, and chi is the error distribution. And again, now, this is exactly the problem I defined in my first slide. Given these m random samples, this m by n random matrix a, and m noisier products with some fix and common secret s, find s, or equivalently find this error vector e. And in the decision version of the problem, we are again given this m by n random matrix a. And our goal is to decide whether the second component of the input, this vector t, corresponds to an LWE instance that is m noisier products with a secret s, or some random vector from z, q to the m, which is completely independent from everything else. OK, so the talk focuses on understanding the hardness of these two problems and how their hardness relates with each other. But before doing that, why do we even care in the first place? OK, in cryptography, we do need decision problems. These are the ones that are appropriate for the crypto constructions. And that's the case for LWE, too. In particular, all known LWE-based constructions rely on the decision version of LWE. And this is mainly due to the fact that most of the security definitions we have in crypto have a very strong indistinguishability flavor. OK, on the other hand, the search problems. From an algorithmic point of view, we do understand their hardness better. So over the time, they have undergone more study by the community. And now, the nice thing about the search to decision reductions is that they somehow bring those two families of problems together. And given search decision reductions, we are able to prove claims such as a primitive pi is secure under some notion of security, just by assuming that the corresponding search problem is hard. OK, our results. We provide a toolset for studying search to decision reductions for LWE, in the special case where the noise is polynomially bounded. And as an added feature of our reductions, these reductions tend not to be sample preserving. I'll come back to that at the end of my talk. And we give similar search to decision results for generalized knapsack functions. And also, in particular, we give some powerful and easy to check criteria in order to prove search to decision equivalence. And I actually saw that the first two bullets are somehow related. And along the way, we use in a new context some techniques from Fourier analysis. And this might be interesting because these ideas might find some applications elsewhere. OK, let me actually start from the second bullet. And I'll come back to LWE towards the end of the talk. OK, so what is a knapsack family? It is parametrized by some integer m and to finally find a billion group g. And we also have this set S of integer multipliers. So S is a subset of integers, where the maximum value, this S, the small s, is polynomially bounded in the parameter m. And now a random knapsack family is a function with domain of the m-dimensional vectors of multipliers and trains this group g. If we want to sample, we just have to sample m independent uniformly random group elements. And then evaluation is simply take each group element g i multiplied by the corresponding multiplier from the vector of multipliers, and then add everything up to form a single group element. And just for ease of notation, I'll be using this dot product notation instead of the right-hand side sum. OK, so many instances in cryptography actually are subcases of this general description I gave above. Maybe the most representative example is this random modular subset sum. This is the specific case where the set of multipliers is just the binary set. Either we get an element or we omit it. And the underlying group is the cyclic group z sub m. All right, so now if we consider a fixed specific distribution on the vector of multipliers, the integer multipliers, then we have the same two problems for the knapsack functions, namely the search problem, given a description of a member of the knapsack family and the image of some input x that follows some pre-specified distribution, find this unknown image x. And the decision problem is very naturally defined as we are given this random member of the knapsack family. And also, we are given either the image of some unknown input x or a completely uniform and independent element u. And our task is to say which is the case. So just for ease of presentation, I'll be using this calligraphy k of g,d to denote the family of knapsack functions that are defined over this group, g, and that have input distribution, this distribution, d. And I'll be borrowing standard terms from cryptography. Whenever the search problem is hard, I'll just say that the corresponding family is one way. And similarly, for the distinguishing problem, if the decision problem is hard, I'll just say that the family is a pseudo random or PRG in short. OK, so what do we know about the search decision connections for knapsack problems? So in Palazzo, now in the paper in 89, they proved that the decision problem is as hard as the search problem. For the specific case, where the multipliers are binary, so this is the subset sum problem. And g is the cyclic group z sub m. And Fischer and Stern extended the result for the vector group g, z2 to the k. And for input distribution, the uniform distribution over all n-bit vectors with a pre-specified humming weight. All right, so we'd like to take a step further and ask ourselves, OK, is this true for other families, for other groups too, or for other input distributions? Ideally, we would like a cleanser to decision equivalence for ideally every group g, finite group g, and every distribution. Unfortunately, that's not the case. However, it turns out that if we add this additional condition in the red frame, the implication becomes true. So and this is, in fact, the main theorem of technical theorem of our paper. And it basically says that the decision problem is hard, assuming the search problem is hard, and also some other related decision problems are hard. And by related, I mean problems defined for NAVSAC families that have range of related groups. So this quotient subgroup of the initial group g. And I don't want to spend too much time on this condition, but it might seem, at first sight, that this is a very artificial condition just to make the proof work. The only thing that I will say is that, in reality, this condition is not restrictive at all. It's much less restrictive than it seems. In particular, in many interesting cases, this restriction holds in a very strong information theoretic sense. So in reality, we really don't have to check anything else for many interesting groups. And we get a clean search decision equivalence. So for example, this is the case for any group and any input distribution, as long as the multipliers are binary. So if we are working on any finite abelian group g, and our distribution is only defined over the n-bit strings, then we get search decision equivalence unconditionally. And just note here that this implication alone generalizes the result by impagiatso now and fissure instead. Same thing for groups with prime exponent and any distribution. And also another nice thing is that we can use all these nice tricks from information theory, leftover has lemma, bounce on the entropy of distribution, et cetera, et cetera, and get similar results for other cases of groups. OK, so just one quick slide about the proof. We want to show how to solve the search problem by having a distinguisher for the decision problem. We do the trick used by impagiatso now. So we break down the proof into two parts by introducing this intermediate notion of a predictor. So this is, again, the outline by impagiatso now. However, due to the generality of our result, the details are fairly, fairly different. In particular, in this step one, impagiatso now already used the Goldreich-Levin hardcore predicate. In our case, we have to derive general conditions that allows to invert such a function, such a knapsack function, just by given noisy predictions for x dot r, for random vectors r, modulo sum number that might not be necessarily prime. So neither Goldreich-Levin or the Goldreich-Rubenfeld-Sudan results are enough in this setting. OK, and so for this step, we use as a tool a nice algorithm developed by Acavia, Goldwasser, and Safra for learning heavy Fourier coefficients of general functions. Step two, again, we managed to show that there is a way to use the distinguisher to get a predictor that satisfies exactly the general condition of step one. Won't get into the details. This is actually the most technical part of the proof. You can see, you can take a look at the paper if you are interested. OK, let me just now come back to the LWE as promised in the beginning of my talk. For that part, we use some unknown duality between LWE and knapsack problems. So if you flip an LWE instance, so if you see it from a different point of view, it turns out that these LWE instance can be transformed to this knapsack instance, where this matrix G, I have grouped all m elements from the group into this big matrix G. In the error-correcting codes language, this is exactly the parity check matrix for the query code generated by matrix A. And the important thing to notice here is that the only component, the only quantity that unifies these two problems is this vector E, the error vector, and that is the error vector of LWE becomes the unknown input in the knapsack instance. And also, it turns out that all the distribution work out nicely. If you start from a random matrix A, you get a random matrix G. All right, so a similar transformation works also the other way around, which is very convenient. And if you put all the pieces together, you can go all the way from the search LWE to the decision LWE through the corresponding knapsack problems and use all the machinery and the strong theorem we have for knapsacks for search decision. OK, so what does this mean in particular for LWE? Using these connections, we are able to re-prove all previously known such reductions with bounded error for learning with errors and for LPN. And also, we're able to get some search decision reductions for instances of LWE not considered before. And as an additive benefit, we get that our reductions are sample preserving, meaning that all the previous reductions prove that M samples from the LWE distributions are indistinguishable. But they have to assume that the corresponding search problem is hard given a higher number of samples, still polynomially related to M, but a higher number of samples. In contrast, our reductions are sample preserving. So if one can solve the decision problem given M samples, then he can also solve the search version given the same number of M problems. Of course, the caveat here is that there is a degradation in the success probability. So if you start with some probability distinguishing at Vanda's epsilon, this will go down the inverting probability. But this seems to be unavoidable. All right, so why should we care about the number of samples? The reason is that in natural instantiation of schemes, there is a certain number of LWE samples exposed. And now the nice thing about the sample preserving reductions is that we can base the security of these schemes on the hardest of the search problem when given exactly M samples. And from a concrete algorithmic point of view, that's interesting because some known attacks against LWE, one wayness of LWE such as some lattice attacks and some recent algebraic attacks seems to be sensitive in the number of samples exposed. And in its extreme manifestation, this phenomenon, there are cases of parameters of LWE where if given enough number of samples, we can completely break LWE. Whereas with fewer samples, the attack doesn't seem to be working. OK, so let me conclude with some open problems. All the sample preserving reductions that I mentioned before work whenever the noise is bounded. It would be nice to extend this to the unbounded noise case. And especially lately, the LWE with super polynomial noise has been used in several applications. So this problem is well-motivated. Just let me mention here that we do know how to get search decision reduction for LWE for some parameters and super polynomial noise by the work of Piker. But these reductions are not sample preserving. And the similar landscape for the algebraic variant of LWE, the ring LWE, we do know sample preserving reductions, but unfortunately, no sample preserving ones are known. Thank you. Very short question, if any. OK, then let's thank the speaker again.


The fraction of Absorbed Photosynthetically Active Radiation, FAPAR, is an important plant physiological index used for assessing vegetation's ability to absorb PAR, sequester carbon in the atmosphere, monitor plant health and productivity, and food security assessment. Multispectral and Hyperspectral Unmanned Aerial Vehicle, UAV, imaging systems can provide precise estimation of FAPAR using chemometrics, but data pre-processing procedures are cumbersome, making large-scale mapping challenging. This study applied image-processing protocols and a chemometric model to a lightweight, frame-based, and narrow-band, 10 nanometers, UAV imaging system to estimate FAPAR over a relatively large cultivated land area with various low-stature vegetation of tropical crops along with native and non-native grasses. The results indicate that 77% of the FAPAR variation was explained by the model, an all-band sensitive to foliar pigment concentrations, canopy structure, and all leaf water content may contribute to the estimation, especially those located close to or within the near-infrared spectral region. This study demonstrates that this narrow-band frame-based UAV system would be useful for vegetation monitoring, and with proper pre-flight planning and hard-way improvement, the mapping of a narrow-band multispectral UAV system could be comparable to that of a manned aircraft system. This article was authored by Choe Ying Huang, Hinlin Wei, Zhengyou Rau, and others.