Session Date/Time: 21 Jul 2026 07:00
[00:00:51] Thibault Cholez: This one's yours? Yeah. I have to connect the. Do you know how the clicker is supposed to work?
[00:01:16] Mikael Nordfeldth: No. I like it.
[00:01:17] Thibault Cholez: Just the go button? You have to. And you're
[00:01:34] Anna Larch: doing it through the tool?
[00:01:36] Thibault Cholez: This one? Yeah. Yeah. K. What I'll do hang on. Let me figure it out. Can you wait for just a second? Okay. Let me get my sound. Perfect. Good. Welcome, everyone. So it's nine past, and I think we we can start a meeting. So welcome, everyone, to, like, the first in person meeting for the OpenCloud Mesh group, OCM group. This session will be recorded. And if you're not yet signed on the for for those on-site, if you're not yet signed on the on-site tool, there are, like, some QR codes that you have next to the mic, which you can scan the QR code and sign up on the online on-site tool. That said, before we start, these are not well, which you should not well. You probably have seen it a couple of time already in, like, yesterday's session. Essentially, I will, like, leave some time for people to, like, read it. It tries to it covers, like, the code and guidelines and code of conduct that we have while participating in the IETF. It means that, like, you will, like, behave in a and interact in a professional manner. There are, like, some rules around, like, intellectual property, it essentially, like, defines the guidelines that, like, you should all have read before I'm coming and participating. Good. A couple of, like, instruction for participating in, like, the the the meeting for participant which are remote. You know, I think we have a couple, like, which are remote. Make sure your audio and videos are off unless you're presenting during the session, and use a headset which, like, avoids the echo and, like, other issue you might have. For participants, when you, like, interact, please, like, raise your hand and, like, state your name at the beginning of, like, participating in the queue. That said, we have quite an agenda, I think, for today. We'll, like, we'll go, like, through the document status, then present, like, the like, because it's a first in person meeting, like, recap about, like, how Centimeters, like, came to be and, like, what is the road map as of today. And then we, like, start, like, the proper draft discussion, which has been structured in a couple of sections. Finally, there are, like, some new draft which will be presented, such as, as, like, how would you, like, federated groups over MLS, and then some discussion for, like, implementers. Any agenda bashing before we start? Mikael?
[00:04:39] Mikael Nordfeldth: I think maybe we
[00:04:41] Thibault Cholez: can Oh, Mikael, can you go to the mic? Thank you.
[00:04:46] Mikael Nordfeldth: Yes, Mike. Maybe we can do it in the discussion section, but I think Aaron might have some notes on authentication for us. So if we can make sure not to overdraft time so we have time to discuss that, that would be excellent.
[00:05:04] Thibault Cholez: Okay. That will work perfectly. Thank you. Any other agenda bashing? I see none. Therefore, we'll we'll proceed. As for document status, we have, like, one document which is adopted by the working group, which is, like, the OCM open cloud mesh draft, which moved from draft four to actually draft six as of this week. So lately, slightly outdated on that site. Before we start, I want to check-in the room to sense who has read this version or earlier version of the draft.
[00:05:40] Anna Larch: And if you're a remote participant, you can speak up in the Zulip text chat.
[00:05:51] Thibault Cholez: Yep. How
[00:05:52] Anna Larch: many are new participants of IETF?
[00:05:55] Thibault Cholez: Oh, how many people are new participant of IETF? That's it. Welcome. To you all. Okay. So we got a couple of people that, like, read, like, the version, and, I think on that, we'll start with, like, the first presentation by Giuseppe.
[00:06:26] Giuseppe Lo Presti: Okay. Very good. So, Giuseppe, I love you well. Maybe I go okay. I go directly back and get back. That's that's good. So good morning. Thanks for for coming. So this is really first in person meeting. So we thought it would be good to have a little bit of overview also what OCM is and what what is behind us with this work that we've been doing already for some time. So this this is actually something that started already a bit more than ten years ago. And the key aspect, if you like, of this initiative is to try and have what we call the dispatch one year ago, the dating protocol between computers. That is a way to share resources, institutional resources in particular, across administrative domains. So without the need of having a common login across different institutions. So, indeed, this started already long ago. It has been hosted in different kind of institutions or collaborations, and it also received funding across different European projects and other initiatives. Actually, we're going to start very soon a new project from this kiosk. I will mention something about that in a moment. So this will start soon in September. So this is actually still growing. And if if I can recap actually what happened within the ATF, so during those ten years, there were implementations, but this was a little bit of a, shall I say, handmade standard without re really making things very, very well enforced. One year ago, we decided to make this proper with a proper draft and proposed it to to ATF. So we got this passed at ATF one twenty three one year ago in in Madrid. And then a working group was actually was actually formed. Thanks to Andy that then said, okay. Look. There is actually enough interest already in the in the community because of the of the activity that that was there in the in the mailing list is that we actually formed it even ahead of of the following IETF. And we had the first in the meeting in in November last year. So this is when this draft that Thibault mentioned was adopted kind of officially by the working group. And in fact, since then, we are having biweekly calls and where we use GitHub, Matrix, these kind of tools to to keep in touch. So there is a kind of community that where we are developing this this standard. It's also interesting to note what is the impact of this of this standard. In particular, this EOS that I just flashed a moment ago. This is the European Open Science Cloud, which is an initiative at the European level to actually federate different systems, and OCM has been chosen as the foundation of this federation. So this is already in place. It has been even successfully demonstrated one year ago, but a bit less than when it was around November. And here you see a little bit of all the logos of the different so at the same time, different vendors that have implemented this and different institutions that have deployed this. So they've deployed different systems that are able to interconnect and and talk to each other. And among those, we have in in this so called EU node that is kind of the official reference implementation of the EUSC Federation. And in fact, we are now at the level that for the next tender, the European Commission has decided to bring this, like, as a requirement. So this is the official the official specification for the next tender of of a a node, what they call a node. And part of it is that it has to follow the OCM standard, which is being standardized with the ETF, etcetera, etcetera. So this is an accept of this of this tender requirement. So, yes, this is a little bit where we are. So, indeed, we were at version five, but then, okay, we we did a few polishing, etcetera, last week. So, eventually, I published the latest version on when was that? On Sunday or just just before coming, in fact. But, okay, those were really refinements. Even though there is one specific addition, which Mika will discuss a bit more in a later presentation, it is about IANA registries to try and make the standard more modular, let's say. And as we stand at the moment, we have actually three drafts. So one is the one that was adopted in the first interim meeting, and then there are two kind of complementary drafts, which eventually, I guess, we're going to adopt. We'll see probably even even today or or in these in these days for specific aspects of the of the standard. I said the mother draft is the one that is already there, and and the others are kind of appendixes. So where are we? So, essentially, during this time from since the working group was was formed, we've been working really on filling the gaps and trying trying to make the specification complete and clear so that implementations can really do something which is interoperable. And in fact, this was not trivial because there are already implementations around. And the parts where the specification was not clear, eventually, happens is that the implementers just just invent. Right? Everybody is creative, especially with software engineering. The easiest to do is, okay. Let me invent something. Right? And then let let me invent the format to do this or that. So this meant that we have to work a little bit on on putting together a test suite that that is testing the different systems and invest into the implementations. In particular, we invested a lot on Nextcloud and Reva / ScienceMesh. Nextcloud because it's deployed at SUNET, and Mikael is representing SUNET here. And Reva / ScienceMesh because it's deployed at CERN, and I represent the Reva / ScienceMesh implementation. So those two, okay, they got a little bit of a of a of a of a lead advantage, if you if I can say. But still, it was a kind of good reality check that what we are doing goes in the right direction. And I would like to acknowledge the sovereign tech agency that one year ago at I IETF approached us and funded part of this activity for for one year. So this project is about to to finish now. And those in particular, Maddy that is a collaborator and is also a holder of this specification. I hope he would be able to join, but being based in Iran, it's not that easy to to get the network proper and running. So we'll see if if he's online. But for sure, we'll follow the the recording. And here so this list is a little bit I tried to compile a little bit of all the different capabilities and and features of the of the specification itself, where at least the good thing is the core components, which are essentially an invitation flow that makes two different systems know about each other and a sharing flow so that then I can share a resource with someone else at a different distribution. Those two and with a discovered endpoint as well, those two are working perfectly well, I would say. But we are we are we we got what we wanted. But then many other items are either in in in in the works or or there is even one that is actually completely broken, and this we will mention later on. So this is still the ongoing the ongoing work, let's say. And so where are we? What do we want to do now? So, essentially, at least my list of priorities, we need to finalize the notifications because this is the red line that you saw there. And this will help also define the life cycle of what we're sharing. So what happens when we exchange this this invitation, but then the user leaves or the collaboration is over? So what do we do with with the resources that have to be life cycled? There is also group management that is that is not well defined yet, and this may come as part of the upcoming projects. We need to do a proper security assessment. We are based a lot on on the Ooutflow, so I'm happy to have Aaron here. And also on the http sig, which is another ETF standard. But we need to really make sure that everything works. And then, often, we can also look into registering the well known discovery endpoint, possibly these days if if I can cross marker. I understand that it should be it should be around. Sometimes that could be and then, okay, towards the last call, but for that, I think we have still quite a few months. We have there is still time for that. One thing that I think is would be interesting is also identifying a way to ship what what we have at the moment is the open API format expect that is more developer friendly, let's say, which could be evolved into the JSON schema, which is quite kind of nice because Elisa is actually leading another working group, and there is a and and this is actually the link to this to this schema in JSON format. I think it makes very much sense to go in that direction, and we need to clean clean it up and make it not redundant, let's say. But then, yes, this is still a bit to to be clarified how to make the full package published in a kind of coherent way. And then, okay, questions open questions like we could approach other vendors. There was a list already proposed some time ago. There's, like, ProtonMail or or others that would be able to implement this. Plus, understand that there is some interest even in doing this at a at a scale that is, like, different systems. Don't necessarily just file a single share single share storage. And I think that's it. Yes. So that's all I have.
[00:16:41] Thibault Cholez: Thank you for the presentation. Any question quick question because we have twenty seconds left. No question? No question from the chat?
[00:16:55] Giuseppe Lo Presti: I guess the questions will come when we start to get into the Yeah. Eat. Agree. Good. On
[00:17:01] Thibault Cholez: that, Mike, I think you you have the next presentation slots. I will put the slides up.
[00:17:08] Mikael Nordfeldth: Does this work?
[00:17:09] Thibault Cholez: So somehow, I cannot figure out how to make it work. So maybe and, otherwise, there's my keyboard.
[00:17:16] Anna Larch: It's in here as a slide clicker. You
[00:17:20] Thibault Cholez: could let see.
[00:17:21] Aaron Parecki: Okay. Yes.
[00:17:26] Mikael Nordfeldth: I'm going to talk a little bit about IANA registries for OCM. So we have been trying to figure out where are the extension points of OCM. So anyone will be able to register their own share types, resource types, protocol, payloads and things of that nature. So we have, yes, like I said, multiple extension points, including notifications. And it should enable bespoke share payloads. So for instance, Mauro told me yesterday that there is what is it, ITIP protocol for sharing calendars, which currently has only one transport, which is email. We could share calendars that way over OCM. And rather than having to go and put it into the specification right now, you could do it in a year's time or two years' time and publish it with a persistent URL somewhere and register it in IANA so other people can use it. So we have seen proprietary single vendor extensions already, which is not I mean, it's not wrong. You can do that. That's fine. But it's not helpful to the community at large, and it's not helpful for open source developers who want to develop their own OCM implementations. So yes, this is the motivation of the registers. So we want to ensure that they are documented in a stable public specification somewhere. And the registration policy that we have chosen is specification required, and that does not mean an RFC. That's another registration policy. It just means that you have to write down in a coherent way in a document what you want to do and publish it in a stable location. Yes. So we are doing that with one registry group with five subregistries in the core Internet draft. So the registry group is OCM parameters, and we have resource type with the initial content file and folder. We have OCM protocols, so they have the send and receive roles. So the initial entries are webDAV, webDAV receive, webapp, webapp receive, SSH and SSH receive. We have the OCM share types. So that's user and group from the core specification and federation from the OCM MLS document. And then we have the OCM share payloads, which binds the resource type, share type and protocol to a specification of a payload. And then we have the OCM notification types. So in OCM MLS, we use notifications to carry the application messages for MLS. So we need notification types for that. So this is how the share payload registry would look with taking into consideration the known protocols that we have. And this is the notification type registry. So this will most probably change when we decide on a, let's say, interoperable format for notifications because we have now several proprietary implementations, which are not interoperable. So pinning down notifications will be a very important work going forward. Yes. And then we are also registering other things from other specifications. So one is the dot well known URI, which we have in the specification. Another is JS contact type of an OCM address and some things related to the OCM address. And then an MLS exporter label. So yes, I think that was it, what I had to say about that. Does somebody have any quick questions about the registries? No. I have also asked IANA to give us another early review. They looked at the things that we have for the other IANA registrations, but our own registries are not looked at yet. But they promised to take a look at that, too. So that's really, really helpful. Yes.
[00:22:33] David Nüscheler: Thanks.
[00:22:41] Thibault Cholez: Great. No question? Doesn't think there's any question. I think, Mikael, you're also the next presentation. So, Mikael, you know yeah. So so so yep. You can come back. Let me just switch to slides. Yes.
[00:23:12] Mikael Nordfeldth: So we have done a lot of work to make web apps, being able to share web apps during the first six months of this year. So we now have successfully demonstrated that it's possible to share Jupyter notebooks from Nextcloud to Reva / ScienceMesh and that in Reva / ScienceMesh, they can open the share and look at it in the JupyterHub installation that I have. So you don't have to have any kind of infrastructure yourself. You just have to have an OCM server, and then you can use the resources of my server to do compute. So that's really nice, and we learned a lot of things doing this. So we have specified web apps much nicer than we had before. And we have come up with a second protocol, which we call OCM integration protocol. So the idea is that the receiving server does not need to know anything about this protocol. It only needs to know about the core OCM protocol. But if you want to develop an open source implementation that can be reused by several vendors, then you can use this protocol on the protocol server side. So I have developed an implementation for JupyterHub. So it is a JupyterHub service and authenticator, which uses this protocol. And there are three flavors of this integration protocol that you can use. And the idea is to decouple the OCM server from handling all of the transport protocols and all of the other things. So you should, in principle, be able to have a very thin OCM server that sits on top of an off the shelf web dev server, an SSH server, a JupyterHub server, hedge doc, whatever you want. Yes. Yes. And this enables protocol implementations to be reused, and you can do an implementation for a specific piece of software once, and it can run everywhere. And it only affects those who want or need interoperability and reusability. You are free to do whatever you want on the sending side. The receiving side doesn't need to know anything of this. Yes. And we have three integration modes. So the first one is provisioned. So that's the one that I'm using for JupyterHub. It defines some API endpoints at the protocol server. So before I send the share, I send a provisioning request to the JupyterHub notebook, letting it know that the JupyterHub server, letting it know that there will be a share coming in. It has these parameters. And there's also so there's a coupling between the protocol server and the OCM server, so they know to trust each other. And then the request for the web app comes in, and you can take a look at JWT, which comes with an open request, let's say, and then you can bind the provisioning to the current session that you have. And then there's a self contained mode, which just use the JWT. So if you the only thing that you care about is maybe the username or some other small details, then you can just take take a look at the JWT, make sure that the signature is correct and belongs to the server that you are bound to, and then you can do whatever you need. And then there's also an introspected mode where you can talk to an introspection endpoint and get the share information that you need back. So this is basically what you get is the share minus the shared secret. So all of the information that you need is in the share, so we need to be able to send that to the protocol server. Yes. We have some for what yes, this is for web app sharing. So we have web app and web app receive in the discovery document. We have targets, which is blank and iframe. So blank means that you can either do a redirect or open a second window, basically. And iframe is you can embed the thing into yours. So for Nextcloud, we have the integration JupyterHub app, which is able to send shares. And then we have developed a new app, which is OCM Web App Receive, which can take any kind of web app and open it as an iframe or do a full page redirect or target top. So and there, we have added some semantics for the web app protocol. So we can have an app icon in hint, app name, the media types that the share supports. And we are using the token exchange for getting the JWT and all of these things. And we know like the first implementation of web app, which was done several years ago, had the share token in a get request parameter. And now we do a post with the access token into either an iframe or, yes, an endpoint at the receiving server. Yes. That was it about web app sharing and OCM IP. So I think the remaining thing to do about this is we should adopt the OCM IP draft if everyone is happy with having that. So that's for web app. And at least now we we have several implementations and know that the semantics work, we can do interesting things with it.
[00:30:30] Anna Larch: Go for that one.
[00:30:33] Thibault Cholez: Yes. So design is setting up a pool so we can have, like, a show of hand, at least in the room. But probably also, like, have that forwarded in case to the mailing list, I guess, for, like Yeah. Like, after the meeting to, like, allow for, like, time and remote participation. But yeah. Let's do a show of hand passing in the room. So for those of you who are new to the IETF, you should have on the on-site tool received a notification for a show of hand, and you can answer yes, no, or no opinion.
[00:31:20] Mikael Nordfeldth: Show.
[00:31:27] David Nüscheler: Yes.
[00:31:33] Thibault Cholez: So, yes, on mobile, the icon is at the top right, should be, and you should have a show of hands and be able to participate on the show of hands. Okay. I'll leave it still for a couple of seconds, but the at least preliminary, like, movement from the room seem to be, like, an approval for an adoption. So great. So, like, if you'd like, that's a like, that's a good like, a good outcome, we'll take that to the mailing list shortly after. So pre not this week, just like in term of expectation. But, like, shortly after, we'll take it to the mailing list, and I I think that's where we'll conduct it, yeah, the the actual adoption call. Great.
[00:32:39] Mikael Nordfeldth: Good. Do I have a another presentation now? Or
[00:32:43] Thibault Cholez: I do see the next presentation is notification. Yes. Good. It is. You will have us a presentation down the line,
[00:32:54] Giuseppe Lo Presti: Then at least we rotate a bit. And if this works, that's better so that they can face the mic.
[00:32:59] Thibault Cholez: It will be much better, for us in remote participants.
[00:33:02] Giuseppe Lo Presti: On the side. Yeah.
[00:33:03] Thibault Cholez: Yeah. Exactly.
[00:33:05] Giuseppe Lo Presti: That's totally fine.
[00:33:09] Thibault Cholez: Great. And so we have the notification updates.
[00:33:12] Giuseppe Lo Presti: Yep. Okay. So here, this is a bit more into into the the details of so let's see if that yes. That works. So we discussed already a little bit this at the last at the last interim meeting. And so the context here is the the notification is a is a kind of broad term to do many things. And it's it's all about informing remote servers so that they can keep in sync depending on some events. Typical case is there is a change in permissions, for example, on a on a on a existing share or other kind of application specific changes. Niko just mentioned that indeed there have been already implementations of applications like Nextcloud Talk is is distributed, they use notifications to notify to keep in sync the different servers. Now the challenge, if you like, is the fact that what we have in the spec at the moment, what what we inherited from years ago is actually a very, very simple format, which is largely unspecified. And there is a list of types, which we have here, but there's not really much else about how to structure things. And so this causes different problems, let's say. So first thing is at this point, we need to define a kind of minimal common payload, and then we use the registry that Mikael presented to go for custom notifications. So everyone can implement their own application. That's fine. But then at least interoperability should be preserved, let's say. Then also, notifications, the way they work, they are kind of sessionless. So the fact that, for example, in NextLow, there is this shared secret is sent over. I believe we don't need that, and and we should be able to do it without. I mean, the the the less we've we involve secrets, the better anyway. And on this at the same time, what we want is to enforce HTTP secret so that we can validate. I mean, the two servers can can know about each other in a trustworthy trustworthy way. Still, we need some kind of unique identifier. So then we need to do something about that. So the idea or my idea at least would be to have a a fully specified payload for what concerns the web part because this is the the part that is already very much used, and then give the structure of other possible other possible notifications. So the general format that I'm proposing, not really to vote, but, okay, to discuss, and then eventually, we can get some kind of rough consensus here along the mailing list, is to actually drop the provider ID from the general part because there are notifications where this provider ID means pretty much nothing. And we actually embed it in whichever terminology is appropriate into the payload. But then the payload itself, so the part of the the notification part, structure it in in two levels so that then anything that is really custom for a specific protocol for which or or share type or resource or whatever we are talking about gets into its own objects. So let's say we keep that object completely free form. So it's really just an object, essentially. Whereas the rest, the the envelope is fixed. So this also helps parsing and, I mean, interoperability in general. So this is little bit the idea. Now how would that look like? So if we look into the classic one that has been used and has been implemented already by by the different implementers, this would be the way to notify a change of permission, for example. So you see that I'm dropping the shared secret. I'm including this what the provider ID that would be the identifier of the of the resource on the on the remote side inside the protocol because this is specific to what we're talking about. So that the external party is actually very generic. I would say we can still keep a message, kind of user friendly message for for UI purposes or for for these kind of things. But indeed, anything that is specific to what we are talking about stays into into an in an embedded object instead of free form in this notification block, which indeed at the moment is completely free form. A different one is what the Nextcloud implemented for for their talk system. So there, what I'm suggesting to Nextcloud, the people that are, I know, they are also online is to actually change their protocol and then create a challenge, of course, would be to to make it backward compatible to their own format, but to have something which is, again, interoperable. So that then you have this talk part where you put whatever, including the room ID. No need to put any placeholder of a shared secret because in that case, it doesn't even apply. And then the external part remains, again, generic so so that everyone can pass it. And then a new one that, at the moment, no one has implemented is this notification about if a user drops out. So the idea there would be we can exchange it between different users in different seasons. So I know Mika. We exchange the token, and then we can share data, resources, applications, whatever. At some point, we stop our collaboration, or I move I move on to a different company or whatever. So this link should be stopped because there's no reason to keep it to keep it alive. So in that case, I remove the invitation, and I notify my server notifies the remote server that this user has been removed. So it doesn't it's not anymore a trusted contact. And so this would be a notification to be sent over over the wire. And similarly for groups, so this would be also something that we would need to look to look after. And finally, there is also okay. This is a little bit of an anticipation of what will come next. So we have notifications for the message via security to do federations of groups spanning multiple institutions. So there, this is still in the in the process of being of being written. So to some extent, we have more freedom because because we can do whatever we want there. Nobody has implemented anything. So I would propose also for consistency to do this kind of structuring where we have the source type to say what we are talking about, and then everything that is specific stays into a kind of block object within the within the payload. So this is pretty much the different examples of what what is coming now. So I have a few proposals. One is to actually completely drop the this first one just because looking at the code base, the only one, at at least to my knowledge, the only one that implements it is Nextcloud, but implementation is return not not implemented. So it's actually a placeholder. It's not really used. The rest is used, and we should retain it. And this is where we do the life cycling of the of the sharing and also this extra permission change. There is also this share undo, which meanwhile, I looked a little bit more in details. There, the question is is there is an assumption in Nextcloud that is you can reshare, and then it's a kind of chain. So I share to MiKi, MiKi shares to someone else, and then someone else can access through MiKi to my data. But I'm not sure this is what we want after all. Like, do we really want to have access that goes through different servers? We want to go straight. And I want to know that my data is being also shared to a different institution compared to the original share that was that was granted in the first place. So this is still to be a little bit discussed. And let me just finish, and then I I give you the word. Yes. So then okay. Retaining just to remove this is this is obvious. There is also even a wider proposal because we introduced recently a new endpoint that this could be transferred into a notification just to simplify the spec. And that's it. So those are the questions I have. So is this good enough? Is it generic enough to allow interoperability? And in particular, are vendors ready to invest in their implementation because we are breaking their implementations, all of them. No one is expecting this forward. So in a way, it's it's a kind of we have a fair share of things to be implemented or engineered to to make things work properly. And indeed, there there is already a question from David. But but then go to the mic so that it's it's recorded.
[00:42:05] David Nüscheler: Yeah. Thank thank you very much. I I just want to highlight that we have to be careful about the permission when it comes to that part, especially when it comes to resharing. We want to or we must ensure that, for instance, we either can limit the resharing entirely that we say, okay. That's not not allowed, or it needs also be possible to to ensure that the data is not being reshared to a certain jurisdiction or outside a certain certain jurisdiction. So it comes to that particular piece, I'm very, very curious how we are going to secure that, for instance, it's not leaving, I don't know, or it's not entering Five Eyes, for instance. Right?
[00:42:56] Speaker 6: Can you
[00:42:56] Anna Larch: state your name by the way?
[00:42:57] David Nüscheler: Oh, yeah. David. On cloud, Kiteworks.
[00:43:00] Anna Larch: Thank you.
[00:43:09] Mikael Nordfeldth: Yes. Mikael Noudin. So one thing that we could do to help backwards compatibility and transitioning to the new format is to add a version to the envelope. So we have version one. And if that's present, then you know that it's a new type of the other thing that you can do is to check if there's a provider ID. And if it's not there, then it's the new version. But I don't know if that's a good idea as well.
[00:43:40] Giuseppe Lo Presti: I did make sense. I mean, I'm happy also to help the implementers, of course. This is part of the of the work we are trying to do together. So yep, there is one more. Yes. But I can I think
[00:43:58] Thibault Cholez: Yes? Also, one thing for, like, on when you're on-site, you can, like, raise your hand directly on the on-site tool for the queue, but sorry.
[00:44:06] Anna Larch: Hi. Yeah. So about the resharing, what is the reason for not wanting the reshare? Is it because of controllable knowledge, basically, knowing who I have re who or who reshared my share with somebody else?
[00:44:22] Giuseppe Lo Presti: I think there is I mean, it's not a matter of restricting it. It's it's something that the owner of the original owner of the data should know. And then it's up to him or her to decide, okay. I'm resharing. Plus, I think it would make sense that even just for efficiency reasons, that the access is done directly, not through another third party service or fourth party or whatever, like, chaining the access.
[00:44:45] Anna Larch: Okay. So you would convert the reshare to a direct share
[00:44:49] Giuseppe Lo Presti: and then Okay. Yes. And so that then the owner knows, and then the access is done directly.
[00:44:57] Thibault Cholez: Thank you.
[00:45:00] Giuseppe Lo Presti: Okay. Thank you.
[00:45:02] Thibault Cholez: On that, moving to the next presentation, which is about, like, federated group of MLS, and we got a couple of hints toward them. So
[00:45:15] Mikael Nordfeldth: Yes. So there's been two things in the specification, which has been very much underspecified. One is group sharing. So sharing to a group on a server, what does that mean? But that's a simpler case, let's say. You don't need to coordinate across multiple servers. And I think we can flesh that out in the core draft. But federated groups, how do you do that in a distributed way that doesn't require some central infrastructure to be able to do. And MLS, message layer security, is a thing that we can use to define the share type of federation spanning multiple OCM servers. So we propose that we can use it here as a group management layer, so not for sending chat messages, but only for key management and group membership via the Ratchet three extension. So that means that every server who has a member of the group has a full list of all of the other members on all of the other servers all the time. And it also gives us the ability to securely send encryption keys. So you can send an encrypted share to someone. So you send a regular share, but it has an optional encryption part, which allows you to use a wrapped file key to decrypt the actual data. And in this proposal, the Groove lifecycle is independent of share lifecycle. So you imagine that you have your OCM server. You go in there to a web interface, and you click create federated group. You become the first admin of the group, and then you can invite other members on different servers using their OCM address to become a member of this group. So MLS has a couple of defined server types. So one is the delivery service. So in this proposal, the group owner server is the sole committer. So the group owner server is the one where the first admin is. So when you create the group, your you become the group admin and your server becomes the group owner server. You have the ability to promote other users to admins, and they get appended to the list of admins. And if you leave the group, the next person in the admin list becomes the first admin, and their server gets promoted to the delivery service. And each user's home server is the authentication service, and they will provide key packages at a specific endpoint for you. And we will add some extra notification types to carry the MLS messages, the welcome message, the proposal commit. And then the application message is used only for sending file keys. So you are not using the group key in MLS directly to decrypt or encrypt files, you'll use a wrapped key. And I can tell you a little bit more about this soon. Yes. And then there are two different modes. So one is the re encryption mode and the other is the key reuse mode. So let's say that member of the group gets removed. The recommended way of doing it is to take the encrypted file and re encrypt it using another key and then distribute that key to the group using an application message. But if you are part of a trusted federation and the it's impractical to re encrypt files at a high pace, then you can choose to use the key reuse mode, in which case you will only send the file key again. So at any time, the members of the group can use the current file key to decrypt the file, and they don't have to care whether you have created a new key or not and decrypt or reencrypted it. So we have a new ID draft for this, OCM MLS, which I also hope that we can adopt. That contains IANA registrations for all of the file MLS notification types. It adds a new also notification type MLS rejoin for state recovery. So if your home server has been down and missed an MLS epoch, then you should be able to rejoin the group, and it spells out the semantics of how to do that. And it also has the group owner server failover mechanism specified. So you don't need to do anything special to promote to make the server outlive your own server. And it splits out federation from the old spec. I think we had like, two rows in the old spec that said federation and nothing more of how that was supposed to work or so we removed that and moved all of this into the new companion document. Yes. So that's about federated groups using MLS. Do you have any questions about this?
[00:52:01] Speaker 6: One question. So the MIMI working group has worked on federation of MLS. I'm curious if you have done any cross comparison with those architectures or if it was overkill. Or
[00:52:11] Mikael Nordfeldth: No. I haven't really. I'm I'm trying to follow the MIMI group, but it's not very active in the mailing list. So I haven't got a lot of input lately.
[00:52:20] Thibault Cholez: But They're kinda in hybrid mode. Yeah. Hibernation mode.
[00:52:25] Giuseppe Lo Presti: Yeah.
[00:52:28] Mikael Nordfeldth: So yeah.
[00:52:33] Thibault Cholez: Does Yeah. And so you state your name.
[00:52:35] Ben: My name is Ben. Does this consider any given group participant having multiple devices, like, each with its own key?
[00:52:43] Mikael Nordfeldth: Yes. That's right. So a lot of the time, the OCM server is the client. So a lot of people interact with a web interface, which is tightly coupled to the OCM server. So in that case, the OCM the MLS client would be the OCM server holding key material for the user. But if you have a native client for the user, then it's recommended to let that client generate key material for the OCM server, and the OCM server will only present them at the key package endpoint. So a user can have multiple leaf nodes for different devices and can push a key material to the OCM server, which only acts as a relay at that time.
[00:53:44] Ben: Is it in the MLS Ratchet Tree? If there's multiple devices for a user and that are distinct, can the other leaves in the Ratchet tree tell which leaves are part of the same user? Like, do they have a extension in the Ratchet tree that says which user ID they are or email address or something?
[00:54:05] Mikael Nordfeldth: A good question. You should read the draft and give me notes. K. I sent an email to the MLS working group today asking for reviews and going through it. So I've done my best to make it look work properly, but I think that there are definitely gaps like this, which needs to be addressed. So I'm trying to reach out to different MLS people to read the draft and make sure it makes sense.
[00:54:34] Speaker 6: Just the last question. There's a couple ways of doing that. There's a virtual client's extension for MLS Mhmm. Which hides the sub elements. Or, of course, you can have one member per element if you want to be visible.
[00:54:46] Mikael Nordfeldth: Mhmm. Okay. Good. I will incorporate incorporate that.
[00:55:00] Thibault Cholez: Okay. Seems there are no other question. So we'll move into the last like, one of the last last thought we have for, like, implementers.
[00:55:10] Mikael Nordfeldth: Can we have a poll for adoption of this document too? Or can we just take it to the list?
[00:55:19] Thibault Cholez: Do you think it's ready for having a
[00:55:21] Mikael Nordfeldth: Yeah. I think it needs work still, but I think the working group can adopt it and engage with it. It's pretty I tried to flesh it out as much as as possible, and I think we can work within the ITF to fix any remaining issues. Okay.
[00:55:39] Thibault Cholez: Maybe we can have a pool for interest and similar to, like, before, we would put that on the mailing list for for for having that option. Thank you, Lisa, for for for for actually, like, speed running through through through the port.
[00:56:06] Mikael Nordfeldth: While we wait for that, I know that we have at least one presentation from Guido, who is online. And then I know Anna is here and wants to say a couple of things from Nextcloud. I don't know if you have any slides.
[00:56:19] Thibault Cholez: Yeah. We we have you see the slide and yeah. Both presentations are lined up right after this one.
[00:56:24] Giuseppe Lo Presti: Good.
[00:56:24] Thibault Cholez: So thank you. Yeah. The show of hand should be up. So, again, if you're on the phone with the on-site tool, it's at the top right corner. Show of hand, and you should be able to participate. Good. Thanks. You're welcome. Thank you.
[00:56:44] Anna Larch: And everybody already figured out the voting, so
[00:56:47] Thibault Cholez: Yeah. It's my trust. So we see numbers go up. And even if you don't have an opinion, you can state that you have no opinion by showing head. Good. I mean, there there seem to be, like, quite some momentum. So I think, like, as before, we, like, put that to the list. Again, not this week, but, like like, probably, like, on next week. And thank you for the presentation, again, the work I'll work on this one. On that, we're moving to, like like, the the the last large slot that we have for implementers. And we will start with a presentation from Guido Guido. Sorry for Guido. He he's online with us.
[00:58:06] Giuseppe Lo Presti: Sorry for the mispronunciation.
[00:58:08] Guido Aben: No. That's quite alright. This is a case of you don't actually transfer the traits of a person if you give them their name. So you can call a Northern European boy Guido, but he's not gonna be a beautiful Italian. It does just doesn't work. Sorry, parents. Hi. Am I audible?
[00:58:29] Thibault Cholez: Yes. It's okay. And you can pardon my French on this one, so you can go.
[00:58:35] Guido Aben: Off to a good start. Hi. So, as one of the, as one of the, early adopter, implementers. So I represent the, the file center project, which for people inside of r and e is probably reasonably well known. For people outside of r and e, I'm just gonna make a grandiose claim. We are the de facto, ad hoc file transferings solution for the uninitiated. Know there's certain people in the room who have far more refined file transfer solutions, but they are for the initiated. Superficially, the tool resembles WeTransfer, if you're familiar with that. It's been in place for fifteen plus years. And as of recently, as of the whole sovereignty drive, as of people beginning to move files into sovereign cloud systems, we've been getting requests to do file transfers not from a an end user's laptop or personal device to a recipient's personal device, but from files in cloud holdings. But, of course, if you're trying to drive the whole thing through a browser, that's actually quite complex under the hood. Do I move the slides myself?
[00:59:40] Thibault Cholez: Yes. You should have control, but happy to do it.
[00:59:42] Guido Aben: Yeah. Know. This is just my very first time in this, very rich ecosystem, so I didn't didn't want to press buttons that were gonna destroy things. So this is what people wanted to do. Right? The thing in the top left corner is a a cloud system. So move files into this web app from a a third party cloud system and then deposit them into a third party cloud system as well. And, of course, if you look at this from the moon, then the first thing you're gonna wanna do is make sure that the first protocol you implement actually gives you a reasonable chance of tapping into a large catchment area. You don't wanna have 30 different plug ins to tap into 30 different, bespoke and exotic ecosystems out there. So as of fairly recently, if you, should you decide to do this over OCN, then there is now a reasonable holding, a reasonably large holding of personal data in own cloud, open cloud, Nextcloud, etcetera, type systems. So that drove our our willingness, our eagerness to use to to to look into OCM to tap into these sorts of systems. The second realization was that we're we're probably not going to be requesting files from the same user that we're going to be depositing them into. So a second thing that we need to do is and I move files like this. Right? Yes. So we need to separate the the two control planes. So the uploading part will have an, an uploading user tapping tapping details, go through the invitation flow to get files in from the cloud holding. Then there's movement across potentially large distances, geographic distances, latency. Then a deposit workflow gets triggered whereby the recipient user gets to punch in things initially, actually physically, and then in late transmissions, you can you can tap from, often used transmissions and just do the whole thing in an automated sense. And then the deposit happens in a a cloud system of the recipient user's preferences. And as soon as you get to automate these sorts of things, obviously, you can then do deposits into trusted end systems like research ecosystems, compute machinery with the workflow attached, etcetera. So, that makes us really interested in seeing what happens if we, implement an OCM implementation into the file sender machinery. Of course, Mikaela being a collaborator and a colleague of mine, he reassures me that we'll be able to just use the libraries that are being generated so that lowers our cost. But there were other requirements as I've listed here. I won't won't go through all of them directly, but that make OCM really suitable, it seems, as opposed to a a number of more bespoke, more sort of command line driven, more client driven implementations of file matching with file system matching that are out there that we couldn't have used but would have, we think, painted ourselves into a corner. So this work has actually already been funded. We've got the next year to start doing this implementation and we'll be feeding back into this working group as things progress. But that will make us a a bridging layer between different implementations of OCM. So you could potentially have a workflow with somebody who uploads from an own cloud server and eventually deposits into an ex cloud server, the whole thing needs to work. And
[01:03:22] Thibault Cholez: You have one question from the chat?
[01:03:26] Guido Aben: In the chat.
[01:03:27] Thibault Cholez: Yep. Is this the regular OCM? No, actually, sorry. It not a question related. Do you have any question from the room regarding the implementation and consideration for the requirements? Even just observation.
[01:03:51] Guido Aben: Oh, booing.
[01:03:56] Thibault Cholez: Good. Well, thank you for
[01:03:59] Guido Aben: I was trying I was trying to trigger the certain people into booing, but no. Hey, Giuseppe. Good to see you. Good to see you.
[01:04:10] Thibault Cholez: Good. Well, thank you. And I'll send them this to the next presentation that we have. And I see it's Anna. Anna has the next presentation. We'll be putting the slides up. Can you see a slide on your side? Because I got it uploaded this morning. So maybe I will
[01:04:50] Anna Larch: Still being shared.
[01:04:57] Thibault Cholez: Okay. I will just
[01:04:59] Anna Larch: And your comments.
[01:05:00] Thibault Cholez: Say just one moment. The time we, like, get the slide back and and and then, like yeah. Because I'm not sure the tool has been able to pick them given they've been uploaded this morning. So I will just upload them manually now. Okay.
[01:05:21] Giuseppe Lo Presti: So
[01:05:25] Thibault Cholez: we're getting that.
[01:05:31] Anna Larch: From do we have a way to share things? Right?
[01:05:33] Thibault Cholez: So I'm able to, like, share the slide, which is, like, already good. And now, like okay. I have the slide imported in the tool, and we should be able to get them here. Okay. Perfect. Fantastic. Thank you.
[01:05:47] Anna Larch: Thank you very much. Hi. My name is Anna. I'm gonna talk to you today about open Cloudmesh in Nextcloud, where we are, who built it, and where we're headed. This is me. That was a while ago. Software engineer, developer relations, and I'm also part of the security team at Nextcloud. Yep. Quickly, where OCM lives in Nextcloud server for anyone who wants to maybe contribute. Votis was built by the community. Our lovely Mikaely, who has done a lot of work and fantastic work on this, but more on that later, and how we could align further with the spec and some questions for you as the audience and writers and implementers and creative minds behind OCM. So we've got the key entry points. We already use the well known OCM, which falls back to OCM provider. Yeah. This is in the OCM controller in the core, so pretty much everything you see on the slides here is in core. The only implementation that is not in core is an open PR where we're moving front end parts to a different app that is not shipped in core. So Nextcloud comes with its own support. We've got the client's end discovery. We've got the wire API, the token exchange. Then we've got resource providers and interfaces. So, some of it is in federated file sharing with the cloud federation provider for files. We've got the calendar shares, which is something that I think deserves a bit of, an analysis, but later. And here we have a list of our interfaces. So if you ever wanna implement, any custom implementation, you're in your own app, you can implement the interface itself. It will give you basically a contract what methods you need to have. As I've said, cloud federation API, federated file sharing, and data are all shipped. The discovery lives in the core itself, which isn't even an app. That's really just the core of Nextcloud. And as I've mentioned, contacts, it's not a shipped app, but without contact, some of the parts of the spec we've implemented doesn't really make sense. The front end part doesn't make sense if you can't present the information you receive from somebody else that has shared with you or whom you've invited to share. So build wise, we've had 30 plus individual contributions. We've got commentators and app teams who have contributors, but Mikael is currently the one that is really driving the effort with 19 PRs against the server since '24, which is really cool. Thank you for that, Mikael. Amazing. We've got 14 merged. We've got two open, and we've got Maxence who I think you've been talking to a lot about this as well. He's very interested. We also have a open group within our own instance, a chat. So if you're ever interested in how we work and what we are talking about in Nextcloud, feel free to join. So, yeah, thank you. This only works with Nextcloud because a lot of people contributed and spent their time and brains on this. So yeah. Further aligning with the spec. So the drafts only list files and folders as far as I know. I'm not an expert here, so fine. Correct me if I'm wrong on this. But calendar contact and users appear in the YAML files that I found on GitHub. So there is a drift between this. We've got files in productions already. Calendar is implemented but not advertised, but since it's not a official RFC resource, I'm kind of torn between what to do here, but I've got those questions also noted down. So we've got the low local OCM discovery event, which is new, and the resource type register event, which has been deprecated but not removed yet. So you could, if you wanna use it, still use it, but it's not really recommended. So we could advertise the calendar. It's a matter of wiring it up. The question is, could other implementations handle this? Is it a good idea? Is it not? This is also why it hasn't been done yet, why it's there but not exposed. So, yeah, this is my question. Cal and Cartov collections are basically files. You've got your collection, which only has one level, so there are no subfolders, no nothing, and it always contains either ICS or, card data. And, yeah, you could treat them as files, obviously, but you could also say, okay. We could do a protocol for this since CALDAF and CARDDAF are well established. They've been there since the seventies. The RFCs are, yeah, have been there for a long time. So it is probably a question of do we want a clean slate because Calendar, I know from experience, has its own, quirks and stuff, and Apple does it this way, and Microsoft does it that way, and Google doesn't even use Kaldaf but pretends to. So it's hard. But, of course, it would guarantee interoperability almost immediately. On the other hand, yeah, a new resource type could also mean a clearly defined well written spec that could support things that are now in x properties really often, calendar colors. That's something that Apple implemented, but, yeah, it's basically now standard, stuff like that. Yeah. Then we only support webDAF for the moment. That is also something where I'm wondering if there is even a need for SSH and if the other protocol types should be supported, if we should think about implementing them. Is there somebody who are already has? Is there experience with this? It's something very interesting to think about. So if anyone has input on this, I'm more than happy to talk after. Yeah. And with the request endpoint is not yet implemented, so open a PR, please, or not. Thank you. And then the, discovery document next steps, we don't have a criteria field yet, and we could broaden our capability advise advertisement. So we've got notifications. We've got shares. We've got the exchange token. We could do the multifactor authentication enforcement invites. Yeah. We could extend the has invite accepted capability with other methods to basically provide this sort of capability advertisement. Notifications, we've already heard from notifications, so I found this really interesting. The user removed, I didn't really find in a spec either. I think it was also just in the YAML file. We offer pretty much everything. We share change permission experimental, of course. If we change this with the notifications, with the shared secrets, it's from Nextcloud side, it's gonna be a bit hard because we use the shared secret for a lot of other back end dependencies as well. For talk, especially example, we have a high performance back end which uses the shared secret to authenticate the user, so that would need a proper rethink on a very basic level. On the other hand, a shared secret is symmetrical and not, you know, a really long term secure way to authenticate your users. So that is something that may even find common ground with the talk developers, which I also used to be. So I have an in if you want input. Okay. Then we also have the self reported version, which differs from from the API version. So the self reported version is one one two. We could, Mikay, if you're ever in the mood and have some time, we could maybe think about how we could do that. Also, I'm not sure what the benefits and drawbacks are of still having the API on an older version. If there is any effect, if there are any clients who really already rely on this, yes. And then we've got some PRs in progress. There is the invite accepted capability and implementation. That is what I meant with the UX. Doesn't make a lot of sense if you don't have the contacts app. So we moved pretty much everything that has to do with the UX parts of accepting or sending an invitation into the contacts app, which was done by Anton. I think you also mentioned Maddy. I'm not sure if it's the same Maddy. I assume so. He was also in the calls. A lovely guy. Unfortunately, he had really bad Internet connection. So yeah. Yeah. Yeah. Yeah. Exactly. Yeah. So shout out to Marty if he ever watches this, if he gets a chance. It was nice having you there. Anton, same for you. So, yeah, they've done great work here. And the contact PR for the front end is still open, but we're getting there next week. It's probably when we will get this merged after our feature freeze. Yes. Yeah. Where we'd love input is what I've already kinda mentioned, the resource type versus protocol question might be something to think about because I can think of quite a few different resource types, but I don't know if there are equivalents of protocols for these resource types. Yeah. The active demand for non web dev protocols, the retiring the one zero propose one string from the API. And, yeah, if you wanna address this or just leave a comment on a PR or whatever, I'm more than happy to have for you. We're on GitHub. So yep. And that's everything. Thank you very much. Are there any questions? Is on the queue.
[01:15:23] Mikael Nordfeldth: Yes. So for contacts and calendar, I think it would make sense to write down a specification for those outside of the IETF and register it in the IANA registry to make sure that that process works as expected. So that would be a nice exercise, I think. For the request for share, I'm working on an app. So the state of the Nextcloud core is now such a way that you can implement different kinds of OCM in an app without having to touch the core, which is very nice. And web app sharing works in, integration Jupiter hub app that we have. And we also, developed an OCM web app received app, which is able to accept shares. So this already works in Excellent.
[01:16:14] Anna Larch: Excellent. Choice.
[01:16:15] Mikael Nordfeldth: And I also have a PR, I think, which makes it possible to disable the wrong API version and make a discovery spec compliant. But the idea that I had was that you could do it from an app, and I don't know if we want to add a configuration toggle for it. Because Nextcloud before '28 relies on the API version string. But once that doesn't need to be supported anymore, I think it's safe to to go to 1.4 or whatever.
[01:16:54] Anna Larch: Okay. Thank you very much for that information. Any other questions?
[01:17:02] Giuseppe Lo Presti: I would have a few, but
[01:17:03] Anna Larch: Let's talk. So so so Alright.
[01:17:06] Giuseppe Lo Presti: So I would love to hear from
[01:17:08] Guido Aben: the panel. Okay.
[01:17:10] Anna Larch: Okay? Thank you very much.
[01:17:12] Thibault Cholez: For the presentation. It was very insightful. On that. We're moving to, like, the discussion time, which is, like, the next fifteen minutes toward the end of the meeting. So if I I think, Aaron, you, like, mentioned you had a couple of of points that you wanted to raise. So I'll let you kick off the discussion.
[01:17:33] Aaron Parecki: Yeah. Hi, Aaron Paraki. I'm I'm most often active in the OAuth working group, so that's kind of the background I'm coming from with this. I'm happy to hash out some of the details of this on the on the list, which might be easier. But at a high level, one of the things that wasn't clear from reading the draft of the the the core what's it called? The core one that is that's adopted. I
[01:17:59] Thibault Cholez: think it's just called Open Clown Mesh.
[01:18:01] Guido Aben: Yeah. When
[01:18:04] Aaron Parecki: you're doing the sharing across instances, is the intent that it's happening in the context of a particular user, like this user is sharing a file with this other user and they need to access the file as that user, or is it more like it's server to server where it's like, I'm gonna share this file and any bill anybody on that server can can access it. That was not clear from the draft. Can you clarify the intent?
[01:18:35] Thibault Cholez: Mikael, if you want to transfer, feel free to. It's good to meet.
[01:18:38] Mikael Nordfeldth: Yeah. So you have the possibility to share with a single user with a group on a server and now federated group across several servers. And so it's in implementation dependent on like, if you more or less impersonate a user and access like that user or if it's just token based or how how it works with the access rules and ACLs and things like that.
[01:19:10] Aaron Parecki: I guess so the the reason I ask is I depending on the goal there, that's gonna have implications of whether you want to have very specific token, like, tokens that are used to fetch files remotely or whether it's more like you let the every instance handle the ACL list itself where you're doing more, like, just server identity across the domains. And that feels like something that, like, you really wanna get right at the beginning because it's kinda it's hard to to change later or hard to you're just you end up having to just trust things that in a way that might be awkward to to extend to other users later. So, yeah, I guess if there's if the if if the goal is that a server is fetching a file on behalf of a particular user, then you really wanna make sure you're doing things more aligned with the OAuth token model versus if you're doing, like, server to server federation, you can actually get away with really not using OAuth at all and just doing things like HTTP signatures to prove server identity across domains. So I feel like there's some work there to straighten that out because it's not very clean in the current the current model.
[01:20:34] Giuseppe Lo Presti: I can't believe that something is up again. Oops. There's the thing is, in fact, I agree. It's not completely clear. And, actually, very recently, I was going through this again. And one thing that we assumed so far, but we just assumed, is that when I invite Mikael and we share this token, then it's really a way to share between ourselves and nobody else like, no one else in my organization can know the fact that I know Mikael and we can do sharing. But in principle, depending on the context, it could be also it could also make sense that we have this so that then it's really like a server to server. They they do whatever authentication between themselves. But then every user or a large fraction of users from my organization can know the fact that we did we have this exchange, and then I can share with a user or a group on the remote system. So this can be user to user, group to group, you know, any kind of combination.
[01:21:33] Mikael Nordfeldth: I can I can say that for sharing over SSH, for instance, we don't have the shared secret? And also you create the share without the shared secret. And then in the response, we get the public key back, and that is used to guide access. So it depends a little bit on the protocol. But I think for webDAV specifically, which is the common ground for everyone, I think we need some kind of token to do bearer auth for access no matter what because we want to be able to reuse standard web dev server implementations.
[01:22:16] Aaron Parecki: Okay. Yeah. Then I guess that's one of that kinda gets one of my other questions with this largely is how much of this are you intending to be to be able to be used by, like, stock things that already exist that don't require modification versus how much are you willing to modify existing software to work?
[01:22:37] Mikael Nordfeldth: We want to modify as little as possible, but we are willing to, like, make PRs to open source project and make them compatible if necessary. Yeah.
[01:22:49] Aaron Parecki: Okay. Okay. Yeah. I like I said, I think the specifics are probably better for the for the list. But that that was kinda where my head was after after doing some reading last night. So I think there's some things we can we can tweak a little bit.
[01:23:06] Mikael Nordfeldth: Yeah. That that would be wonderful.
[01:23:08] Thibault Cholez: So yeah.
[01:23:10] Giuseppe Lo Presti: And I can even add indeed that we we are aware of other implementations. There is one in particular which I like in terms of concept that is about sharing GIS maps with a cost with a custom protocol. And there, I don't know the details, but the more we can build on open standards, the better for this kind of extra projects. Because then at that point, I don't think we would be able to actually open PRs to adapt things and make them too much custom. So the idea really would be to build on top of existing standards. And the idea there is actually helping a lot because we're really building on the bits and pieces that are already well known instead of inventive things. So that would be a kind of the guiding principle. So then, for example, for out if we can use a vanilla outflow, I would be absolutely happy with it without any special customization. At least we limit the customization to bare minimum just to allow our flow to work with it.
[01:24:11] Thibault Cholez: Thank you. Any other item for for discussion? Okay. Doesn't seem to be like it. So I guess, like, the action, at least for the is continuing on the mailing list for, like, the two ad option call for, like, the document that have been discussed. It should be, like, OCM IP or o c m like like, with federated MLS. And, otherwise, there's a couple of action that, like, without asking happened and activity on the list. Thanks to Aaron, and that's it. Any other piece of no. Okay. Good. Great. On that, we're adjourning the meeting, and have a good rest of the day. Thank you.
[01:25:08] Giuseppe Lo Presti: Always good.