WEBVTT 00:00.000 --> 00:19.000 All right, up to the next one, that's me, so very briefly, I have way too many slides, so I'm going to try to... 00:19.000 --> 00:24.000 So I'm a senior software developer at age 50, you can call yourself senior for sure, I've worked 15 years 00:24.000 --> 00:32.000 so I thought it was worth lying, about 10 years of open exchange, already in bail and such as well, and about almost a year now for open cloud. 00:32.000 --> 00:40.000 In the past time of free time, I've been an open user contributor a lot for a long time, I've been open user board twice, 00:40.000 --> 00:46.000 and I've actually organized first and for about 10 years, so I'm getting full circle now as a speaker. 00:46.000 --> 00:52.000 It's actually the first time I can watch talks in full, as organized as you can't do that. 00:52.000 --> 01:02.000 So what is open cloud even, really quickly, an efficient file management and sharing solution, so a drive, so to speak. 01:02.000 --> 01:12.000 Everything is open source and very sizes, we have a great web UI, we have desktop clients including for Linux, they're in cute, and mobile apps. 01:12.000 --> 01:18.000 Technically, back in this in-go, front end is in view, desktop is, yeah, cute, easy, plus, cute. 01:19.000 --> 01:26.000 So, that the big feature is to make it really quick, it's easy to install the news, we don't need a database, 01:26.000 --> 01:32.000 any sort of storage besides just the file system itself, we have a net as well, but we don't need much infrastructure, 01:32.000 --> 01:38.000 and you can scale it up from a pie up to Kubernetes and whatnot. 01:38.000 --> 01:45.000 So we're also part of the high-end group, which means we have brothers, sisters, cousins in the organization, 01:45.000 --> 01:53.000 are quite interesting as a stack, open talk, for example, which is a video conferencing solution that is also open source, 01:53.000 --> 02:04.000 and mailbox, which is the email provider, if you want those, so we also have a certain affinity to hosting that stuff for sure. 02:04.000 --> 02:10.000 So, this is about we are adding groupware to this solution we already have. 02:10.000 --> 02:13.000 I'm not going to show you something finished, it's still in the works. 02:13.000 --> 02:17.000 Hopefully I can come back next year and show you the thing. 02:17.000 --> 02:27.000 But the interesting part is we are a German client, and we wrote our own German client library and go. 02:27.000 --> 02:33.000 We might split it off at some point as an independent thing, I mean, it's already there in open source and everything right now, 02:33.000 --> 02:41.000 but it's like part of the whole thing at the moment, probably makes sense at some point that I wanted to get some real good usage first 02:41.000 --> 02:47.000 and stabilize the thing a little bit. So why JNAP? First of all, it's a time frame thing. 02:47.000 --> 02:57.000 We all know there's a big demand for EU sovereign solutions, one not only in the EU, and that's where we get a lot of requests for our products. 02:57.000 --> 03:03.000 I say, hey, you have this great thing, can we also get the groupware stuff from you guys? 03:03.000 --> 03:10.000 And so we can't spend 10 years developing a completely new, huge groupware solution now. 03:10.000 --> 03:16.000 So JNAP is definitely a massive accelerator in that regard, because it's an API that is so much easier to work with. 03:16.000 --> 03:21.000 I guess everyone here knows how painful it is to work with IMAP. 03:21.000 --> 03:31.000 So JNAP is a completely different experience, the statelessness alone is just a huge game changer also. 03:31.000 --> 03:41.000 And many, many regards as so much. Well, now it's the API to work with, and it puts a lot of burden on the mail server. 03:41.000 --> 03:46.000 Thank you. And also because of stalwart, things to be. 03:46.000 --> 03:55.000 So yeah, we do JNAP, but we really do stalwart. So very important for us in terms of features said what it provides, 03:55.000 --> 04:00.000 so that we can accelerate the development of our solution instead of having to do everything ourselves. 04:01.000 --> 04:09.000 As it would be the case with our JNAP, and without a great JNAP implementation. So thank you, Mauro. 04:09.000 --> 04:18.000 One thing we chose to do, though, is so we have our clients, especially our web UI, and we don't talk JNAP to the outside. 04:18.000 --> 04:29.000 So we have a layer in between, and the reason for that choice was that we would like to intercept data that comes in and have high level API calls from the client. 04:29.000 --> 04:43.000 JNAP is amazing. You can chain or probably everyone knows it here. You can chain small commands together and have back references and everything to avoid wrong trips. So you can construct much more complex requests with smaller ones. 04:43.000 --> 04:56.000 That's amazing, but I don't want our clients to do that with us, because then I have to reverse engineer what they're doing to try to understand if I want to do caching or inject additional data. 04:56.000 --> 05:15.000 I mentioned a couple of examples for that later. So we have a high level rest API, but we do use and we use JNAP data structures, data models as much as possible. Obviously, it's pretty much all JNAP except the APIs. 05:15.000 --> 05:33.000 One of the things you want to do, where we see a big asset there, is we want to add data that we have from other components in a big system. So data from our drive system, but also from open talk at some point to enrich the model that is there. 05:33.000 --> 05:47.000 Obviously, everyone, everything. But an interesting aspect is you have to look at there is really one that there's actually really very distinct sort of scenarios in terms of target audiences for your system. 05:47.000 --> 05:57.000 One is like the holster sort of scenario where, for example, you go to mailbox to buy an account and it's essentially just you and not much collaboration. 05:57.000 --> 06:15.000 And all the other options, be like a small SMB, I don't know, like an office of with three lawyers and five secretaries or something like that, up to education, education networks where you have hundreds of thousands of mailboxes or private companies. 06:15.000 --> 06:24.000 They are quite different because they very much expect to be able to share very easily and share in the broader sense. 06:24.000 --> 06:36.000 So having things like email account representatives, which is great, which is built in in JNAP in many ways, which is amazing, because if you want to know what I mean. 06:36.000 --> 06:50.000 Also having automatically share the rest books, for example, if you're in a tenant or in a group of certain in some sort of way or in a department, you expect to have an address book where all your colleagues are in there that you don't need to provision them or add in yourself, etc. 06:50.000 --> 06:55.000 That's what I mean with automatic sharing in many ways. 06:55.000 --> 07:04.000 They built in JNAP boxes, of course, and yeah. 07:04.000 --> 07:17.000 Right, so larger organizations that we want to have groups and departments of all sorts of ways, because those are the perspectives you have on the system, because if you have 30,000 users or 100,000 users in your system. 07:17.000 --> 07:18.000 Good luck. 07:18.000 --> 07:20.000 You need some sort of structure in there. 07:20.000 --> 07:29.000 You're going to have tenants for sure, the tenants are completely separate, at least everyone has a slightly different definition, but usually they're going to be completely different in terms of data. 07:29.000 --> 07:31.000 That's the whole point of it. 07:31.000 --> 07:38.000 It's really more of a hosting perspective so that you don't need one installation for each customer. 07:38.000 --> 07:47.000 And then you're going to have some sort of groups in there, and those are the ones where you want to have a lot of sharing in between. 07:47.000 --> 07:53.000 So for example, one tenant could be an address book, but of course not if you have 50,000 people in there. 07:53.000 --> 07:58.000 You could have any group could be an address book, for example, what we can do. 07:58.000 --> 08:04.000 Well, people who've shared file with us are an address book, or people I've shared files with are an address book. 08:04.000 --> 08:17.000 So that's the sort of stuff we want to augment all the data we get from a stalwart with. 08:17.000 --> 08:24.000 Let's call them collaboration units to have something more generic because groups and tenants, whatever that is in your system. 08:24.000 --> 08:33.000 Those are also shouting units, because at some point you likely have memory caches on your notes and you want to hit the hot caches, right? 08:33.000 --> 08:40.000 That you end up on a note where you don't have the data and you first have to retrieve that from some sort of storage that you have somewhere. 08:40.000 --> 08:58.000 So you want data routing that a certain user always ends up on the same cluster node, but not just that, because if you have these sort of collaborative units of groups of people, the data you're most likely going to fetch is not just yours, but also the data of those people. 08:58.000 --> 09:02.000 They're names and addresses and photos and whatnot, but more than that. 09:02.000 --> 09:14.000 So you really want those to be shouting units that are served by the same notes, ideally, so that you can keep hot caches of them. 09:14.000 --> 09:23.000 Also, depending on what sort of storage you have, if you have, I don't know, a galera cluster, for example, you don't want to have cross database queries. 09:23.000 --> 09:29.000 And if you have a Cassandra, for example, you don't want data center, cross data center queries either. 09:29.000 --> 09:35.000 If you don't, Cassandra knows that, it's going to complain that if you do, which is great. 09:35.000 --> 09:46.000 So you also want to optimize that in those sort of clustering those sharing units. 09:46.000 --> 09:53.000 I want to mention a few things, Mauro is working on, and he asked for whether people are interested in that. 09:53.000 --> 10:00.000 Yes. Something really, really interesting for us, from all perspectives. 10:00.000 --> 10:04.000 So it's gemometer data. 10:04.000 --> 10:12.000 Is essentially attaching custom key value to any gemap object? 10:12.000 --> 10:22.000 So mailbox, email, contact, address book, whatnot, including deep ones, just to serve your supports it. 10:22.000 --> 10:25.000 Really interesting for our perspective. 10:25.000 --> 10:26.000 Let's take an example. 10:26.000 --> 10:35.000 If you want to do something that's not in a gemap standard, like the ability in the UI to, or I haven't, I have a folder here, from my mail, and I want to define a color on it. 10:35.000 --> 10:45.000 We would have to pull up like a completely new storage that is separate from stalwart, just to store that information. 10:45.000 --> 10:51.000 And whoa, the fun of denormalization, what if someone deletes that folder and I need to know it? 10:51.000 --> 10:55.000 Okay, you all know that sort of nightmare scenario. No one wants that. 10:55.000 --> 11:03.000 And so the ability to attach a proprietary or custom data that might become a standard, maybe one day, but that's not what usually going to start with. 11:03.000 --> 11:14.000 You don't want to change the RFC for every requirement you have is a really, really important feature. 11:14.000 --> 11:19.000 Another one that is surprisingly not an RFC yet. 11:19.000 --> 11:21.000 But super interesting as well. 11:21.000 --> 11:27.000 So my proposed a simple protocol to easy manage user settings. 11:27.000 --> 11:30.000 A user is not an object in J-Map. 11:30.000 --> 11:35.000 It has accounts, but the user itself is just what you authenticate as, but it is not an object. 11:35.000 --> 11:40.000 So we won't be able to use the previous one to attach custom data to the user. 11:40.000 --> 11:52.000 Super interesting as well. So my dimensions, password, application, password, basic email forwarding without having to do SIF, blocking email addresses without SIF. 11:52.000 --> 12:00.000 Okay, preferences, times of configuration, et cetera, et cetera. So yes, amazing. That would be great. 12:00.000 --> 12:05.000 J-Map is a book sharing that's more of a standard omission. 12:05.000 --> 12:08.000 Also one of your proposals is super important. 12:08.000 --> 12:14.000 I don't need to mention all that much about it. Obviously in some sort of enterprise setting, you absolutely want to have that ability. 12:14.000 --> 12:22.000 It's mostly because when the J-Map sharing RFC was filed, it was pretty forgotten on mailboxes. 12:22.000 --> 12:25.000 So there's a lot of things you can't share but not mailboxes. 12:25.000 --> 12:28.000 Super important as well. 12:28.000 --> 12:46.000 I want to mention a few things we typically run into and more of an enterprise setting in terms of challenges to integrate many components because it's not just going to be your one mail server and your browser at home. 12:46.000 --> 12:51.000 It's going to be living within a very large system. 12:51.000 --> 13:04.000 So typically from experience larger customers will want to have customer authentication implementations because they already have an IDM in place, they already have provisioning in place, they already have an holding administration system in place. 13:04.000 --> 13:11.000 And you're not going to dictate to them how it has to work. I mean to some extent, but not much. 13:12.000 --> 13:22.000 OIDC is great as a great integration technology for standard for authentication, but it's just not enough. For example, you can't get a group membership out of OIDC. 13:22.000 --> 13:27.000 There are some, for example, there's a p-clock extension to do that, but that's not part of the standard. 13:27.000 --> 13:34.000 For example, you find to say, hey, I have a group here, give you the list of people in there, that's not going to give you that. 13:34.000 --> 13:39.000 It's only authentication. So that is still around. 13:40.000 --> 13:49.000 But, many seem to hate it, but actually, it's very fast. It's really well supported in very much any programming language with lots of SDKs. 13:49.000 --> 14:02.000 They're really good. It's the article and we have open at the very least open LDAP as a really good implementation, not necessarily must work with, but it's really good at replication and you can define indexes for performance. 14:02.000 --> 14:10.000 So it really scales really, really well. So maybe don't spit too much from LDAP, it's actually, it's always still going to be around for a while. 14:10.000 --> 14:15.000 And usually your key plug is going to have LDAP behind it anyway, so. 14:15.000 --> 14:23.000 One topic I want to touch on is Master's Education, which is still going to be used a lot in integration scenarios. 14:23.000 --> 14:30.000 So what is Master's Education? It's essentially in personation using a shared secret. 14:30.000 --> 14:34.000 It happens to be a password, but it's a shared secret. 14:34.000 --> 14:42.000 It's not ideal because if someone intercepts that password, of course it has to be encrypted, but if someone intercepts that, they have access to all the data of all the users. 14:42.000 --> 14:45.000 And definitely, you notice. 14:45.000 --> 14:51.000 But it's still often necessary. I'll have a little picture after that to explain the better, maybe what I mean. 14:52.000 --> 15:04.000 But you are living inside of a trusted zone, so it's not that much of an issue either. You can use IP address ranges or additional secrets to try to restrict the usage a bit more. 15:04.000 --> 15:09.000 But it would be mutual TLS or CCWTs, because at least then they have an expiration time. 15:09.000 --> 15:14.000 So if you intercept that, it's only going to be for a limited time. 15:14.000 --> 15:24.000 But, so essentially, with the example of our stuff here, but the client talks to an OIDC IDP first. 15:24.000 --> 15:31.000 For example, kicklook uses the credentials to authenticate and they get a token back. 15:31.000 --> 15:35.000 That's also kicklook's going to talk to an LLB. 15:35.000 --> 15:42.000 You get the token back and then authenticate against our back end using the token. 15:42.000 --> 15:45.000 We validate that token, but then we need to talk to StarWart. 15:45.000 --> 15:50.000 We don't have the credentials of the users. Obviously, that's the whole point. 15:50.000 --> 15:58.000 Because StarWart does not yet support validating the JWTs unless it itself the IDP. 15:58.000 --> 16:01.000 But I'm sure it's going to change that some point. 16:01.000 --> 16:07.000 It doesn't already. I'm saying I'm not up to date. You're probably implemented at yesterday. 16:08.000 --> 16:10.000 Ah, no, okay. 16:12.000 --> 16:15.000 Okay. It doesn't care about it. 16:15.000 --> 16:19.000 So, but it's still a frequent scenario you're going to have to use. 16:19.000 --> 16:26.000 You're going to have to use impersonation, muscle authentication, which it can do in many pieces of stuff they can do. 16:26.000 --> 16:36.000 But it would be, of course, you still send the same JWT through and can check the same signature or you make another JWT. 16:36.000 --> 16:39.000 At least you have only temporary capture of that. 16:39.000 --> 16:44.000 We'll only give access for a couple minutes at this. 16:44.000 --> 16:49.000 But you also have to keep in mind that there's always going to be, like, that's just more from the hosting perspective. 16:49.000 --> 16:54.000 There's always going to be different channels to which your may is going to be accessed. 16:54.000 --> 17:03.000 Because as amazing as our web client is going to be, there's still going to be users using different applications or the mobile phones or 17:03.000 --> 17:08.000 I'm just, I'm at clients or Apple Mail or what, no, to access their email. 17:08.000 --> 17:17.000 And so you have authentication not just happening there, but you're also going to have just playing I'm at authentication using credentials. 17:17.000 --> 17:27.000 Hopefully some, uh, Cecil, oh, I was there with hope, but we had to talk about that yesterday. 17:27.000 --> 17:29.000 Adoption is not amazing. 17:30.000 --> 17:44.000 Maybe Apple will actually, but that would be great and better, but you're still going to have multiple channels through which and different authentication mechanisms from hosting perspective. 17:44.000 --> 17:48.000 So in terms of authentication, it would be great to have an authentication API. 17:48.000 --> 17:51.000 There's no standard for that. 17:51.000 --> 17:54.000 And where we could delegate all those authentication calls. 17:54.000 --> 18:06.000 So that when you have to implement customizations for certain customer or 10 different ones, you can do that in one place and you don't have to do it like in your software and install one or any other part, et cetera. 18:06.000 --> 18:14.000 So you can do it once, but also because you want some sort of solution in place that can track brute force attempts. 18:14.000 --> 18:19.000 So you want to have some sort of, okay, the blue one is kind of like a representation. 18:19.000 --> 18:22.000 You really want some service that's going to delegate. 18:22.000 --> 18:31.000 You're going to delegate those authentication attempts by so that you can detect brute force attacks that happen across multiple channels because they're not just going to happen on I'm at it. 18:31.000 --> 18:38.000 It's just going to happen all the protocols we have open and all the products you have on your website. 18:38.000 --> 18:41.000 Another topic one late provisioning. 18:41.000 --> 18:44.000 No one wants to provision data into multiple systems. 18:44.000 --> 18:50.000 It's absolute hell because then you have to start keeping track of, okay, this worked and there it worked and they didn't work. 18:50.000 --> 18:54.000 So after keep a state after retry, when do I give up, do I roll back or not? 18:54.000 --> 18:56.000 Because you don't have transactions. 18:56.000 --> 18:58.000 Great. 18:58.000 --> 19:00.000 And you have to think about deep provisioning as well. 19:00.000 --> 19:10.000 And you're often going to end up being in some sort of work flows anyways because, hey, what if I want to provide three months or three access to this service? 19:10.000 --> 19:12.000 But what happens after three months? 19:12.000 --> 19:16.000 You're just going to delete the data right away so then buy their account. 19:16.000 --> 19:18.000 Not be great as a customer, right? 19:18.000 --> 19:26.000 We'll be nice to give them some sort of grace period after which I'm going to subscribe to this three weeks after the deadline. 19:26.000 --> 19:28.000 I'm still going to have all my data in there. 19:28.000 --> 19:31.000 Same if someone misses a payment. 19:31.000 --> 19:34.000 I'm not going to delete the data right away either. 19:34.000 --> 19:36.000 If you want to keep that around for a certain time. 19:36.000 --> 19:41.000 So provisioning and deep provisioning are going to have is quite complex with workflows and 19:41.000 --> 19:42.000 states of users. 19:42.000 --> 19:45.000 You have to memorize and yeah. 19:45.000 --> 19:48.000 That's also always an integration challenge because you're not. 19:48.000 --> 19:53.000 Your mail service is not going to be the only piece of software in that puzzle for sure. 19:53.000 --> 19:58.000 Certainly from a hostess perspective where you provide, hey, I have some drive space. 19:58.000 --> 19:59.000 And you have some wet mail. 19:59.000 --> 20:00.000 And you have other things. 20:00.000 --> 20:02.000 And you have an office suite. 20:02.000 --> 20:08.000 Well, you have to provision into all those systems so that's always a big integration challenge as well. 20:09.000 --> 20:15.000 And you're also always going to have upselling for hostaries and the larger ones certainly commercial ones. 20:15.000 --> 20:21.000 Because just a simple example you're going to get free wet mail for nothing. 20:21.000 --> 20:26.000 But if you want more quota or more features, you're going to have to pace also going to have states. 20:26.000 --> 20:34.000 So they're going to have their sort of admin software solution connected with their IDM in place that tracks customers contracts, 20:34.000 --> 20:37.000 billing which features which quotas they have, etc. 20:37.000 --> 20:39.000 You have to integrate with all that. 20:39.000 --> 20:42.000 So provisioning major challenge. 20:42.000 --> 20:52.000 I hope you didn't expect me to give a solution. 20:52.000 --> 21:15.000 So what did help to use an existing protocol like? 21:15.000 --> 21:25.000 Yeah, but it'd be helpful to use the existing protocol like skin. 21:25.000 --> 21:29.000 Skin is really more modeled for simpler scenarios. 21:29.000 --> 21:30.000 Yes, for sure. 21:30.000 --> 21:35.000 But you're probably still going to end up having lots of extensions to the standard. 21:35.000 --> 21:36.000 Yes. 21:36.000 --> 21:44.000 But you're still going to be stuck with the issue that you have to do that transactionally. 21:44.000 --> 21:48.000 Which you don't over multiple systems anyways. 21:48.000 --> 21:56.000 One point that's kept over if you do the service software having something like auto provisioning is really helpful. 21:56.000 --> 22:02.000 So what I mean with that is if a user authenticates and it doesn't exist yet, just create it immediately. 22:02.000 --> 22:07.000 That not helps, but still going to have the complexity anyway. 22:07.000 --> 22:22.000 So it doesn't help with group permissions and features for sure. 22:22.000 --> 22:23.000 No easy solutions. 22:23.000 --> 22:29.000 You're saying, just wanted to share experience on the platform of painful things. 22:30.000 --> 22:36.000 There are a lot of existing layers on the outside, and you're probably going to change them. 22:36.000 --> 22:44.000 If you don't speak J-Map, is that any layout that has next J-Map to my map? 22:44.000 --> 22:50.000 So the question is whether there are lots of main service out there and only very few that speak J-Map. 22:50.000 --> 22:55.000 And if there's any sort of translation layer that could do a J-Map to I'm a bridge? 22:55.000 --> 22:56.000 No. 22:57.000 --> 23:03.000 So for us, our strategy is very much stalwart. 23:03.000 --> 23:08.000 Do not hurt this man, or you haven't problem with me. 23:08.000 --> 23:11.000 Maybe shortly, let's sneak in Brown for a comment. 23:11.000 --> 23:12.000 I don't know. 23:12.000 --> 23:14.000 You wanted to comment on that? 23:14.000 --> 23:19.000 I was going to say that he's one, but it's very outdated and it needs to be updated. 23:19.000 --> 23:20.000 But I wrote it. 23:21.000 --> 23:28.000 So Brown said there is one, but it's ten years old. 23:28.000 --> 23:31.000 I didn't want to out you in public. 23:31.000 --> 23:34.000 Now you're going to have to maintain it, you understand? 23:35.000 --> 23:36.000 I'm sorry. 23:36.000 --> 23:39.000 About the token validation. 23:39.000 --> 23:50.000 About the open AP policy agent from the CNCF to like standardize how every application does the token validation of the credential validation. 23:50.000 --> 23:55.000 Maybe using the open policy, then be here. 23:55.000 --> 23:59.000 So, right, your comment is maybe using CNCF open policy. 24:00.000 --> 24:03.000 Again, it is, is it going to be part of your infrastructure or not? 24:03.000 --> 24:07.000 You're usually going to be sitting inside something that already exists? 24:07.000 --> 24:11.000 So it could be something if you can push it in there, but 24:11.000 --> 24:21.000 It can be easily extended and like you can write your own policy to adapt to the cost of any infrastructure. 24:21.000 --> 24:25.000 So it can be written and extended to be adapted to the situation, but 24:26.000 --> 24:30.000 I don't have much expertise with it, barely. 24:30.000 --> 24:35.000 So maybe I could be something, but it's yet another layer. 24:35.000 --> 24:37.000 I'll tell you down. 24:37.000 --> 24:38.000 Thanks. 24:38.000 --> 24:39.000 Yeah. 24:39.000 --> 24:45.000 On the very more generic point, are you in contact with last week? 24:45.000 --> 24:46.000 No. 24:46.000 --> 24:50.000 The question was what a way in contact with last week in the movie. 24:50.000 --> 24:55.000 And some, but I'm not me. 24:55.000 --> 25:02.000 Instead of using the LDAP to provide the groupware data as your source, 25:02.000 --> 25:08.000 it could be an idea to store this data in your IDM and provide it as an attribute. 25:08.000 --> 25:12.000 That's an attribute of the response. 25:12.000 --> 25:16.000 So the question is whether instead of using LDAP, whether the data shouldn't come from the IDM, 25:16.000 --> 25:20.000 and they are supposed to mean your duty claims, carrying the data then. 25:20.000 --> 25:24.000 Yeah, in part, but not for groups, but there's going to be points where you want groups 25:24.000 --> 25:27.000 really very specific example, but that you need a ton. 25:27.000 --> 25:31.000 If you are part of a group, at some point, you want to say, OK, whose else is in this group. 25:31.000 --> 25:37.000 And so the claims are not going to be including other people in the group, because it's highly volatile as well. 25:37.000 --> 25:40.000 And so it house for some things for sure. 25:40.000 --> 25:45.000 But it's also difficult to depend on, like, please never give us opaque tokens. 25:45.000 --> 25:51.000 So having to ping back to the IDM is just to the IDP is just pain and unnecessary. 25:51.000 --> 25:54.000 And actually, that's what performance from experience. 25:54.000 --> 25:57.000 But yeah, we can't show everything into claims either. 25:57.000 --> 25:59.000 Yeah, for some things for sure. 25:59.000 --> 26:04.000 For the attributes, but it is going to pertain to the user itself in not to other constructs that you have. 26:04.000 --> 26:06.000 So, and it doesn't have to be added. 26:06.000 --> 26:11.000 For example, for us, we have a lot of data that's in the file system from open cloud. 26:11.000 --> 26:12.000 So it doesn't have to be added. 26:12.000 --> 26:16.000 It was mentioning, because some people hating on LDAP lately. 26:16.000 --> 26:17.000 Still around. 26:17.000 --> 26:20.000 So, we might have time for one very quick question. 26:20.000 --> 26:23.000 Is there any otherwise? 26:23.000 --> 26:27.000 No, sorry. 26:27.000 --> 26:32.000 So, up close, I'm for release. 26:32.000 --> 26:34.000 Are they? 26:34.000 --> 26:36.000 I didn't hear the question. 26:42.000 --> 26:43.000 Thank you. 26:43.000 --> 26:45.000 Thank you. 26:45.000 --> 26:46.000 Thank you.