1:11: Eric Rescola (EKR): discussing different ideas about ownership
1:14: PHB: Databases have the idea of zero, one or many. Really large
rooms are different than other use cases, you don't have to consider
them in the same way. In this case, you don't have to worry about the
other cases.
RB: This is a more complicated
1:17: JDR: We aren't in a greenfield environment, it is not in our remit
to tell them how do design the products they ship. Policies and
procedures change across the providers/
EKR: Largely agree with JDR. How does this work with existing services
that provide policies for the room. Remarkably simple if we assume that
there's a designated provider for the room. Provides examples.
RB: It would work that services establish a boundary of acceptable
policies, and clients set polices within that.
Rohan Mahey (RM): A benefit is that users can look at the room policy
(like a spammer, logger, and backstory, whatever reason) and refuse to
join. A clear set of things we can do that allows a policy setting
owner, a client setting up the group, and clients from other providers
choosing from a set of rights from that room.
Daniel Gilmour (DG): Worried about vagueness of policies. Talking at
this level of abstraction difficult. Can we list the types of policies
that we are discussing? The end user should see the types of policies
and who provides this.
Alissa Cooper(AC): How can it be in scope if that's enclosed in a
encrypted envelope?
DG: Example of encrypted envelope, who gets to join the group. If the
room provider provides it, don't they need the ability to see inside the
encrypted envelope? If we think about these things, we need to discuss
looking inside the envelope. But if this is out of scope.
1:27: MH: <<fill in split brains
Rapheal What types of policies can a server actually implment? Open,
closed, moderators, admins.
Pete Resnick: Needs examples of policies that servers can implement
other than message delivery.
RM: A couple: a provider enforcing a member's only group. Popular use
case. In this case, the owning provider can implement a joining style.
Describes. This policy can be described and burned into the group. If
the provider adds someone outside of policy, they can warn, leave, etc.
The point is that there are roles for everyone, but in this case, the
owning provider can do this role. Example 2: Logging. Financial services
provider needs a log of all customer conversation, so there's a logging
bot in each room. An auditor needs their own policy and needs their own
bot. People can decide to not accept this policy (two loggers). Many
providers need this level 2 of commitment.
RB: Let's have a strawman. Single ub for distribution that sets the
policy, then enforces it.
JDR: Better idea about policy is more document, enforced twice. The
document describes the format for policies. Both clients and severs can
implement this policies. Document once, enforce twice.
PHB: I agree, except, that you want to have multiple moderators, and
what is the policy for creating a policy and administrator if everyone
dropped out. The other is, we create a service and then all the
subcribers drop out. You have to worry about this moving from one
service to another. We are using gateways, not protocols.
Basel : Thus the need for a portablity draft.
Missed speaker: 1:42 If we have portability we'll need to deal with
the sort of consistencies from one to other
Warren Jumari: Agreed
MH: Strawman agreed.
RB: Strawman seems to survive. On to the rest of the deck.
(RB) We have to get back to distributing messages flowing.
Shows diagram
Now that we have a hub (yay), this diagram works.
Alternative architecture where subnmissions by passes the servers
JDR: Strongly opposed to bypassing the server. Authentication roles,
etc.
RB: Short circuit this: everything is a server mediated model. Asks for
some consensus.
Uknown: 147: Client connects directly to the hub, looks as if there's
another client on that. The baseline is that client picks that makes it
looks like a client, connects as a hub. Proposed to keep the door open
on enforcing only hub to hub connections.
RM: We can also model this as the hub can do whatever it wants to to
connect to the hub. Inside the provider boxes, not in scope for Mimi.
Other clients could attach to the hub, out of scope. We can do
server-to-server first.
EKR: I want to close the door on this. I want to think about any other
effort, hubs can make their own decision.
Martin Thompson (MT): There's a third model, not explored, not favored,
but interesting. Direct messaging to directly to all of hte service
providers.
MH: Matrix does this, but we aren't pushing this here. Instead, check
out linearilized matrix.
Rphael: I used to have friends defending this, but easy way to do this
with delivery service draft I will propose later.
Consensus: Owning provider as the strawman.
RB: Will send this strawman in the mailing list today.
Client server,not for now.
This is about requirements of the transport protocol of MLS delivery
service.
Overview:
JDR: What's the reason they are calling these async?
RM: The important thing is that you cannot be guaranteed a timely
response.
Implications
EKR: There's no meaningful difference in volume.
Martin Thompson: Batching thing for independt things is problematic.
Just add servers
JDR: Not in favor of the first bullet
Martin Thompson: Avoid bundling requests together. It's very
straightforward
EKR: It used to be expensive, not now
TSH: Batching has real world networking advantages
RM: We'll be discussing lots of this at the bar.
Subset of matrix
Makes it completely self contained
Zero dependency of external matrix
4 different models fo linearized matrix
What's changed?
Standalone draft
Useful feedback
Dual-stack Synapse -> Eigenserver Interop
Android Messages Interop
Where Linearized Matrix fit?
See figure
"CSSSSC"
Room versions define edition of each alg room uses to auth and
distribute messages
Changes to auth rules require new room version
State Events: track meta data for the room, user membershp=ip, name,
Room events: MLS commits
EKR: The room events themselves, there is no ordering, but inside the
room commit event that doesn't have ordering
TR: No
EKR: What is not ordered
TR: Delivery transport side.
TR: Current draft has strict ordering, but there isn't a striick order
of the non commit non MLS messages.
Content Hashes Protect the event from modification as it transits
between servers.
Reference hashes cover content hashes and the event itself.
Signatures guaranteee the originating server did actually create the
event, implicitly covering the reference hash.
The core of linear matrix.
Operates on each and every event that pass through the system
Defines:
Alissa: How does this map in the enterprise case of different power
levels
MH: depends on implementation. Default levels, but configurable
JDR: Does this mean no discord?
MH: Rohans model is different, there is no ordering concept.
RB: The words seem like a descriptive noun, but they are actual
integers?
Conversation devolves into abstract mathematics.
MH: Explains the existing approach, modeled after ACLs
Alyssa: What do we do in the case of systems that don't have this strict
rank ordering
MH: This is solved, as you can support both.
RM: I think I see an escape mechanism to add discord stuff, and
basically that you don't have persmissions at all
Room: Looking forward to draft.
Defined transport is inspired by 2014-era design, to be replaced with
gRPC in an upcoming draft.
Currently HTTPS+JSON
JDR: Let's stay with HTTS+JSON and not start a war
Basel: HTTPS +JSON is great, not the most scalable thing. We are looking
at more of a binary approach. In favor of a Grpc or something similar.
Martin: There are other formats than JSON if performance is an issue.
CBOR.
Rafeal: We have been
Linearized matrix layers MLS on top for encryption. Supports double
ratchet.
Currently uses a mostly server-side model. Membership is tracked by the
server, but user mesages are E2E encrypted.
Single biggest question for the working group.
MT: I heard a long series of arguments making MLS required. Maybe only.
MH: That means it's forever, which might be genius, maybe.
RB: We should have stapled TLS to HTTP sooner.
JDR: Still deciding if this is genius or crazy. We should enumerate the
pros and cons. We need to fully flesh this out.
MH: There might be room for both.
Raphael: We have to go through security first. Took us five years on
MLS, a good starting point, doesn't preclude
EKR: Ditto. The properties that made it hard to decouple HTTP and TLS,
WebRTC followed by quic. If coupling gets us more security, then that's
a good enough reason.
PHB: I disagree on the coupling. Allow people to establish different
ways to managing the security goals, etc. which are not always the same.
Please don't weld it together. End to end,good, but no one true way.
Konrad: We shouldn't bake that in
Rohan: If we don't bake this in, then we have to have a bunch of auth
rules, then we can no longer rely on the nice features of it.