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...
So I'm a senior software developer at age 50, you can call yourself senior for sure, I've worked 15 years
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.
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,
and I've actually organized first and for about 10 years, so I'm getting full circle now as a speaker.
It's actually the first time I can watch talks in full, as organized as you can't do that.
So what is open cloud even, really quickly, an efficient file management and sharing solution, so a drive, so to speak.
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.
Technically, back in this in-go, front end is in view, desktop is, yeah, cute, easy, plus, cute.
So, that the big feature is to make it really quick, it's easy to install the news, we don't need a database,
any sort of storage besides just the file system itself, we have a net as well, but we don't need much infrastructure,
and you can scale it up from a pie up to Kubernetes and whatnot.
So we're also part of the high-end group, which means we have brothers, sisters, cousins in the organization,
are quite interesting as a stack, open talk, for example, which is a video conferencing solution that is also open source,
and mailbox, which is the email provider, if you want those, so we also have a certain affinity to hosting that stuff for sure.
So, this is about we are adding groupware to this solution we already have.
I'm not going to show you something finished, it's still in the works.
Hopefully I can come back next year and show you the thing.
But the interesting part is we are a German client, and we wrote our own German client library and go.
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,
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
and stabilize the thing a little bit. So why JNAP? First of all, it's a time frame thing.
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.
I say, hey, you have this great thing, can we also get the groupware stuff from you guys?
And so we can't spend 10 years developing a completely new, huge groupware solution now.
So JNAP is definitely a massive accelerator in that regard, because it's an API that is so much easier to work with.
I guess everyone here knows how painful it is to work with IMAP.
So JNAP is a completely different experience, the statelessness alone is just a huge game changer also.
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.
Thank you. And also because of stalwart, things to be.
So yeah, we do JNAP, but we really do stalwart. So very important for us in terms of features said what it provides,
so that we can accelerate the development of our solution instead of having to do everything ourselves.
As it would be the case with our JNAP, and without a great JNAP implementation. So thank you, Mauro.
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.
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.
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.
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.
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.
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.
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.
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.
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.
They are quite different because they very much expect to be able to share very easily and share in the broader sense.
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.
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.
That's what I mean with automatic sharing in many ways.
They built in JNAP boxes, of course, and yeah.
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.
Good luck.
You need some sort of structure in there.
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.
That's the whole point of it.
It's really more of a hosting perspective so that you don't need one installation for each customer.
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.
So for example, one tenant could be an address book, but of course not if you have 50,000 people in there.
You could have any group could be an address book, for example, what we can do.
Well, people who've shared file with us are an address book, or people I've shared files with are an address book.
So that's the sort of stuff we want to augment all the data we get from a stalwart with.
Let's call them collaboration units to have something more generic because groups and tenants, whatever that is in your system.
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?
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.
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.
They're names and addresses and photos and whatnot, but more than that.
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.
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.
And if you have a Cassandra, for example, you don't want data center, cross data center queries either.
If you don't, Cassandra knows that, it's going to complain that if you do, which is great.
So you also want to optimize that in those sort of clustering those sharing units.
I want to mention a few things, Mauro is working on, and he asked for whether people are interested in that.
Yes. Something really, really interesting for us, from all perspectives.
So it's gemometer data.
Is essentially attaching custom key value to any gemap object?
So mailbox, email, contact, address book, whatnot, including deep ones, just to serve your supports it.
Really interesting for our perspective.
Let's take an example.
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.
We would have to pull up like a completely new storage that is separate from stalwart, just to store that information.
And whoa, the fun of denormalization, what if someone deletes that folder and I need to know it?
Okay, you all know that sort of nightmare scenario. No one wants that.
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.
You don't want to change the RFC for every requirement you have is a really, really important feature.
Another one that is surprisingly not an RFC yet.
But super interesting as well.
So my proposed a simple protocol to easy manage user settings.
A user is not an object in J-Map.
It has accounts, but the user itself is just what you authenticate as, but it is not an object.
So we won't be able to use the previous one to attach custom data to the user.
Super interesting as well. So my dimensions, password, application, password, basic email forwarding without having to do SIF, blocking email addresses without SIF.
Okay, preferences, times of configuration, et cetera, et cetera. So yes, amazing. That would be great.
J-Map is a book sharing that's more of a standard omission.
Also one of your proposals is super important.
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.
It's mostly because when the J-Map sharing RFC was filed, it was pretty forgotten on mailboxes.
So there's a lot of things you can't share but not mailboxes.
Super important as well.
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.
It's going to be living within a very large system.
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.
And you're not going to dictate to them how it has to work. I mean to some extent, but not much.
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.
There are some, for example, there's a p-clock extension to do that, but that's not part of the standard.
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.
It's only authentication. So that is still around.
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.
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.
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.
And usually your key plug is going to have LDAP behind it anyway, so.
One topic I want to touch on is Master's Education, which is still going to be used a lot in integration scenarios.
So what is Master's Education? It's essentially in personation using a shared secret.
It happens to be a password, but it's a shared secret.
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.
And definitely, you notice.
But it's still often necessary. I'll have a little picture after that to explain the better, maybe what I mean.
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.
But it would be mutual TLS or CCWTs, because at least then they have an expiration time.
So if you intercept that, it's only going to be for a limited time.
But, so essentially, with the example of our stuff here, but the client talks to an OIDC IDP first.
For example, kicklook uses the credentials to authenticate and they get a token back.
That's also kicklook's going to talk to an LLB.
You get the token back and then authenticate against our back end using the token.
We validate that token, but then we need to talk to StarWart.
We don't have the credentials of the users. Obviously, that's the whole point.
Because StarWart does not yet support validating the JWTs unless it itself the IDP.
But I'm sure it's going to change that some point.
It doesn't already. I'm saying I'm not up to date. You're probably implemented at yesterday.
Ah, no, okay.
Okay. It doesn't care about it.
So, but it's still a frequent scenario you're going to have to use.
You're going to have to use impersonation, muscle authentication, which it can do in many pieces of stuff they can do.
But it would be, of course, you still send the same JWT through and can check the same signature or you make another JWT.
At least you have only temporary capture of that.
We'll only give access for a couple minutes at this.
But you also have to keep in mind that there's always going to be, like, that's just more from the hosting perspective.
There's always going to be different channels to which your may is going to be accessed.
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
I'm just, I'm at clients or Apple Mail or what, no, to access their email.
And so you have authentication not just happening there, but you're also going to have just playing I'm at authentication using credentials.
Hopefully some, uh, Cecil, oh, I was there with hope, but we had to talk about that yesterday.
Adoption is not amazing.
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.
So in terms of authentication, it would be great to have an authentication API.
There's no standard for that.
And where we could delegate all those authentication calls.
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.
So you can do it once, but also because you want some sort of solution in place that can track brute force attempts.
So you want to have some sort of, okay, the blue one is kind of like a representation.
You really want some service that's going to delegate.
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.
It's just going to happen all the protocols we have open and all the products you have on your website.
Another topic one late provisioning.
No one wants to provision data into multiple systems.
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.
So after keep a state after retry, when do I give up, do I roll back or not?
Because you don't have transactions.
Great.
And you have to think about deep provisioning as well.
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?
But what happens after three months?
You're just going to delete the data right away so then buy their account.
Not be great as a customer, right?
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.
I'm still going to have all my data in there.
Same if someone misses a payment.
I'm not going to delete the data right away either.
If you want to keep that around for a certain time.
So provisioning and deep provisioning are going to have is quite complex with workflows and
states of users.
You have to memorize and yeah.
That's also always an integration challenge because you're not.
Your mail service is not going to be the only piece of software in that puzzle for sure.
Certainly from a hostess perspective where you provide, hey, I have some drive space.
And you have some wet mail.
And you have other things.
And you have an office suite.
Well, you have to provision into all those systems so that's always a big integration challenge as well.
And you're also always going to have upselling for hostaries and the larger ones certainly commercial ones.
Because just a simple example you're going to get free wet mail for nothing.
But if you want more quota or more features, you're going to have to pace also going to have states.
So they're going to have their sort of admin software solution connected with their IDM in place that tracks customers contracts,
billing which features which quotas they have, etc.
You have to integrate with all that.
So provisioning major challenge.
I hope you didn't expect me to give a solution.
So what did help to use an existing protocol like?
Yeah, but it'd be helpful to use the existing protocol like skin.
Skin is really more modeled for simpler scenarios.
Yes, for sure.
But you're probably still going to end up having lots of extensions to the standard.
Yes.
But you're still going to be stuck with the issue that you have to do that transactionally.
Which you don't over multiple systems anyways.
One point that's kept over if you do the service software having something like auto provisioning is really helpful.
So what I mean with that is if a user authenticates and it doesn't exist yet, just create it immediately.
That not helps, but still going to have the complexity anyway.
So it doesn't help with group permissions and features for sure.
No easy solutions.
You're saying, just wanted to share experience on the platform of painful things.
There are a lot of existing layers on the outside, and you're probably going to change them.
If you don't speak J-Map, is that any layout that has next J-Map to my map?
So the question is whether there are lots of main service out there and only very few that speak J-Map.
And if there's any sort of translation layer that could do a J-Map to I'm a bridge?
No.
So for us, our strategy is very much stalwart.
Do not hurt this man, or you haven't problem with me.
Maybe shortly, let's sneak in Brown for a comment.
I don't know.
You wanted to comment on that?
I was going to say that he's one, but it's very outdated and it needs to be updated.
But I wrote it.
So Brown said there is one, but it's ten years old.
I didn't want to out you in public.
Now you're going to have to maintain it, you understand?
I'm sorry.
About the token validation.
About the open AP policy agent from the CNCF to like standardize how every application does the token validation of the credential validation.
Maybe using the open policy, then be here.
So, right, your comment is maybe using CNCF open policy.
Again, it is, is it going to be part of your infrastructure or not?
You're usually going to be sitting inside something that already exists?
So it could be something if you can push it in there, but
It can be easily extended and like you can write your own policy to adapt to the cost of any infrastructure.
So it can be written and extended to be adapted to the situation, but
I don't have much expertise with it, barely.
So maybe I could be something, but it's yet another layer.
I'll tell you down.
Thanks.
Yeah.
On the very more generic point, are you in contact with last week?
No.
The question was what a way in contact with last week in the movie.
And some, but I'm not me.
Instead of using the LDAP to provide the groupware data as your source,
it could be an idea to store this data in your IDM and provide it as an attribute.
That's an attribute of the response.
So the question is whether instead of using LDAP, whether the data shouldn't come from the IDM,
and they are supposed to mean your duty claims, carrying the data then.
Yeah, in part, but not for groups, but there's going to be points where you want groups
really very specific example, but that you need a ton.
If you are part of a group, at some point, you want to say, OK, whose else is in this group.
And so the claims are not going to be including other people in the group, because it's highly volatile as well.
And so it house for some things for sure.
But it's also difficult to depend on, like, please never give us opaque tokens.
So having to ping back to the IDM is just to the IDP is just pain and unnecessary.
And actually, that's what performance from experience.
But yeah, we can't show everything into claims either.
Yeah, for some things for sure.
For the attributes, but it is going to pertain to the user itself in not to other constructs that you have.
So, and it doesn't have to be added.
For example, for us, we have a lot of data that's in the file system from open cloud.
So it doesn't have to be added.
It was mentioning, because some people hating on LDAP lately.
Still around.
So, we might have time for one very quick question.
Is there any otherwise?
No, sorry.
So, up close, I'm for release.
Are they?
I didn't hear the question.
Thank you.