OLIVIER COLSON: 0:00

How do you scale when the database becomes really

DAMIEN BOUVY: 0:04

You can easily split like front end servers. So Python servers, you can split them on multiple machines. That's what we do on Odoo. Com actually we have I think now five six machines that are really beefed up serving the website and the back end. You can scale quite a lot. We have already a lot of instances with thousands of back-end users. I mean, if you take a do.com alone, we are now what, 3000 employees?

OLIVIER COLSON: 0:28

I think that among the trends and things that are

MEHDI RACHICO: 0:35

So rest is just a communication protocol between Odoo is exposed with another communication protocol called Xml-rpc. A lot of customers ask like, okay, I usually work with a Rest API, so why don't you expose Odoo as a Rest API? People just use Rest without thinking about it. They're not even aware that there are other communication protocols, maybe ten other communication protocols that can be used and can do the job. Sometimes better, easier if you just learn it.

OLIVIER COLSON: 1:00

Hi, everyone, and welcome to this new episode of Today we share with you the second part of the discussion we had on Twitch. If you didn't listen to last week's episode, I highly recommend you do it first. And if you already did, stay with us because we'll jump into the conversation right now. Ready? Let's go. And we are back. So, let's start with a last question about AI from the chat, actually. And then we will move on to other subjects because actually we do have other subjects. But I uh, proves to be a long one. Come on. It's a it's a nice one. So it's okay to take the time. Uh, so let's put this one. So AI to GPT seems to be a lot more than a trend. Do you regret not implementing it earlier?

DAMIEN BOUVY: 1:45

Not really, because I. I don't think we could have done it much earlier than what we did. Basically, I think we did it in version before version 17 a little bit, or maybe just landed in 17 publicly, which was six months ago. So as I said, what, one year after ChatGPT got really, really exploded?

OLIVIER COLSON: 2:06

Yeah, that was really the time where everybody So it it has existed. This kind of AI has existed for a long time. But, uh, the moment when we really started to hear about it everywhere was really last year. Yeah.

DAMIEN BOUVY: 2:18

So I don't think we're really late on that, to be Uh, and I don't think, I don't think it will be a huge driver of sales anyway. I mean, it's a nice feature to have. Uh, sure. It will help you in your day to day if you want to, to write, uh, help, uh, if you want it to help you write emails to your customers, for example, it can help to reply customer tickets, stuff like that. But it's not a killer feature like it could be in, for example, if you take, uh, I don't know, Zendesk or uh, I don't remember the name of the company, but something like that includes, uh, chatbots, uh, where it's really their core business, then. Yes. Maybe for them it was important to have it super early. In our case, we do have a live chat and chatbots, but I don't think it's such a huge problem not to have done it that early. We have also to keep in mind that the fact, the fact that ChatGPT is really has really exploded in the tech world, it's being spoken of in other sectors. But if you're not a tech aficionado, you know about it. You probably never used it. I mean, most of the people.

OLIVIER COLSON: 3:28

I met with it. Yeah, exactly. You tried it. I, I know someone, uh, he he he asked GPT to to write a poem about, uh, uh, Pythagoras theorem, uh, things like that. So everybody can try that. It works really well. Uh, but, but the the actual use is arguable for these kinds of things.

DAMIEN BOUVY: 3:48

It's not a killer feature. You don't need it to So no, I don't I we don't have any regret I think.

OLIVIER COLSON: 3:54

Yeah I agree. Plus it would mean if we regretted would have wished to replace something we made earlier by this. And so the question would be what? What do we sacrifice exactly? So no, I think the timing is, is, is okay. Uh, and it adds to the wow effect. It was nice that the keynote experience, uh, mission complete. Um, so, uh, let's maybe move on to the next, uh, topic. So I know you have a lot of things to say about this one. Uh, why not using microservices? You know.

DAMIEN BOUVY: 4:27

As I said.

OLIVIER COLSON: 4:28

The floor is yours. I mean, I said.

DAMIEN BOUVY: 4:30

When we prepared the the episode a little bit, Like, that's a.

OLIVIER COLSON: 4:38

Therapy moment. Exactly.

DAMIEN BOUVY: 4:40

Uh, I used to work in a company where we use absolutely no good reason. And it was really a nightmare to maintain.

OLIVIER COLSON: 4:51

Again, I think everybody has a vague idea of what microservice is anyway?

DAMIEN BOUVY: 4:57

So a microservice is, uh. I'm not an expert on the matter, but my take on it is that you split your platform. It's usually for bigger platforms that you do that, so you split your platforms into services that are quite small. So for example, you will have one service whose scope is to authenticate users. You will have one service which is usually one endpoint in your API to fetch some kind of data. For example, if you were working in Odoo, you would have one endpoint for the CRM stuff, one endpoint for the sales stuff, one service for the, uh, helpdesk or accounting. Exactly. You could even split it further to have a service that is in charge of tax computations. Only if you want to really go mad. Um, and so the the reason this exists, I think, as a, as a technology, is to make it easy to scale stuff that needs to be scaled. And I think that's the part that a lot of people forgot about is that if you don't need to scale, don't do that. It's going to be a nightmare. Because the problem when you start working with microservices is that you have to have clear boundaries between services, which is not as easy as it may sound.

OLIVIER COLSON: 6:09

At the end of the day, it's just, uh, any as any So you decide that there will be a service for this, for this, for this, and then maybe six months after deploying the thing, you realize that, okay. But actually, it cannot work like that because this one is to communicate with this one and then you start. That's usually what.

DAMIEN BOUVY: 6:24

You end up with is that all your services will be So it's super cool because you have all small services with clear APIs. But as soon as you want to change one API in one service, you have to create other endpoints in the other services. And so your small feature that is basically one endpoint because becomes a huge change set that is introducing like five new endpoints in other services that that the one you are working on. And if you have split your services into teams, it means that you have to coordinate this effort between teams so that, like all the services, are ready to be deployed at the same time, of course, because everything needs to be interoperable. Um, or if you manage to make it like, uh, asynchronously, it means that you're really good and that you probably should be using microservices. Uh, but it complicates stuff so much. It's amazing.

OLIVIER COLSON: 7:17

But at the end of the day, you know, it's well, start having services depending on each other like that, it doesn't scale that well anymore because it means that if you want to really add a lot of workers for one service since it depends on another one, you might load that service as well.

DAMIEN BOUVY: 7:34

I guess you have a lot of dependency. Yeah, it means, but the fact is that usually, you will deploy microservices using some kind of containerization and automatic scaling. If you set up your, uh, now it would be a Kubernetes, uh, setup. Probably if you set it up correctly, you can immediately tell the system, if you see this kind of load on the system, spawn another worker, another Docker image, uh, whatever. So the scaling kind of goes automatically, uh, if you, if you move in that direction. But uh, it's another layer of complexity to add, by the way, because you need to know decide, okay, when do I scale? It also means that you kind of lose control of your platform. Yeah. If you have someone dosing you, all of a sudden the platform will scale and then you've multiplied your Amazon invoice by ten and you didn't do anything like it's not. You cannot control that. You can put limits I think in Amazon and Google, um, and the Google platforms, but still you kind of hope for the best. Yeah.

OLIVIER COLSON: 8:34

At least you need to be careful on the way the don't want it to scale forever.

DAMIEN BOUVY: 8:42

You always put limits anyway. But I mean, it's it's. Uh, it makes sense if you're Netflix or if you're Amazon or if you're a huge company that needs to reach millions of people across continents; it clearly makes sense at the same time, at the same time, and with low latency.

MEHDI RACHICO: 9:00

Yeah, exactly.

DAMIEN BOUVY: 9:01

So that's, uh, like a huge problem here in Odoo, It doesn't really make any sense. Most Odoo instances have, what, 20 users and a website, maybe with a few thousand visitors. That's I think I've just described something like 95% of Odoo instances. And obviously such a complex setup doesn't make any sense. You've just put so many brakes on your development velocity that you. I'm not going to say you drop to zero. That's not true. But you you divide at least by two. Uh, and probably I think from my experience, a lot more.

OLIVIER COLSON: 9:36

Yeah. That, probably would mean for, for Odoo require a huge number of changes, of course. But, uh, I think indeed the, the well, the thing is, Odoo does a bit everything as it is now and everything is complicated. Everything is a lot of things. And so, uh, even with well, even if you, if you manage to dispatch that into microservices, I think it will soon become very, very complex because you have a lot of features that need to interact with each other to override part of the code, this and there. And so you need to exactly. It all depends on what is installed on the database of the customer. So it's one more layer of complexity.

DAMIEN BOUVY: 10:14

And as a developer I think that's really a interconnected. It means that there is some ramp-up in your onboarding as a developer for Odoo to know, okay, I need to override this method on this model. And like you kind of get to know, okay, the few key methods and a lot of models. For example, action confirms on sales order action post on account moves stuff like this. But once you get that, you can basically plug it into any workflow and do whatever you want. That means that if you set a lead to confirmed, it will create a sales order that will get auto-validated and then create an accounting, um, invoice. And if you start doing it with microservices, I, I'm not even sure we could have this kind of modularity because it means that instead of having one module that depends on sale accounting and CRM to like do some stuff with all that data, you would need to patch three different services, then probably have one other service that kind of serves as a like receptacle for all this data sharing and data management. So it would be a nightmare as a developer I think then.

OLIVIER COLSON: 11:28

My take is sacrificing our design. And I think it would be a pity because one of the, one of the things that really I think the first thing that really impressed me when I got into Odoo, uh, was really when I saw I read the tutorial, I was learning how to program in Odoo and, uh, and, and just the explanation of how the models work, the inheritance, these kind of things, because you read it and you're like, okay, actually, it's simple to understand, but when you look it into action, you realize that there are so many things that are possible because of that. Uh, that to me, the design, uh, the whole modeling of Odoo. So all those things are what makes the worth the worth of the product. Yeah. Uh, and changing that for something else might be very, very bad.

DAMIEN BOUVY: 12:17

I don't think it would be called Odoo anymore. It would be so different. Like the approach that's really not in our DNA. So I mean, the chance of that happening is basically zero. Uh, thank God. Yeah. But, uh, yeah, it's, uh, I remember that we had some feedback in the past like, hey, should we, you know, make silos out of our application so that if you have a lot of, uh, invoicing data that works on, you can split the database and have it live on other machines so that it's more powerful for that. But then the rest is not impacted by the fact that you use a lot of invoices. And no, we said no. We will keep saying no because it would be really complicated.

OLIVIER COLSON: 13:00

But then the question becomes, uh, how do you huge, uh, in Odoo, uh, because there are big projects, you know, there is Odoo of first.

DAMIEN BOUVY: 13:10

Uh, yeah, we are I think our database is probably Um. We scale. At the moment it's only possible to scale, um, the processing on Python. So that means that you can only have one database. That's the at the moment the, the last um, pressure no pressure point but access point that is not really scalable. At some point, you run out of RAM to throw at thethe database, but you can easily split like front end server, um servers. So Python servers, you can split them on multiple machines. That's what we do on Odoo. Com actually we have I think now five six machines that are really beefed up serving the website and the back end. But we have only one database server. What we are doing with Odoo 18. Uh, and actually I think it's already merging in, in the master branch is that we allow to replicate the database and to split requests for read only access and write access, because basically, when you navigate within the Odoo backend, we estimate that 90% of what you do is reading. You go on a, on a lead, basically, you start by reading and then maybe you pass the message, maybe you modify a field, but most of the time you will do reading stuff. That means that we can replicate the databases on multiple servers. These replicates are read only. So if we tell the system, okay, if the request incoming is read only, you can actually read on any of these databases in the database pool. So you can have like ten hundred. So basically, there is no actual limit. But of course uh, these replicates are need to be synchronized in real time because it's management software. So the data needs to be consistent all the time. We're not Facebook. We don't want to be ultimately consistent. We want to be always consistent. Consistent better.

OLIVIER COLSON: 15:05

For accounting. Yeah. Please. Um.

DAMIEN BOUVY: 15:08

And so we have of course new limits. We are going to use this on the dotcom soon, uh, and see how it goes. And if we tweak the system a little bit, uh, but you can scale quite a lot. We have already a lot of instances with thousands of back-end users. I mean, if you take Odoo.com Alone, we are now, what, 3000 employees, I think.

OLIVIER COLSON: 15:31

Yeah.

DAMIEN BOUVY: 15:32

Something like that. Uh, and, okay, we don't work all at the same time because we've split across time zones, but it's a good bet that 1000 or 1500 people connected and using the system actively at the same time is really not unrealistic. And it works. I mean, sometimes it's a bit slow. It happens. Uh, sometimes it's also the connection at the farm that that's actually slow. It's not always the Odoo server. Uh, and we always try to improve it. And frankly, it's, it's, I think it's faster now than when I arrived and it was Odoo 8 a few years back. So. Yeah, it's quite, uh, it is possible to scale. It's a little bit more complicated because you don't get the auto-scaling. You could have some auto-scaling, but you don't get as much auto-scaling as you would get, uh, on, on microservices. But honestly, it's worth the trade that's for sure.

OLIVIER COLSON: 16:20

Mhm. Mhm. Mhm. Okay. Uh I suggest we move on to another subject. Uh, among the trends and things that are often asked by people, uh rest or not rest, uh, because uh, you have a bunch of stories with that. Right. Uh, so people asked for it, but we, we don't have it like, uh, perhaps we.

DAMIEN BOUVY: 16:42

Can do as we did in like, a quick reminder of

MEHDI RACHICO: 16:47

Yeah. So, uh, so rest is, is just a communication So you have like something to follow upon when you, when you do like the requests. Uh, and like rest is a protocol, uh, similar to many other protocols that are used in communication and communication between software and, uh, yeah, it's just like you have like for each resource, you have an endpoint and you can like have uh, mainly for, uh, for, um, let's say methods we have get to get the, the, get the resource, uh, post to create a new resource put or patch to edit the resource and delete to delete the resource. And this uh, gives you the ability to, let's say to have like an interface, like, like an API, like we call like a Rest API means we have an interface which you call and you don't know what's happening behind the scenes, but you just get the response from the back end. And as I said, so in Odoo, we usually like Odoo is exposed to another protocol, another communication protocol called Xml-rpc. And it's just another way of communicating.

OLIVIER COLSON: 17:48

What is that. Yeah.

MEHDI RACHICO: 17:50

So yeah. Yeah. Xml-rpc is just a uh, like RPC stands for Remote Procedure Call. And it's just like calling your Python functions from your Python code from a remote location. Let's say basically that's that basically.

OLIVIER COLSON: 18:05

You call public functions exactly like that.

MEHDI RACHICO: 18:07

And in Odoo like we have like so like the xml-rpc Uh, and, and um, you just have to expose functions like expose meaning that just, you like, make them public and public. Function. This function doesn't start with an underscore. So if you decide okay I want to expose this workflow I will just create a function. And this function will be used when someone calls my, uh, my uh, server with an XML RPC and it is as simple as that. So we have like this request for many customers and stack like not many customers but a lot of customers uh, asks like, okay, uh, I usually work with, with, uh, rest API, so why don't you expose Odoo as a Rest API? Okay. So we try first to convince them. Okay. So it's basically just another communication protocol just so you can learn in one hour. Okay. If you are like a developer.

OLIVIER COLSON: 18:57

It's just a function to call. It should be

MEHDI RACHICO: 19:00

Just some set up. You create your, uh, like your exactly as you do with the code if you're writing Python code and, um, yeah, I mean, because and I think that now that the trend is becoming more and more, uh, like, um, uh, let's say present, like all people, like when they get started, they usually use rest and that's it. They don't like first, let's say compare between, okay, what should I use in this case? What should I use in this case? Is my application ready for like do you like, uh, is my use case built for rest or not? But people just use rest without thinking about it. So that's why people usually like, especially like, um, uh, like recent developers, they come. Okay, I want to expose Odoo. Please expose Odoo for me as rest so I can know what I'm dealing with.

OLIVIER COLSON: 19:44

Yeah, because because they're used to that and not even aware that this is exactly, exactly.

MEHDI RACHICO: 19:49

They're not even aware that there are other maybe ten other, uh, used communication protocols that can be used and can be, can do this job sometimes better, easier if you just learn it.

DAMIEN BOUVY: 20:02

And it's, uh, like I do a bit of development in And if you look at any and I really do mean any tutorial right now to build a react app to build something with View.js, it's always rest. And it's funny because as you said, they don't even say like rest is one possibility among others. But it's the simplest for this demo. So let's go with that. Let's just say we're going to create RESTful endpoints for API. There is no other way to think than that.

OLIVIER COLSON: 20:30

But that's often the problem with tutorials You have someone explaining a very, very, very simple use case, uh, to simple uh, with very, very simple tools and the things that he's the most comfortable with. And often it doesn't even tell you that there are other ways of doing that.

DAMIEN BOUVY: 20:44

Knowing I think what's interesting for RESTful, about the data that you're storing and what you plan to do with it. I think RESTful makes a lot of sense. If you have something that basically just stores data, like if you have, uh, like the classic tutorials for a to-do app or whatever, of course, you will only just do, uh, create some stuff, edit a little bit and then delete it when you don't need it anymore. But that's not what we really do in Odoo in Odoo the point of view and the usefulness of Odoo is that you have basically workflows. You click on a button, something happens, it triggers something else elsewhere, and it creates stuff and reminders and it sends emails. And so if you want to plug that into a RESTful use case or RESTful API, you need to think in a really weird way. Like, okay, if I want to confirm my invoice, I need to update the state of the invoice. Like I need to do a put call with like a payload where I change that value. But then it seems like it's a simple change, while in fact you're triggering the amount of data that is going to change with this simple change is enormous. And I think it just doesn't fit. If you look at, uh, what I've seen, someone sometimes in the world is like a RESTful API. I think it was stripe, uh, where you so you have a payment intent? I think they call it. And then you have to create like a payment intent validation object that you need to post. Then you need to update that object to say that it's done. It will trigger a change. And it's really like you can see that they have a workflow and they try to make it fit into objects that they split artificially. And it's really weird. Yeah.

MEHDI RACHICO: 22:27

Exactly. Yeah.

OLIVIER COLSON: 22:28

Yeah.

MEHDI RACHICO: 22:29

It's like for example like you're going from like A, B, C and then d like this.

DAMIEN BOUVY: 22:34

Exactly. And at the end you have like five stuff one time. Yeah.

MEHDI RACHICO: 22:40

Exactly.

DAMIEN BOUVY: 22:41

So yeah, we have I think we are more dedicated you've done it, uh, I guess doing uh, RESTful endpoints for customers.

MEHDI RACHICO: 22:51

Yeah, yeah. I mean, you just you just like, uh, Let's say they want, like, for example, something to confirm and do something else. Okay, you say slash, confirm, slash the ID of the invoice, for example, and you just do the logic there, and then you expose the endpoint as an HTTP endpoint and that's it. And it's as simple as that.

DAMIEN BOUVY: 23:11

So you basically transform the transform the But that's it. Exactly.

MEHDI RACHICO: 23:17

With an endpoint. Yeah. Exactly. Yeah. That's also something else to add on top of this. Like Odoo didn't start as an API server. Actually, it didn't start as an API server. You could call with an endpoint. It started as a whole, as an application, as a whole, as you said, with workflows. So like the front end is strongly connected, connected to the back end. So we can't now like ask the question why didn't Odoo doesn't. Why does Odoo not lose the rest? Does it make sense to ask this question in my opinion? Yeah.

DAMIEN BOUVY: 23:42

And yeah, we don't need it. Yeah. We don't for the application itself. And if you really want to have RESTful APIs like that, you can control with a lot of granularity. I know that the Odoo Community Association maintains a Rest framework for Odoo. I, I haven't used it. I assume it's probably a little bit complicated to set up, because you need to decide what to expose, what you do not expose, how access rights will play with all that, because that's another layer of complexity to add. But if you ever want to do it, it's not that complicated.

MEHDI RACHICO: 24:13

Yeah.

OLIVIER COLSON: 24:13

It's it's again, we have the point of view of the And so we want our, our thing to be the, the, the simplest possible. And come on, it's complicated enough. Uh uh. If you need more advanced things or really want, uh, something specific like that, uh, that we chose not to do, usually the community has done it. And that's the case here. Uh, I suggest we, uh, unless you have something else to know.

MEHDI RACHICO: 24:37

I just wanted to add, like and like, uh, it's, as It's just a tool, after all. Like, to to to make you achieve some goal. Like, for example, shipping, uh, companies usually like, use the soap uh protocol because there are, because they started early in the tech market and soap was really used at that time. So if for like I was, I was faced before the project that you have to have the greatest shipping method. I'm going to say why you so why don't you like expose a rest API for me? I just know I just get informed a bit about Soap and then use the protocol as another communication protocol.

DAMIEN BOUVY: 25:09

It's not that complicated. I mean, soap is a bit It's it's XML based.

MEHDI RACHICO: 25:13

Yeah, exactly. Yeah. But yeah.

OLIVIER COLSON: 25:16

Okay. So, uh, I suggest because we are really a few minutes. I suggest we answer a bunch of questions from the chat again. Um, so, uh, let's start with this one. Actually, uh, so are you currently debating on any potential trendy features to decide if it should be added in Odoo or not?

DAMIEN BOUVY: 25:37

No.

OLIVIER COLSON: 25:38

Haha. Someone wants spoiler for. The next version.

DAMIEN BOUVY: 25:41

Everybody wants spoiler. All the time. Yeah. Uh, let me think. Some trendy features. Uh.

OLIVIER COLSON: 25:50

In accounting I can answer no. I have a lot of things. But not trendy things.

DAMIEN BOUVY: 25:55

Uh, what we did that could be considered already been done, uh, at post 17, I think. So it's 17.1 maybe, uh, we have done something that. Do you know, GraphQL.

MEHDI RACHICO: 26:08

Yeah, yeah.

DAMIEN BOUVY: 26:09

We've, uh, so GraphQL is basically another If you want to continue that debate, it's instead of having it's basically kind of giving access to a database from the, from the, uh, Json world. So you say, hey, I would like to have this object. And within this object I want all the embedded data from other objects that are linked to it. For example, you can ask to have the information for sales orders. Then all the lines of the sales order detailed precisely, then all the products of the lines detailed. And you can go deep and deep and deep and get everything in one payload. Um, GraphQL also includes the notion of mutation with this kind of like RPC. Basically, it's a method. We didn't do that, but we did something that's a bit like, uh, GraphQL with, uh, I don't remember the the name we use in the end, the name we used in the end, but we called it unity endpoint, uh, internally. And it's basically when you load a view in Odoo, we go and tell the server, hey, give me all the information about the sales order. And in the past it would say, okay, this sales order will contain lines. And these lines are those with the IDs, uh, and then a bunch of IDs. And then we had to get to the server and can you say, can you give me all the data for the sales order lines with these, with these IDs? Now we allow the system to read everything in one go, which is from a performance point of view, a good thing, except if you start asking things like too deep, if you go ten levels deep, it means that we have to do a lot of joint tours in the database. And if you stumble upon a table that is absolutely huge and the joint may be super slow, so it's like GraphQL, it can be dangerous if you start to go too deep into the system. That's one of the trendy things we did, but we did it in-house. We didn't implement GraphQL itself. Uh, and besides this, I have nothing that comes really to mind. Uh, um.

OLIVIER COLSON: 28:05

So, you'll have to wait till Odoo experience.

DAMIEN BOUVY: 28:08

Yeah, yeah. Usually the big.

OLIVIER COLSON: 28:09

Don't know yet. Uh.

DAMIEN BOUVY: 28:11

You probably don't know yet. Probably.

OLIVIER COLSON: 28:15

A typical Odoo workflow. Don't worry. Um, okay. Uh, and I suggest we. Conclude with one last question here. Uh, what would be something you'd add to Odoo that would make your life as a developer easier? I would say, again, a trendy thing that you think would be nice. Uh, do you have any idea?

DAMIEN BOUVY: 28:35

I'm going to ask the one who does development for

OLIVIER COLSON: 28:38

Good idea.

MEHDI RACHICO: 28:41

Um, what would you do if. Let me think.

OLIVIER COLSON: 28:46

If you have no idea, it's fine.

DAMIEN BOUVY: 28:47

I have nothing obvious that comes to mind either. We have, uh, we are working on some stuff to simplify some APIs. For example, the debug mode, uh, is kind of a nightmare. Uh, right now, it's it's been. Kind of a mess. For a few years. We've put a lot of stuff in it. Uh, uh, now we're kind of splitting back into, like, its original intention of having a developer mode and like an advanced mode for advanced users, which are not necessarily developers.

OLIVIER COLSON: 29:17

I didn't know we were doing that. Yeah. It's it's it's good. It's coming.

DAMIEN BOUVY: 29:20

Um, so that's one of the things we're simplifying still in early development, uh, it's not even really getting developed. It's still in the planning phase, but we haven't. We plan on reworking the authentication mechanisms in Odoo. So right now we have like the base authentication within Odoo itself with the database password user, blah, blah blah. We have some uh, auth modules that go to fetch users from a remote system. For example, we have the possibility to integrate with Ldap. We had we have some auth integrations that are kind of shaky because in our oath, our oath.

OLIVIER COLSON: 30:00

Our oath.

DAMIEN BOUVY: 30:01

Our oath implementation is kind of old and Um, not from a security point of view, but from a like usability point of view as a developer. And so we are thinking about having some kind of clear authentication framework, which will also add new features like, uh, the Fido Alliance, which is basically a new way to authenticate users without passwords, uh, that uses public-key cryptography based on your devices. So, for example, you will be able to log in to your Odoo account without a password, but with your biometrics on your phone or with the biometrics on your computer. I see you have the same as me you can use your finger on the fingerprint sensor. Uh, so that's this we already have. We plan on using it as a second factor in a two-factor authentication system. We will also like, clean the two-factor authentication mess because we added it like in a stable version with a few modules that need to link everything. So that's kind of trendy in a way. Because authentication right now is, uh, a hot mess, hot debate, maybe not a hot mess, but a hot debate in the development world, because we have we have a lot of attacks in the. So based on password leaking, uh, and this, uh, it's called webauthn. It's not easy to say as well for a French speaker, but Webauthn, uh, allows you to basically avoid passwords altogether and make sure that people it's basically you remove all the men-in-the-middle attack possibilities because it uses cryptography. You remove all the attacks based on, uh, just trying stupid passwords on a lot of accounts.

OLIVIER COLSON: 31:40

That is the thing, a lot of just using passwords. And we see that with two factor authentication that is just like everywhere. Now passwords are not enough anymore because no one puts a password along like this with a lot of random characters. Yeah, unless you have a password manager, but not.

DAMIEN BOUVY: 31:57

Many people have those. I mean, I'm trying to they look at me like, you know, they roll their eyes. Oh, he's here. He comes again with his password manager. But, I mean, I don't know about you, but like, my email account contains my whole life. If you get my Gmail account, you can basically do whatever you want and rename all my accounts and take over my life so yeah, I've secured it as much as I could.

OLIVIER COLSON: 32:21

Of course.

DAMIEN BOUVY: 32:21

But uh, yeah. So that's one of the things that is kind of trendy that is probably going to get into 18. But I mean, as I said, it's still in the planning stage, you'll see.

OLIVIER COLSON: 32:32

And that will be the final word for today. Thank you for your answers, the discussion, and all the powerful insights that you gave us today. And thank you to thanks to you as well for watching this episode and see you again in the next one.

MEHDI RACHICO: 32:47

Cheers. Thank you. Bye. Nice.

OLIVIER COLSON: 32:49

And that's a wrap for today's episode. I hope you enjoyed it as much as I did. If so, don't hesitate to join us on Twitch next time. Having you on the live to interact with us would be awesome! The video of our discussion is also available on YouTube, so it would be nice if you could go there and hit the like button. And if you want to stay with us longer, we have dozens of other podcast episodes available. Until next time. Cheers!