Internet Engineering Task Force Interim Meetings, 7 Jun 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF-MIMI-20230607-1600

Description

MIMI meeting session at IETF
2023/06/07 1600

https://datatracker.ietf.org/meeting//proceedings/

A

To start the session, although I think we still have a number of people who aren't here yet so we're going to allow a few more minutes before we get started properly.

B

Hey Tim, can you say something so we can be sure the audio works.

A

uh Yeah, can you hear me nothing going on just yet, except.

B

A

No problem we're just allowing a little more time for uh more participants to roll in then we'll get started in a couple. More minutes.

A

Okay, that's five past the hour, so I think we can sort of formally get started here. So this is the third I think interim maybe session um thanks all for joining.

C

A

Odd there we go so as usual. uh Please note! Well the ietf note well um and all the policies uh and then let's get into today's agenda. So the only thing formally on the agenda is that uh Travis is going to uh spend some time explaining linearized Matrix to us and we'll have uh some questions after that and then, after that, nothing else formally on the agenda. So anything anybody wants to discuss um can be brought up.

A

um Does anybody have any uh objections to the agenda or anything they'd like to add at this time.

A

Okay, it doesn't look, looks like we're all happy with the agenda um last thing before we dive into Travis's deck is that we do need a volunteer to take notes on today's session. uh So please speak up if you're willing to do that.

A

If we don't have anybody I guess I'll just do it.

A

All right, um I think we can just move on into uh uh the first deck um Travis. Are you? Are you ready.

A

I'm, sorry, can you please repeat that should be yes, okay, uh would you like me to uh Drive the slides for you or I, think you can press a uh press, a button to request control.

D

uh I'll, probably just get you to do it, it's probably easier than trying to fight things. Sure thing.

A

There you go all.

D

A

Let me know when you'd like to change slides I'll, be forgive me if there's a delay because, like looks like I'll, also be taking notes while I do this go ahead. Nope.

E

D

A

D

um But yeah, so there is a updated draft for loading rise. Matrix um I probably should have put that on the actual title card here, but oh well, um but there is an o1 draft.

D

It removes all the dependence off of specdomatrix.org and uh these slides are kind of split into two parts, the first part being what linearized Matrix is just as a sort of recap for people who might not have seen the uh the draft and then the other half being a question around Channel State and whether it should be client-side or server side, um but yeah if I can get the next slide. Please.

D

uh Yeah, so the rough architecture is, uh there is a hub server and multiple participant servers.

D

um This has been discussed multiple times already um across the different sort of Transport uh drafts, where yeah the Hub server is responsible for basically keeping track of the conversation.

E

D

The participant servers, kind of just hold users and procs everything to the hub server, linearized Matrix rooms are what hold events, events, meaning um pretty much anything to do with the room itself. So that could be a text message. It could be an image, it could be a membership change. It could be the the room name, changing itself, that sort of stuff. We call events over the wire, pdus or persistent data units. It's just a slight distinction.

E

D

Next slide, please.

D

uh Yep, all of them behavior for a room, is defined by the room version or on that in a second um users are what send events they can have zero more devices. Devices are effectively what MLS would call a key or a device in the group versions are somewhat complicated in Matrix and honestly they're. Just not well named um the rough ideas that all the ACLS all of the behaviors algorithms, all that sort of stuff that actually runs the room, is defined by a single room version.

A

D

A room version is identified by a string um with that room version. You end up with everything you need for how power levels work, how messages are accepted or events are accepted, all that all that stuff is defined by the room version, but it doesn't necessarily need to be server-side. It can be run on either area.

D

They are Frozen Once to find Rohan.

B

Yeah I I found this this terminology a little bit confusing when I was reading it um would you um I feel like I understand it now, but would you would you feel, like it'd, be a good characterization that this is like um that this is basically a capabilities negotiation that the room version is just like. As you add new capabilities you you create a new version string and people can can coalesce on a specific set of capabilities that are associated with that quote-unquote. Reversion string.

E

D

Probably the best Congress is that yeah.

A

D

Because yeah, like they're Frozen, Once defined uh by a spec process of some kind um so like it's not like, you can just change how how rooms work um and so yeah everybody needs to support that version. You would also know well in advance um whether or not you can even join that room, because the room version would be told to you as a server or as a client, depending on where we put it uh so like you wouldn't be able to actually join or anything like that.

E

F

E

F

I'm just wondering, because about there being like a baseline version, that everybody supports, because I think that, um like what you just spoke about this like finding out that there's a room that you can't join um for for the sake of interop, is there a value in having like the the simple version? And this is the thing that ever that every implementation would be supporting, and then you can like do other things.

F

On top of this, that are more complicated um and find out that you know you don't support what somebody else supports, but um is that is that notion present or should it be for Mimi purposes?.

D

uh Yeah, so the intended purpose of linearize Matrix the waste in the draft is actually specify sort of like the first room version. I think it calls it like I dot, one um for no particular reason um bail like it would have all of the the semantics all the behaviors. So that way, everybody at least has something to go off of um in practice. You can Define sort of custom room versions, but the reality is, nobody actually does.

G

D

Outside of sort of specifying through an additional document.

F

D

That's good yeah, I think.

F

We like simplify for for this, so could.

C

I just read that back to confirm Travis. It sounds like you're saying that, like the at least the first iteration of linearized Matrix would define specific, newer inversion that captures The linearized Matrix capabilities. That would kind of be the target. For me, it's not it's.

D

Like about right uh yeah, so there would be an initial room version that room version has all the or all the behaviors that uh like I'm about to kind of go into and uh that sort of stuff it would all be. In the same.

E

D

If we ever need to make a change to it, it would just be a document saying or a new ID saying, hey yeah. We want to specify I.2 or I.3 or whatever, um and then we can just kind of build off of it from there.

D

I'm, assuming that's starting to make some amount of sense.

D

I'll, take silence is yes, um yeah.

C

The mute button here takes five seconds, so silence says yes, thanks.

F

Because Tim is um running the slides, I'm taking notes so sorry, I didn't come back and unmute.

D

No worries um yeah, so each each room version is is Frozen um technically the room versions aren't linear, so I.2 does not necessarily have to follow I dot one or inherit from I.1 in any sort.

E

D

um The reason why we call them room versions is because a room can sort of upgrade between these things, which is again just like a really awful term when they're, not linear, um because it is technically possible to go from I.2 to I.1.

D

If you wanted those characteristics instead um in practice, what upgrading really means is you create a new room with that room version um and then add a bunch of stuff to the rooms that way clients know to either splice or link or whatever, to deal with the two separate rooms um visually, but at a sort of protocol level there two entirely different uh rooms which mean to entirely different MLS groups.

D

Yeah uh next slide. Please.

D

uh See if this will be the same diagram that people have seen before in many different shapes, just as a slightly different shape, um you have a central provider provider. A in this case is the Hub provider B The Gatekeepers, and the existing dag, capable Matrix are all participant servers. In this example, the green things are clients or devices, depending on how you.

E

H

E

D

um And uh yeah, if you're familiar with Matrix as it currently exists outside of linearized Matrix, it does run off of a dag- that's represented here, as it just magically Works uh we're just not going to necessarily get into the details in in these sorts of interns, at least for the moment.

D

um Gatekeepers since they're a much larger sort of organization, they might have a slightly weird internal structure, but the idea is that there is a sort of public facing a linearized matrix server that is capable of speaking this protocol. Richard.

C

Yeah so Charles you and I talked about this before before.

C

One of the the bits of complexity that bled over from full fat, Matrix and linearized Matrix was that the despite the sequence of events in linearized Matrix being linear.

C

um It wasn't append only because if there are events in some chunk of the dag and full fat universe that right hand bubble. That could cause rewriting in the history of the linearized version. Is that still the case in that? In the current version.

D

uh Linearized Matrix in the current version does fix that. um So it's it's no longer affected by yeah. What might be going on on the sort of decentralized refrigerated side of things it just is append only it magically Works um that sort of stuff.

C

Okay, so the view that provider b gets here uh as a follower of the Hub and provider, a the view of the provider biggest would be a linear append. Only history.

D

C

Cool great thanks. That's that's a great Improvement.

D

Yep uh next slide, please uh so yeah everything in Matrix and linearize Matrix is sent as an event. uh There are two kinds of events, State events and room events, um but yeah. The the rough idea for a state event is that it tracks sort of meditative for the room, user membership, uh name, join rules, power levels that sort of stuff they are keyed by an event type and state key um Tuple, and they override each other.

D

Where current stage is just the most recent one that was sent um as defined by the append Only log sort of idea, um we don't use a dedicated event ID. um The event ID is just the reference hash of the event itself. This protects against basically malicious actors, um primarily if you use a uuid or a namespace or something to that effect.

D

um The easiest consideration is that other people can create collisions fairly trivially or truly.

D

um Although the downside of obviously using reference hash is that you are tied to a hashing algorithm of some kind, um usually some sort of um sha-256 or something um which also can obviously have collisions.

E

D

That would be fixed in a sort of proactive room version.

A

D

So before we necessarily encounter that sort of problem, um as it sort of starts to be a looming problem of some kind, there would be yet another room version being sort of cut and put into the works there. Conrad.

D

If you're speaking, I can't hear you.

G

Okay, now yep sorry um yeah, so maybe I'm jumping ahead a bit, but- um and maybe we talk about this later so if we will then please just interrupt me is it uh is this? Does this mean that events are broadcast to all servers so, for example, changes in room membership um or that rumors membership, for example, generally, is tracked by all uh participating servers or hubs.

D

uh Yeah, so the The Hub server is the only one that's actually required to actually keep track of current state and all that stuff um the participants can, if they want to, but there's no necessary necessity for it.

D

um The the idea is that yeah you can, or all of these are broadcast anyways because they have to end up on clients in some capacity.

D

um So you know just as a user that somebody joined the room or left the room or whatever, um but the participant servers can just act as basically store and forward nodes if they really wanted to.

G

But is it required that they're transmitted in the clear so they could be transmitted encrypted from The Hub, the original Hub to the clients.

D

uh Yeah I think that'll be more in the channel State discussion, the sort of Latter half of this, this deck, where we start talking about whether or not this information needs to be client-side, meaning within the MLS group or server side where it currently resides where it is in the clear.

G

All right, thank you. Yep.

D

um Yeah room events are basically everything else that isn't a state event, so that would be your text messages. Your image, events that sort of stuff um next slide. Please.

D

um Yeah, so just so that way, we're kind of all on the sort of same page, because, like a lot of this stuff, was discussed uh two uh interns ago and there were some I guess, disagreement around uh ACLs um and what that might have actually meant. So for the purposes of this sort of deck, um the a cells are what the room version defines.

D

uh So everybody knows what um is required of.

B

D

um There's not necessarily a need for a domain-specific language um as long as you support that room version like I dot, one or whichever um you will be fine and again you'll, know well in advance as a server or I guess as a client, whether or not you're actually capable of participating in that room, um because yeah, like you'll, have all these room versions um negotiated and that sort of stuff.

E

D

Does that make sense so far, Conrad I think you're still in the queue or rejoin the queue.

B

All right, Richard.

C

Yes, so sorry, if I missed something here like okay, it's unclear to me how these power levels map to like actual rules about who can do. What is that defined as part of the room version.

D

E

D

Auth rules um basically to find what is like it upon receipt of an event. um What are the conditions required to accept it? uh Power levels is how Matrix Maps um permissions and roles and that sort of stuff, um so power levels is a relatively large State event that has um basically a string key to a integer value um and basically the higher.

C

D

The more power level you have um users are also defined to have a particular.

E

Power level, roughly.

D

Speaking 100 is usually an admin. 50 is usually a moderator and then everybody else is zero, but you can also go anywhere within the n32 maximum range. um If you really wanted to um so like the rough idea. Is that like to ban you need a power level of 50, which means anybody who has yeah 50 or greater can bam that sort of stuff.

C

um Right so so, I think what I'm asking is: where do those sort of rules get encoded like that? That map you just said where you need a power level of 50 to be able to Beta like where does where does that live? Is that a fixed property of the room version, or is that written down somewhere I download that, in terms of time,.

D

um So it's in two places, I guess uh so the actual sort of definition of what requires, what level uh that is defined in the power level. State.

E

D

That is embedded into the room as part of just the normal room. State, the actual enforcement of those power levels is defined by the auth rules, which are part of the room version.

D

um So everybody knows how to interpret those rules uh as part of just being a member of the room.

C

A

C

Like there's a broad framework that is established as part of the the room version, but then the specific mapping of the integers to those rules is set as part of the room. So yeah.

B

There's like band, kick invite redact like the what level do you? What number do you need to have in order to be able to do these particular actions.

C

All right so the right, and so though you're saying that those thresholds are set in room setup.

D

uh Yeah and they're they're changeable throughout, which is yeah. Why they're part of the sort of room state yeah so.

H

C

You can sorry go ahead, so it's it seems like the presumption here. Is that there's like a total ordering on uh on rolls, basically that any two roles you have one will be strictly. One will be more powerful than the other.

D

uh Yeah um yeah we've been using that sort of system for years now and yeah it Bridges fine uh to everything um same for maybe Discord uh discord's role-based access control is different, um but there's also like we can just swap that out in a room version. If we wanted to all.

E

Right all right, thank you for the clarification yeah Eric.

I

I'm still a little puzzled, um so is. Let me try to restate what I thought I heard, and you could tell me if I'm wrong enough, so why that the specific set of activities that one is able to do is defined by the room version, but the uh the levels that are required to do those roles is defined by some configuration.

D

uh Roughly yes, um I'll I'll, reiterate it just just as a sort of different different way, um so yeah, like the the actual configuration of like what requires what that's just part of the room uh and then yeah. The actual enforcement is, is defined by the room version.

I

I I I don't understand what actual enforcement is defined by moons. That's the problem, higher problem with.

D

Yeah so like when you send a new event, like let's say you are trying to ban somebody that requires sending an event. um The actual ban event gets sent over the wire um gets received by a server somewhere. um That could be the Hub server. It could be a participant server, that's going above and beyond, um and so once it receives that event, it goes ah yes. This looks like a ban.

D

um It'll run it through the authorization rules which actually Define like in addition to all of this stuff, but also how to detect that it is a ban, for instance, because you'll be sending an M room. Member.

B

D

With a membership of bam, and so it it falls into a case of like it's, basically a giant if else ladder um sort of fall through into that, and then it'll tell you how to process that, where it's like. Okay in order for this event, to be.

E

D

It needs to the sender needs to have this certain power level um if they don't just reject the event and then nobody.

I

Oversized it yeah, but not confused, apparently power level, again parallel specified in the room version and the room configuration right.

D

Yep, so it tells you to look up the the current user's power level and there's a definition of how to actually interpret that power level. State event.

I

I'm sorry I'm still confused. The user's power level is part of the room state, but is the power level required to do an action part of the room state.

E

I

Rc does the RFC say to ban you have to have 50, or does it say to ban you have to have the thing specified in the configuration document associated with the room, the ladder, the.

D

I

Ladder great thank you.

D

So yeah, uh with with all the ACLS yeah they're, all defined as part of the the room version, um the ID goes into detail about like what the actual currently proposed rules are, um and also like what the M room power levels event looks like um if you're kind of curious there um you can get, it is called the auth rules, algorithm uh 542 in the in the document.

D

um So next slide. Please.

D

E

D

State is the sort of term taken by Eric slides number 14 if you're interested back about a month ago. um So traditionally, Matrix and linearized Matrix handles this sort of Channel State server side. We call it room state um and then we would try and keep the MLS group in sync through rules defined on the clients.

D

um But lmos is also capable of handling nearly all of this client-side if it wants to um and obviously when ours Matrix can support either so I'm just going to jump through a couple of the slides and then we'll kind of just open up the floor to just like the sort of wider.

E

D

But if I can get the next slide, please where we talk about the server side stuff, so in this model, MLS only handles the device key membership in a group, but it's informed on what's going on sort of in the room so which users are joining, whichever rules we end up, creating for um basically making sure that Alice is zero or more devices are actually participating in that group appropriately.

D

um That is undefined at the moment that will need to be figured out if we, if we decide on this sort of model, um but the servers end up um rejecting the events um based off of permissions power levels or just general structure.

D

um You know if it's a malformed event, it should obviously be.

E

D

But there is the obvious security flaw of without cross signing or some sort of um device verification structure. A server can maliciously involve a device in the MLS group um by simply just appending it to a user, for instance, and that causing the instruction to um add that device to the to the group.

D

um We would solve this by somehow defining some sort of rule that prevents that um Conrad.

D

No audio once again.

G

Sorry, my uh Linux keeps picking the wrong audio device um understand this correctly, so the server would then kind of make a client add someone to the group on the MLS level.

E

D

Within reason, yeah like there would be some sort of semantics that would say like hey. When you see Alice create a new device, um they would be somehow involved in the MLS group, whether that's an external, join or something similar. To that um same thing for like when Alice loses the device um that would have to be resolved somehow, um and so like. That's, where the the sort of servers being able to inject devices into the into the group becomes a bit of a problem.

G

Okay, but then sorry, then I have a follow-up question. um It's not clear to me what you mean by cross signing I mean because of MLS every client knows like who is in the group right, so the server can, in theory, eject like quote-unquote inject a malicious device into the group, but all clients will know at all times to which devices they will encrypt and they will know that all other clients know as well right.

G

So if I, if the server were to inject a new device for any user, that user would notice, at least as soon as it would come online right.

D

Yeah, uh the problem is that, like damage is already done once the the device is in the room uh or in the group like if you're already encrypting for that device, then like no amount of prompt or anything like that is going to prevent the.

F

D

From receiving traffic um I see correct, yeah cross signing in this case is basically saying just like hey I created a new device and I can cryptographically prove that it is actually my device and not just the server plugging in as me, for instance, because it has access to be able to do that.

G

Right I see: okay thanks.

B

I

At least three different scenarios here, um I think the easiest scenario is the one of um of adding a new device for an existing users in the room, and in that scenario I mean we assume we have some authentication structure that that authenticates, endpoints and or people and um and if and that when someone adds a new device, the device should be authenticated to be that authentication structure and so I'm being big about this.

I

But, like you know, hypothetically, it's like you know, cificus plus KT, um then um then the server then the server the server should not be able to mount this attack because because they can't you, because they can't authenticate the user, um so I don't think that needs cross-siding. Anything is ordinary Authentication.

I

um uh The more difficult problems are the ones about, manipulating the conceptual membership of the group in terms of in terms of users rather than devices, and so in terms of the addition of a new member.

I

um You know, as Conrad says, it is true that the uh uh that the membership of the gurus manifest to all users, but that doesn't mean that the um that in a substantialized group that the the group member um uh that the group members know who ought to be in the group so I think we probably, as we discussed previously.

I

We probably do need some way for um to have groups that have a policy that only uh only members to add people, but we also need some way to have the policy that um uh that uh um that the server can add people um and um I think so. I think that, but and the former course in the asset control in terms of what you're Crossing by would just call signing, which is to say signing the manifestive users were allowed to be in the group.

I

um um I think under the circumstances, once I finished, I think the answer is external join rather than um uh rather than having some group member do a joint, um because who knows whoever be online?

I

um The hardest part, um however, is kicking which the server can't do, because it's not part of the group, um and so someone will have to I mean what the server can do is change the room roster, um but what it can't do is actually, if it's someone from the MLS group, and so that requires someone in the ls group to do the eviction um as I understand. That's.

B

Not true, you can do an external proposal, uh the server can do an external proposal and that's accepted.

I

B

Yeah, it has to be accepted, it has to be in the.

C

B

A mechanism for.

C

The for uh folks, outside of the group sending proposals um of what the server can't do is commit that proposal, um so you'd have to have some mechanism by which the server uh that publishes the proposal and then whoever next comes online, commits it. The.

H

C

Can sort of kick but can't actually put it into effect.

D

Right, yeah, I guess the server could instruct that hey this person or this device rather needs to be removed from the MLS group. And then it's on the existing members to make that actual call.

C

Right right, I mean the server could even enforce policy like the server knows. Who's on one server can enforce a policy that it's not going to accept any events until its proposal is committed.

D

Potentially a yeah the fall definitely into the sort of like Rules of Engagement. Here I think.

I

um So I think I think that the new technical mechanism is actually required. Here is um the mechanism I mean so I mean it seems to me that the the logic that the MLS implementation on um organization group participants has to be is when a new when, when a new person is there needs to be like the cause of a room. Roster I mean a new person to join the group. They examine the identity and compare it against a roster. If that's and if that's permitted, then you accept the astral joint.

I

If you don't you don't and, um and so the new mechanisms I'm sure Matrix has that concept. The new next is required here is the ability for users in the room to sign the roster, um thus allowing you to create groups which only which only new participants, which only participants.

E

E

I think you're on the wrong audio device again yeah.

G

Sorry I'll have to do that manually. I'll figure it out in between anyway, um so since we're discussing membership and MLS is essentially already tracking membership. This kind of leads me to another question: are you considering MLS messages and like public messages or private messages so like encrypted MLS messages or plain text like handshake messages, at least.

D

uh uh What do you mean by that sorry, the the crypto side specifically is like less of my sort of wheelhouse.

G

Like um sorry, maybe let me explain real quick, so in MLS you can messages and especially handshake messages can either be sent encrypted or unencrypted, and if it's unencrypted, it obviously leaks um everything. That's inside the message, but that's not necessarily kind of users and data, that's more concerning the group state, so that would be adding removing uh and these kind of things handshake data um and you can send them encrypted so that it all it leaks to the servers. The I think the group ID uh the content of the message.

G

So if it's a sorry the content type of the message, so if it's a proposal or a commit and um the current Epoch or something and um so I guess what I'm trying to say is that the server can easily kind of just track the MLS membership. If we use plain text, handshake messages, so sorry public, handshake messages and then can the server can also control can also check. If it wants a kick a member, it can also check if the next message is a commit.

G

If it doesn't indeed include the remove proposal it previously kind of enforced on the group. So.

E

G

As a as a if you haven't really looked into that um in terms of how the universe metrics can interact with MLS, that's certainly a thing: I will take a look at.

E

D

um I've been told by the crypto team that uh they're in the past that we would encrypt it as much as we possibly can. um If we sort of make it like it,.

E

Depends on where.

D

uh I guess like we fall on those sorts of rules for adding or removing devices from the MS group. If we require that the server you know require or needs to see that the proposal is accepted, then yeah we probably need to be plain text, but if we can come up with something I guess reliable, where you know the server doesn't need to see that information and doesn't really care about that information.

D

Then we should definitely encrypt it um and then, depending on like where we fall in between those two points, but I guess depend on sort of which specifics are encrypted and which specifics aren't.

E

C

Yeah I was gonna say as a general rule. I would propose that we kind of adopt the the the goal of have of using encrypted MLS messages everywhere or at least being compatible with that option.

C

um Now it may be that certain things are not compatible with that, um and so the way I would proposally proceed as a working group is to start out from the assumption that this server can't see inside any MLS mistress that is sent, including the proposals and commits uh that manipulate the the in-law State um and then only if, if there's some critical feature, we can't do do we create cases where you would need to send it.

E

G

Okay, um so Richard, can you maybe elaborate on why you think we should do this? So um sorry and I want to kind of motivate this. This question before you, you respond because we try to look at both and when we started out with encrypted uh handshake messages. Obviously, with the idea of you know protecting as much as possible from the eyes of the server we afterwards figure, like noticed ourselves, kind of building all the stuff that we wanted to uh to have on the server kind of building it outside of MLS.

G

Again- and you know you have a notion of user sorry, you, you have a notion of members and the members somehow have to authenticate to the server that they're part of the group, etc, etc, and so, in the end, what we, what we ended up doing in our like delivery service uh proposal, is decided on just doing plain text messages and um kind of obfuscating. The metadata by you know using pseudonyms and that kind of stuff. So yeah I'd be curious to just to see here what uh why you think this should be regard.

C

um I I was not trying to articulate the requirements as much as an aspiration, so I think we should. You know well if.

H

E

C

As as you know, you might imagine a naive reader once you know, I should be using stronger security settings everywhere um and justifying when we know who's the strongest, so I think mainly what I'm saying is like. If we decide to go yeah to adopt a position that you know, MLS messages need not be encrypted or must not be encrypted. It might be a possibility.

C

um We just need, like a section of security considerations that collaborates. Why basically the stuff you just said.

G

Sure I mean we can see and go ahead. How far we get um one. uh One thing that we noticed is what uh we very likely want on the server and some uh as much kind of as in terms of message: verification as possible, because, especially in a Federated environment, you're, otherwise, really quickly get messages that you know, Fork a group or you know otherwise send garbage, make the server increment to Epoch, and you have to roll it back Etc, so that kind of stuff.

G

You can mitigate a lot of these uh the potential for malformed messages by sending plaintiffs and check messages and then have the server verify a lot of the properties that you want.

C

Yeah and I'm sympathetic that a lot of what you're protecting in those uh handshake messages is the part that the roster of the group, which the server fugitively already knows anyway, I'm a little wary, though, when it comes to the possible extensions you might use in MLS the White House stuff, you don't want, it wants to be accessible to the server you.

E

C

It's possible, you could design some of the hand protected extension model that you have.

G

C

The outside, but the encrypt some stuff.

G

Yeah we're already kind of in the process of drafting like an encrypted extensions extension, I guess so. Yeah, sorry, Travis.

D

Yeah no worries uh on The Matrix side. We also have something called dmls or decentralized MLS, which theoretically could be applied to both the server-side and client-side model um in in these are in this deck here.

D

um The rough idea is that basically, your epochs become a small, dag associated with each device, um and then you run a conflict resolution on them, um and so it allows you to have those divergences in in MLS stage and group and that sort of stuff without having to make the server aware of it. So you would still be able to encrypt a lot of that stuff, um but that's not necessarily described in the in the draft at the moment. I think it's referenced, but not not actually written down.

D

um Yeah I think that adequately covers the server side. For now.

D

Once twice three times all right uh next slide, please uh client slide is the pretty much the complete opposite of this. So servers pretty much just check to make sure that the actual syntax of an event is okay or as much as of it that it can see um because, like these would be all encrypted payloads, um you know everything is run within MLS the act of accepting rejecting events, um adding removing users which would probably change the membership model to be per device rather than per user.

D

um All that stuff the server doesn't see any of that it just receives an event goes. ah Yes. That looks like an appropriately formed whatever.

B

D

Sends it off to its local clients, um or in the case of the Observer, it sends it off all to the participant servers as well.

D

um The obvious downside for this one is the client complexity goes way up you, you need a ton of conflict resolution, there's also a bunch of data waste um where you know the clients know that things were accepted or rejected, but the server doesn't necessarily know because it can't form um basically that linearize, um it can't form what the room actually looks like, because it just doesn't.

E

D

It can't necessarily trust and a random client um on its or as part of the sort of membership to just say that you know this was accepted because there could be another device that says that it doesn't, and then you have that sort of problem going on there. um So, ultimately you just let it happen within MLS. Everybody knows again with the MLS group that you know we're using this room version, which means we're using these ACLS, um which means you can accept and reject uh different proposals and commits that way. Richard.

C

Yeah sorry I just had a little bit of a meta question here in that um I I may have missed like. Why are we talking about server side versus client-side group models, like my my impression was The Matrix. The way it runs today is all basically called the status maintained on servers and clients are very similarly, so are you proposing kind of departing from that model and building a new model where more state is kept? The client-side, which I guess would mean a participants servers. It would just be routers.

D

um So this is falling back to yeah, like the conversation at a couple interns ago, where pretty much the question of just like. Should it be server side or client-side um was raised, but there didn't seem to be an answer so linearized Matrix can do either, and so this is realistically the the sort of question of which do we want to do as a working group, um which is clarified on the on the sort of next slide but like covering like the server side and client-side individual pieces is, is important. I think.

B

Yeah um so I wanted to comment on one thing in your slide up that servers don't know what was accepted or rejected. So um that's only true. If the commits are a private message, if the commits are private message, then it seems unlikely that uh that we would be able to do external joints, which we were, which it sounds like from previous discussions that we're going to require so I I, don't know anybody who is doing a serious implementation of MLS.

B

That's that's using um you know for messaging, that's using uh or that you know that needs this kind of property where you can do an external commit that is doing um uh that's doing uh encrypted. Mls commits.

E

D

Yeah, um there are definitely aspects that MLS can't necessarily handle um the client sites are remodel, does aim to use private messages as much as possible, uh if not exclusively um where it can. But there are obviously the sort of edge cases of eventually you're going to need to kick a device. You will need to add a device that sort of stuff.

B

But basically, if you want to be able to, if you want devices to be able to go and add themselves, I think that you're gonna find that you all of your commits need to be public message.

E

D

And like that, might be a disadvantage of basically using a client-side brew model, um much like with a server-side remodel there, an equal number of disadvantages, which is largely why this this conversation is being brought up.

E

B

I think anything we do in Mimi is going to require using public message for commits.

B

And I think among the people who've been who've. You know been actively working on MLS I. Think that that's actually non-controversial.

G

Yeah I won a second run on this. I also think we want to do a public message. uh It lends you essentially a bit between the server and the client-side role model, where you get the advantages of the of both. Essentially so the server can do all the checks and do tracking and can support external joins can keep the you know kind of clients joining by having them download the because it tracks the registry, essentially um like allowing clients to avoid uploading, the whole group State again and again and so yeah.

G

So at least to me there seemed to be a lot of advantages and, as far as we have seen, the disadvantages can be mitigated to large to a large degree, but again we'll see what the requirements are that we run into, but yeah a second rowlander generally here.

B

C

Yeah I just wanted to be clear. That I was in my earlier comments. I did not mean to be dogmatic about. You know, encouraging about requiring private message.

C

um I, you know in the product I ship, for you, we use public message um as well, just just like our own suggested, so I think it's very possible one up. There um I think it's just useful to keep an eye on. You know when we might be able to use private message.

D

Yeah I mean, like my personal belief, is that wherever we can, we should be encrypting this sort of stuff, but if there's a necessity to make it public, obviously that that starts a play. Alyssa.

F

So can we sort of put the client-side room model to bed them like? Do we need to continue to evaluate it.

E

D

That's kind of what I'm hearing um if we can go to the next slide, uh it kind of raises this question um of just like which one should we go with and also does it need to be cryptographically bound?

D

um What I'm currently hearing is that yeah like we would want something more on the server side than the client side, uh cryptographically bound I think it was an open question still Eric.

I

Yeah, so I I, don't think basic description. I, don't think the client side is viable, so I would not I think we need server side.

I

um I, think my position on Twitter, if we bound was clear um and I think it'd probably be useful to like actually try to talk about a little bit about what threats were always tolerated for the surfer and which ones were not um um rather than just sort of like you know. um You know we were talking about implementation details but, like the relevant question is what is it we? What is it where we wish that are designed to provide in terms of security against the server and well I?

I

Don't have anything like complete the description of that? um You know, I think it should. It needs to include the server not being able to like read the messages so we're not being able to um falsely inject a user into the group um um uh and um I. Don't I, don't I.

I

Do not, however, think it needs to, um or are these it's practical at the moment, to conceal the group structure from the youth from the server or um or to um you know uh you know, perhaps um you know conceal um other things like that, but I do think. If you look at it for the president I just indicated. That does tell you, for instance, that um uh that the server may or may not be able to um modify the uh uh the accident the configuration, because if the cervical monthly configuration they can, they can.

I

Basically uh you know, uh change the permissions. So um if you think that the room has to be cryptographically protected the membership, then probably the configuration has to be as well so um so I think again, like I, think the most useful, rather than discussing the precise details of like how women perform things to discuss, what we're trying to achieve in terms of production as a circle.

E

Yep fair enough Conrad.

D

uh I can barely hear you. Yes,.

E

D

But yeah to Eric's Point like having a lot of the stuff server-side. um Obviously they can just create events and create configuration. Then that is a problem when you want cryptographic, proof that the change can happen or has happened, um which I think is just basically saying that we do want that cryptographic. Proof Tim,.

A

Yes, um so one thing I I'd always try to keep in mind me- is that, like the objective here, is to get a number of existing systems to Gatekeepers, to talk to each other, so I wonder like what are actually the existing capabilities of these systems. My understanding is that for a number of the systems that are, you know that we'd like to see in drop rate via Mimi.

A

um The server operators can already say impersonate arbitrary users because, like they control identity, um what I'm less confident in is to what extent can I don't want to pick on any particular vendor here uh but like to what extent can existing server operators add members to a group in in existing deployed systems.

E

A

E

Bring it up because, like.

A

If, if Mimi goes and says, you know Design's a thing that makes that impossible, I wonder if that then is like a deal breaker for some Gatekeepers.

D

Yeah so generally yeah like the The Gatekeepers and existing messaging providers, like you said, do have the ability to just impersonate their own users, for instance, and just do whatever they want, as their users there's obviously a social contract there that you know you shouldn't do that, um but in the sort of rough case it's it's very clear that you know if, if you want to take over a user's account and change the permissions and that sort of stuff, so long as you have the ability to do that, then you know: there's nothing stopping the the sort of service provider from from doing that.

D

So with the cryptographic proof that is I think in an additional requirement um that doesn't necessarily translate to the existing Gatekeepers.

B

So um Tim I wasn't really clear whether you meant uh there are there. There are features like the ability to go and add new users that are, in you know, uh example, gatekeeper, A and B, uh like you know like WhatsApp, can do that right um and does this allow for that? Or was your question um if you allow people to add users to a conversation?

B

What does that do to somebody who can't do that like iMessage uh and I'll just go ahead and hop in and say that I think iMessage is fundamentally broken at its protocol and in its user interface, and so, if we try to base Mimi around that we're going to end up with something that just doesn't work.

A

E

Fair enough.

E

G

Okay, is it better now.

D

It is different, so, okay.

G

um Jeez, okay,.

D

uh It's understandable at least.

G

It's understandable, okay, I'll, give it a go for this person and I'll try to fix it for the next one, um so I, just it's. Nothing just want a second uh Eric and I think it comes back to what we talked about in terms of security requirements rather than functional requirements.

G

Right comes back to the discussion we had on metadata last time to where we have to uh you know, work out a threat model and figure out which of these uh yeah security or metadata requirements. We want to meet um and I mean we should do that separately, but I think these discussions on different approaches to you know running a server at least kind of gets us closer to to what we want. So I think this is It's a good discussion to have for sure.

B

I

Yeah so I think you know Tim's making an important point about, like um you know, not trying to get out too far ahead of the um of the existing systems, which do not have great security properties, but, on the other hand, I think you know my take on what we ought to be doing is trying to design a system that was compatible with existing systems which had as as condom for your security properties, but also could be constructed in a way that has stronger security properties that provides a bridge to um you, know a bridge to a better world, um and so uh you know to take to take the probably the most egregious example right.

I

The fact that um the uh uh the the the the existing systems, basically don't have any kind of mechanism threading impersonation.

I

Well, we do you know we do have technical mechanisms that potentially um you know avoid that you know in the form of key transparency like that, and so you know what we ought to be designing is something that is compatible with mechanisms that provide for an impersonation by the server, um even if it also can be run in the mode does not have those mechanisms, um no I, think in that case it's probably almost requires almost no extra work, um but maybe there are things that require a semester work and we have to figure out.

I

You know um you know what those things are, and you know whether we need to leave extensions for them or actually deal with them, but have opt-outs or whatever, but I think you know, I I wouldn't want I, wouldn't want the system resigned to be, like the you know, the the minimum of all possible um known existing systems, but rather to be at least compatible with the best. We know how to do while also supporting the Positioning Systems, if necessary,.

E

D

um Something that uh particularly like on The Matrix side, just to quickly respond to that um that we aim for is.

E

D

Compatibility rather than minimum compatibility um just because yeah like it's it's more important to have have those sort of aspects rather than yeah cause problems for yourself, Alyssa.

F

um Yeah I think Ecker said most of what I was going to say, but I do think.

F

um It's also just worth considering that their the posture of Any Given service provider towards what they want, um some uh other server to be able to do as they have other users interoperating with their own users, is maybe not necessarily 100 the same as what privileges they reserve for themselves today in their existing Services, um so I think um we can be like a little bit more aggressive about the security properties um that we were just talking about because of that um and I was and I was also just noticing that Matthew posted into the chat.

F

um This gatekeeper comparison uh that he had promised to deliver and I think um now. People can look at it um and take take some time with it. But I think we should come back around on this um in a future interim and on the list as people kind of digest this, because we can also use this to try to synthesize like what the actual um superset of um the existing gatekeeper functionality is that we we think we want to support.

E

D

A lot of those conversations was uh started based off the idea of what do we want to achieve as a working group because yeah it was kind of undefined at the at the previous intern and uh yeah. uh Thank you, Matthew for sharing the uh the document.

F

D

F

Thing um just to throw it out there I feel like because we're now, until whatever the fourth or fifth um meeting- and we have this kind of long-running thread about like what do we think the requirement should actually be I'm- probably going to start just collecting all the ones that we've talked about um thus far and putting them in some document that people can edit and um and add to so that we can start to have like a single reference point for what what we think.

F

We are slowly coalescing around in terms of what these security and authorization and metadata requirements are.

D

Yeah, that would be very, very helpful, um uh particularly from from my side of trying to build something that uh meets the unknown requirements. uh It does sound like, though, that yeah so like we have the rough consensus that something server-side, possibly with uh public MLS messages, um is the the rough Target uh I guess: cryptographically bound I, guess state in general, not just membership.

D

um That I guess is an unknown um depending on whether or not we think it's a useful uh characteristic, but I'm. Also mindful that we are out.

E

D

On this slot, so I will leave it to the chairs to decide if we can continue.

A

Well, we have another hour in the session today and there's nothing else on the agenda. So, if there's still stuff to be discussed on this topic, I think we should pursue it.

E

Fair enough Eric.

I

Yeah I just I'm, sorry, I missed the beginning, so I don't know how the chairs teeth this up, but I think you know um uh as I understand it. um We have not yet decided on a starting point for this for this place of the protocol um and so I think. Probably the uh the focus of this discussion should be not necessarily answering questions about how open your eyes man turns out to look but determining whether the linear's Matrix is a suitable uh foundation for the beginning of of the workers.

I

Written group um so um well, I think definitely should move forward and, like you know, if you have more to talk about I think we should be focusing on those questions um because, like, for instance, this.

H

Question binding.

I

Is like a great question but like since Matrix doesn't do it and like draft person doesn't do it? If that anything, and so like I, think it's probably um I, think we should focus going forward on like whether Linux Matrix is like a good foundation.

I

D

Yeah I mean like this is the last slide in the deck um but uh and I'm, obviously biased I do think it's a suitable base um yeah if we want to shift the conversation in that direction, I'm totally. Okay with that.

I

I I guess what might be helpful would be um you know uh um you know and obviously I'm asking you to really argue against interest here. But, like you know, what are the challenges you see? um You know, starting from the United Matrix, that we have to resolve that like profit, but I might not be, might not be the case. If it's another protocol um you know and what are the?

I

What do you think, like um you know, I think I, guess I guess I guess advantages are pretty clear which is like starting from like something. We already know um that already exists and works, um but I guess are there other other advantages of um of this design? um You know, as opposed to some of the other designs. We've seen floated um what those advantages might be.

I

Which Networks yeah.

D

I mean like that's the that's the fundamental Wellness. It already exists, um like the the draft is extracted from the existing Matrix spec, um so it already functions in that. In that respect, the other sorts of benefits are like it honestly just comes down to just its existence for a while, like the the author rules have been narrowed down quite a lot, um but I guess speaking to disadvantages, uh it's the stuff that we already kind of talked about where, because it's a server-side model um in Matrix, because Matrix has its own encryption existing already.

D

um A lot of these problems are fixed at that level, rather than at the sort of Transport or superset uh um Communications layer. um You know with with introducing MLS to the stock. We have the issues where servers could theoretically inject devices, which we obviously don't want um so trying to come up with those rules is, is sort of Greenfield new tech that needs to be decided on where the the existing sort of Matrix spec using a not MLS.

D

Encryption has already solved a lot of these these in these areas, but, like we'd, be building off of that experience and those those characteristics to help shape how MLS would work um I will also just pass it immediately to Matthew and see if there's anything that I might have missed briefly, there.

H

Sorry I couldn't find the tab. um No I think that covers it um Travis, but I'm very happy to try to um clarify his need.

D

Yeah um I guess other, like have people had a chance to go through the draft at the moment, or is it still or probably it being published 12 hours ago or 24 hours ago? To two reason: But Eric.

I

Well, I certainly have not. uh I was really not going through the most recent draft. um I wrote a previous draft. um um Sorry I will about um uh um I. Guess you know, uh do you see there being significant architectural differences between like this design and like Jeff Rosenberg I mean? So? What do you think?

I

That's all um I guess because I'm sure trying to get out is like you know, I definitely like you know, I think it's a lot of me right and like this has already been done like it works but, like you know, um but like obviously in anything anything like I, guess anything made anything else. So I'm wondering are there like if you like, look at Jeff, Rosenberg and I.

I

Guess Jonathan's not here so like I, don't want to do it but like are there things you would say like gosh I, don't think it's gonna work, because that's for some architectural reason that the players major solves.

D

uh From what I've seen of the sort of existing alternative proposals uh we'll say, because there are a couple of them, uh the the rough theme seems to be that um there are like several minor some cases, uh more major problems that, like they're, about to run into um that we've already solved.

D

um You know we also mentioned previously, just like almost all of them use some sort of uuid or namespace for what we would call event IDs, whereas in Matrix we already ran into that problem already created a room version uh to solve it and started using hashes.

D

um That sort of side of things is is look, I, think we're like ours. Matrix yeah definitely has uh some sort of standing. The existing proposals, architecturally or all, are all pretty much. The same uh I think we discussed that at the the last interim, uh where it's all of them have some sort of central server uh that deals with the fan out for the other servers and the other servers just kind of send it through that and on a roughly per conversation or per room basis.

D

uh Linearis Matrix is the same thing like it's. It sends it.

B

Through a hub server.

D

The participant servers kind of exist, um something for the the later requirements would be. Do we want to be able to move that Hub to a different server um like let's say provider, a just has no interest in running the room anymore, but provider B does have an interest. You know. Is there sort of Merit in having um having that be transferable state of some kind.

H

And that's why planting the existing decentralization stuff in Matrix means that moving the Hub around could be much easier because you could use um the basically a subset of the proof, logic that is used for the full fat um decentralized Matrix in the context of linearized Matrix. In order to securely hand over a hub from A to B I think there was also a difference on MTP in terms of mutability of events or messages that I seem to remember.

H

The jury was out on whether the message contents was immutable or not, whereas a matrix would have gone deep down, the immutability rabbit hole and it's worked out quite well, albeit with things like redactions being or sorry deletions, being append only messages that you put into the log, which then go and preserve the Integrity of the previous messages. By only deleting the um human.

G

H

Pieces was keeping the hash, and thus the ID intact, which is quite a nice property.

D

Conrad, your unmuted, but not providing audio I.

G

Thought I had a solution, but apparently it doesn't work anyway, uh yeah, so to jump in here. um The so last I looked at the combination between Matrix and MLS, like one of the issues, was matrix's uh the functionality of essentially supporting longer term net splits. So is there? um How does this relate to uh the linearized version? So do people have to keep key material around to essentially potentially recover from an expert that they might or might not know about? This is something that that is still present in linearized Matrix.

D

uh Linearized Matrix deals with network partitions differently, so with the existing sort of Matrix side of things um or the dag, capable Matrix um to just be more clear about it um in there yeah, you need to have an encryption protocol that understands that some servers might be slow to send their events or might never send their events um so like that, creates a situation with an MLs where that just becomes difficult um with.

H

D

Matrix because everything runs through a hub, rather than being a full mesh transport, you end up having the situation where, um basically that, as long as the Hub is online, you should be able to send information between other servers and it's less important. If the participant server um doesn't receive things because the Hub can theoretically say Hey, you haven't received anything, you can't produce anything until you receive all this stuff, um but equally, if the hub goes down, nobody can chat anywhere because there's nowhere for the the conversation to go.

D

So that's an advantage more on the Matrix side, rather than on the linearized Matrix side.

H

It's also worth noting that even on normal Matrix we're moving away from this idea of keeping key material around in case of a net split, because it's um almost an impossible problem to solve. Because if you have a network partition.

E

H

Some devices get added on the far side of the partition, then obviously you're not going to encrypt for them at the time, because you don't know that they exist, and so you would have to go and re-encrypt and effectively exfiltrate the information out to them, which, as a whole, set of obvious trust and problems associated with it. So what we're actually switching to, particularly in the very latest generation of Matrix clients, is to just disable what were the key gossiping functionality entirely.

H

So we've got this new client called element X, which is built on a new rust SDK, and about two months ago we made the decision to just turn off the Kegel spin functionality outright and instead handle basically a UI feedback mechanism. That says sorry, you can't see this message because the person who sent it didn't know you existed and empirically users seem to be able to get comfortable with that. If it's presented simply enough, because in the decentralized world of Matrix, um it's obviously a bit of an edge case. If you have a.

F

H

Split and telling the user sorry, the network was all over the place and they never sent you. The keys almost feels um understandable, but as Travis says, that doesn't even happen in linearized Matrix, because you don't have the ability to have Network partitions in that manner.

E

Thank you, Richard.

C

Travis, can you speak to the state of the art in terms of implementation and any interrupt testing may have been done here.

D

uh Yeah so like we've written a linearized matrix example, server um then I continue I forget the name of um which is a bit embarrassing, as I wrote, most of it in.

H

Fact I can serve it.

D

Yep eigen server, um but uh yeah so like we've written the example, implementation of it um and.

B

D

It's taken days rather than months to actually make the thing function, uh the interop side of things we've proven it can work with uh synapse, which is a traditional Matrix, Home, Server, um capable of supporting dags and all that fun stuff. It's like we do have the interrupt with. Obviously, our own stack um we're just kind of working out the the details of making it function with something that isn't Matrix branded I would say.

C

Yeah, it seems like the interesting case here would be someone who had not didn't have any Matrix Heritage, uh starting from the spec and working up to some level interop with with your code. So it sounds like that has enough for you.

H

Oh, if sorry, if you're playing Felson news with the um queuing discipline by the way, um but we do have two different compliance- Suites that we've already written for Matrix as a whole. Admittedly looking at the client server API, as well as the server server API, there isn't one yet for the new um linearized Matrix server, server API, but um yeah one's called site test and slightly embarrassingly, is written in pole.

H

Five and the new one is called complement written in golang and both of them are published by The Matrix Foundation um as a compliance test, Suite, basically to exercise the the API surface, which basically Maps directly onto the Mimi, um or at least it's.

E

H

Superset of requirements for the Mimi use case so for linearized Matrix going and switching the existing Federation tests and complement to instead exercise LM basically means that you get a conference tests framework and for free. If I wanted to do a question, correct ish.

C

um You know, I think what would be interesting here is you know whether there was a second implementation that would run against something like that, um but.

B

Like I said, it sounds like.

C

Like so far, we've just had the Matrix elements. um Implementations don't get me wrong, so that's good good work but um I think the next. The next interesting big step would be to to have. You know.

H

A really interesting fact could be to take an existing normal Matrix server and make it to linearize, Matrix and potentially, and so we have eigen server as complete Standalone clean room thing that Travis wrote and then forgot the name of the taking the existing um ones already out there uh and making them speak. The dialect, too, could be those points or we could potentially get one of the independent Matrix servers.

H

There's a really nice one in Russ called conduit and get the conduit guide as if they were up for going and implementing the LM dialects to um have improved point.

C

Yeah I mean that those comments seem pretty focused on going kind of down from from regular Matrix I'm, also interested in the up version, where you start from nothing, and you build up to just doing the nearest Matrix.

E

D

I'm aware of a couple implementations that are planned, I would say that aren't written by us uh that are in in theory, going to be compatible.

D

um I would basically just ask that yeah if people feel so motivated, uh taking a look at the draft implementing it as server side and basically saying like hey, this isn't going to work, or this will work or it will work with with changes which is probably the the expected State there.

D

I

I wanted to clarify like to sharpen Richard's Point um that the standard here is like that. I have to be able to read this document and nothing else, um there's not an ITF format and um an implement the thing. um So um so so it's so so like that that so like definitely a starting point is a matrix.

I

Server does not like help move that forward, um so, like um so I think like um uh so so, I mean I'm, not saying it has to be a case now, but that will have the case eventually um um and so uh Associated that the most interesting question is: how hard is it for somebody to get to that point?.

E

D

The current draft uh has no references uh to spec.ametrix.org, unlike the previous draft, um so it should be currently self-contained um just for yeah just for people who might be interested in implementing it.

C

Yeah, that's a super positive development, so thanks for that, um just to soften ecker's point a little bit like. Obviously that, like fully independent implementations, uh just from spec is the the standard to which we Aspire for the final stuff here. I think the question as Ecker pointed out earlier uh before the working group here is like, what's the right basis for the working group 2.0 to start from and I think to get to that adoption question.

C

um You know: you'd want some level of Independence, um but you could probably allow some level of coordination but still kind of working from the spec and without a lot of external tools. So you know you'd want to like start from something where you can get some interop and then reduce the level of coordination. You need reduce the level of dependence, ethics troops, so I think. Yes, we want to get to intermittent implementations, but you know so the adoption question we just need some basic, um so some more basic demonstrations a little.

E

Yep fair enough Alyssa.

F

Yeah I mean I think this exercise. um It serves multiple purposes right, so uh it if, if you had somebody who was starting from zero and trying to build up just based off of the spec like it, it improves the spec quality, because you immediately find out all the things that aren't there.

F

That need to be added, and that's like a fine fine thing to do, but also like validates whether um this design provides the all the functionality that some other third party would be looking for, um if they're interested in and interrupt so I think both you know, having both of those things um as benefits is reasonable. At this stage, right I think the eventually like some Independent party being able to implement the thing from the spec is, is a good objective, but that's not where we are today.

E

Yep I'll see you.

H

Remember to press the key button, um so I've been talking to two different independent outfits who were interested in independent implementations of linearized Matrix, basically as a way to plug it into existing non-chat servers, so Mastodon style things where people don't have encrypted DMS, but want to have a sort of simple um easy to implement. Don't have to run a great big full fat Matrix server way of hopping on board, so I can certainly nudge those guys and see if there was appetite to crank out an implementation again clean room purely from the um I.

H

uh The internet draft, without cheating and looking at sweat.matrix.org and I can certainly find folks who can pretend to be independent through within the Matrix and ecosystem. Well, Independence development, at least who could have a play with it as well. I think it sounds great I mean bring it on. The whole point here is to have something that people can Implement independently.

E

C

Sorry I took a second but I managed to get the slides on the top of the new button, um so I wanted to like rewind a little bit here, um so changing topics in case anyone wants to understand the current topic, um someone I someone brought up a few minutes ago. The client server API, um and it reminds me of a question that came up in my mind with regard to linear linearized Matrix um it the picture kind of the architectural picture you showed before had um servers talking to servers and so I believe.

C

A lot of them is based on these Matrix server to server API, but it seems like the server the the follower servers, the the participant servers and as opposed to the hub servers. Those servers aren't really doing much as servers like all the ultimate decision making happens up on the Hub.

C

um So forgiveness is a naive question but like I wonder whether the client server API might actually be a better fit for this sort of simplified use.

E

D

Yeah Tim, if we can go to slide four.

D

uh So this would be the architecture diagram of like how this works so yeah.

C

Sorry, just in just a and just to kind of like elaborate this, and that we have this in front of us like what I'm, what I'm wondering is like these Blue Links from the servers up to the hub would be the The, Matrix, client, server, API or whatever simplified definition of it. We do here and the green links out to the clients would be whatever provider aspects. Whatever provider B speaks um and then job with the server would be just to map those operations up into the interoperable thing.

D

Yeah I'm slightly concerned I, guess that, like there might be sort of um basically terminology overloading going on in a certain sense, um because we did so like the blue lines here between the the providers that is server to server. But there is obviously a client from a network perspective, um so linearized Matrix is based off of the Federation API, um with with all that consideration, The Matrix, client server. Api is honestly like way too complicated to even really consider for for this sort of like for.

D

For me me, we are intentionally leaving it as a like the the link between the green and the blue. um That is we're leaving that up to the provider. Although there are implied constraints like you will need a way to send an event. You will need a way to get key material, that sort of stuff and.

H

I said traffic, so I think um Richard's point is: uh why do we even need a separate SS API to csapi is not a subset of the um uh client server API enough to go and get messages from A to B, and that sympathize with the question, because I can literally remember asking it in my 2013 when we first started Matrix and said: hang on guys, if we're just synchronizing a bunch of events between servers, why do we have a completely different API for synchronizing them from servers to clients, um particularly for the subset that is needed here and I?

H

Think it's right to have completely different flavors of apis in the end between the two, because um you're optimizing for totally different things, the clients basically need to see a partial view of the total data on the server and so, for instance, on The Matrix csapi right now, we're on our fourth generation of same kpi and the whole idea is that it's lazy loads. Only the data that the client needs to see onto the client. So you just do not get any information about other rooms that you're not looking at you don't get.

H

You know most recent messages: it's almost a graphql style feeling where you pull in as rapidly as possible, the bare minimum to have the most responsive, first fastest time to First interactivity app imaginable and that's how Discord in Telegram and the other really really performing mainstream apps are doing it and that's just a fundamentally different problem to how do you synchronize the message backlog on This Server through to a hub to a different server? You don't need any of that lazy, loading or graphql install semantics. It's much more of a message queuing thing.

D

Yeah, the the transport between servers here is um like deliberately as simple as it can be, um which makes it look very similar to a client, server API, um but other. The rough idea is that yeah, you send an event, you receive an event and then that's about.

C

D

C

What I was thinking thinking was was sort of the you know, the the providers here the the non-hub provides servers here. Don't arguably don't need to receive things like um changes to the rules, so it's the authorization State, because.

E

C

Not going to, they don't need to enforce that it's all enforced to have so it seemed like they were more in a client sort of posture, but I can see Matthew's arguments. There's you know other stylistic differences. You know, for instance, a.

H

C

B server they're serving multiple users, and so there are Provisions in the csapi that were doing things specifics. One uses this wouldn't be appropriate. Yeah I could say the argument that there's differences here.

E

D

uh There's also just the aspect of um at the protocol level we're not trying to make decisions for the other providers if that makes sense, so, for instance, while provider B might literally just be a straight through proxy, like it's just not actually looking at the payloads it just assumes provider a there is is properly handling things.

D

um The clients on provider B might want to know that you know a new admin was added or somebody was kicked from the room like just to visually, show it to their users um and so like. While the information creating center for the wire might not be important to the server operation, it still might be important for user experience.

B

G

um I I I, like the idea um and again we we thought about this as well and I mean at least partially. You can have a you, can have overlap between the client or server and server to server API, I. Think right.

G

So in the sending case, um the server is really just essentially a downpipe forwarding the the messages, but in the receiving case, obviously them and the client's server has to do the you know, store and following stuff and obviously there you can have a more sophisticated API during the graphql things that Matthew just mentioned so I mean we don't have to do, go all in on this I guess. But why not? You know uh allowing it partially might also be in the interest of metadata.

G

You know, I mean my own server might not have to learn uh with which other servers I'm talking or well at least not immediately, I, guess or um yeah those sorts of things.

H

Sorry, even a terminology question.

F

H

The end and that what really is the difference between a separate service over API and a client server API um other than almost the prefix on the um API on the URL itself, because um if you have two different ways to send messages, one of them is more message. Query. The other is more um actually I'm trying to think of the differences between sending messages. The the difference on Matrix is that when you send via client server API, you don't need to understand the dag or the linked list or whatever.

H

The underlying data structure is for the room. You just send a message and you've got a transaction and it's not within the context of anything else, whereas when the servers synchronize the messages together, it's in context in linearized, Matrix of a linearized like this or a normal Matrix as a dag, and so the permissions which are applied by the server well, the messages are synchronized in the context of the permissions which are being sent on the server.

H

But what I'm trying to say is that whether you call that one API surface or two separate ones is pretty arbitrary.

I

E

D

uh Sorry, like just briefly on that Matthew um the the way that lagrance Matrix is currently structured as well provider. B doesn't actually need to know anything about the linked list. um It's only provider a that needs to know about the history and enough to fill like the previous events, that sort of stuff, because it'll rebroadcast, basically the correct or final form of whatever the event is out to the remaining servers.

D

uh Eric, you were going to say something.

B

E

G

Yeah I mean okay uh yeah, but no I, guess I'll jump in um yeah I mean that that's kind of what I was getting at.

G

So my understanding was that with linearized Matrix, uh the other servers really don't have to know anything and the whole state is kept on uh on the on the Hub, which is kind of essentially goes to um mimics, what's happening in MLS, where uh the most important stuff is actually happening on the client sides and uh the server is just tracking the state to assist clients in joining or do some verification stuff.

G

So I guess there is no real, uh like reason not to have clients interacting with the product directly. If that's what they want.

E

Yeah like this would be the the.

D

I guess benefit of something like MTP or BMA transport protocol. It doesn't actually say it's a server server, API or a client server API. It just is an API um which is yeah, I, think arguably like in in essence. Yes, linearized metrics could be or characterized as either um but yeah, like maybe I'll, just take it to the to the draft and call it an API.

D

uh Matthew you're still in the queue.

H

F

Okay, so um anyone else have things they want to discuss. Tim and I are going to try to summarize and give you some homework.

F

So um so here's my assessment of of where we are and uh I'll like, propose some next steps and um people can react to those so I feel like we've, had um some productive discussion sort of more in in the requirements and design decision space about the transport protocol in the last few meetings and that's been good um I do think that needs to be synthesized and put out to the working group. So people can um evaluate that and and react to it, and so that's something that I will aim to do.

F

um I think as far as linearized Matrix um there's a couple things. First of all, we got the draft and and the update yesterday so I think the first thing is like people should really sit with this.

F

um You know, take a look see what you think and if you have additional questions or you think there's um you know other aspects that we didn't discuss today that you want to discuss like. Please, please, please send emails to the list and we can have that discussion on the list.

F

um I think we also talked about trying to find some independent um non-matrix based parties who might be interested in um getting going on interop testing with linearized, Matrix and I. Think that would be a very valuable process for us um and as we go forward on both of those things both you know people looking at the draft and also you know potentially getting some interop testing going.

F

um It would be good to move towards eventually and also like comparing against these requirements um and the synthesis from the gate key pure comparison that Matthew shared um those are kind of the things that we need to do.

F

I think to get to the step of saying like do, we want to either adopt linearized Matrix as uh um as a target for the standard that we're supposed to produce for the transfer protocol or do something else, and we still have MTP as as another proposal, um so I'd really like to push forward on that uh over the next like month. Let's say we have an interim in two weeks and we can schedule another one prior to itf117, um but I think you know Gathering.

F

All of that information together will help us get to the point where we can say you know: do we want to do. We want to adapt some protocol and and doesn't meet the set of requirements that we think we've um mostly agreed to so the homework would be read the draft if you're interested in interrupt.

F

Let's get interop testing going, um read the gatekeeper comparison and if you have reactions to that or thoughts about what what is the subset of um of requirements that we should be aiming to send those to the list um and I have homework to synthesize requirements in general and send that to the list as well.

C

H

E

Yeah only thing I'd add is, if there's anything unclear.

D

In the uh in the existing draft, just please let me know either over the list or directly I, don't I don't mind either way. I would love to help people get set up on implementing or interrupt testing.

E

Okie dokie.

F

Great I think that's it Tim anything else.

A

No I don't think so.

F

Excellent thanks. Everyone.

A

E

Thanks, everybody we'll see you next.

A

E