[{"author": "Daniel Gillmor", "text": "

are we meeting here, or will there be an ietf-117 subchannel?

", "time": "2023-07-24T20:04:19Z"}, {"author": "Jonathan Lennox", "text": "

This is what's reflected in the meetecho chat

", "time": "2023-07-24T20:04:43Z"}, {"author": "Daniel Gillmor", "text": "

there we go, thanks @Jonathan Lennox

", "time": "2023-07-24T20:04:56Z"}, {"author": "Phillip Hallam-Baker", "text": "

Not like that. Rooms are owned by participants. Not servers.

", "time": "2023-07-24T20:09:08Z"}, {"author": "Martin Thomson", "text": "

I wonder if anyone who was involved in the P2P messaging stuff at Skype is here and can comment on whether it makes sense to have a distributed \"owner\"

", "time": "2023-07-24T20:10:00Z"}, {"author": "Ross Schulman", "text": "

Is there a video feed for today's meeting? I can listen to the audio stream but I am getting \"Unauthorized\" when I try to log into the video stream.

", "time": "2023-07-24T20:10:08Z"}, {"author": "Alissa Cooper", "text": "

@Ross maybe reload your web client? video is streaming from the room in the full client.

", "time": "2023-07-24T20:10:41Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Ross, the slides are about authorization...

", "time": "2023-07-24T20:10:42Z"}, {"author": "Nick Doty", "text": "

I'm seeing video streams and slides in meetecho here: https://meetecho.ietf.org/conference/?group=mimi

", "time": "2023-07-24T20:10:58Z"}, {"author": "Ross Schulman", "text": "

Chrome and Firefox are giving me the same. Its ok, though I'll just listen!

", "time": "2023-07-24T20:12:21Z"}, {"author": "Pete Resnick", "text": "

@Rohan Mahy I would still put sequencing arbitration in the \"hub\" category. It's not clear that such arbitration is a \"policy\" function.

", "time": "2023-07-24T20:13:42Z"}, {"author": "Konrad Kohbrok", "text": "

Sequencing could be another type of ownership.

", "time": "2023-07-24T20:14:49Z"}, {"author": "Pete Resnick", "text": "

Possibly.

", "time": "2023-07-24T20:15:44Z"}, {"author": "Andrew Sullivan", "text": "

You kind of have to permit them to have different opinions about what the policy should be, because the competing \"owners\" could be under incompatible legal/regulatory regimes that require enforcement of the minimal compatible subset, no?

", "time": "2023-07-24T20:17:41Z"}, {"author": "Pete Resnick", "text": "

There's a category of stuff (which seems to me to include sequencing) where no server should care which of the servers takes on the function. Then there are policies, where servers might disagree.

", "time": "2023-07-24T20:17:55Z"}, {"author": "Pete Resnick", "text": "

Are there policies envisioned where the implementation of the policy is other than \"deliver the message/don't deliver the message\"?

", "time": "2023-07-24T20:19:42Z"}, {"author": "Phillip Hallam-Baker", "text": "

The MIMI charter assumes we are building gateways. The WG participants assume we are building gateways.

\n

And yet, that is what email was before SMTP reached critical mass and suddenly everything else was first legacy and then obsolete.

", "time": "2023-07-24T20:20:26Z"}, {"author": "Travis Ralston", "text": "

There's some policies related to features as well. For example, whether it's possible to \"knock\" on a room and whether that action was legal.

", "time": "2023-07-24T20:21:06Z"}, {"author": "Nick Doty", "text": "

wouldn't it be possible for servers to have incompatible policies? Server B can block all messages from Person X, even if Server A owns the room and allows Person X

", "time": "2023-07-24T20:22:13Z"}, {"author": "Alissa Cooper", "text": "

Rohan just addressed this -- the way you manage through incompatible policies in the presence of an owning server is having clients of non-owning servers not able to join if the non-owning server's is incompatible with the policy chosen by the client of the owning server.

", "time": "2023-07-24T20:23:49Z"}, {"author": "Konrad Kohbrok", "text": "

Are we assuming that policies are fixed for the lifetime of the room?

", "time": "2023-07-24T20:24:13Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Nick, everyone can have whatever limitations they like on day 1. But then they will have to explain to their users why they don't do X. And it is usually easier (and cheaper) to write code than explanations.

", "time": "2023-07-24T20:24:29Z"}, {"author": "Jonathan Lennox", "text": "

Does this require that owning services describe their policies honestly?

", "time": "2023-07-24T20:24:31Z"}, {"author": "Konrad Kohbrok", "text": "

Whoever does the sequencing of messages can decide not to accept a commit and not tell anyone that that happened. I don't think there is a lot we can do about that.

", "time": "2023-07-24T20:25:31Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Konrad, surely we are going to need policies of the sort 'everyone from the Marketing Group'. Which need to be standing policies.

", "time": "2023-07-24T20:25:37Z"}, {"author": "Nick Doty", "text": "

+1 for user transparency into how the room is administered

", "time": "2023-07-24T20:26:01Z"}, {"author": "Jonathan Rosenberg", "text": "

You could have policies set by the hub, which are enforced by clients (because they are inside the envelope) by distributing the policy to the clients from the hub

", "time": "2023-07-24T20:27:00Z"}, {"author": "Konrad Kohbrok", "text": "

@Phillip I agree. But do we also need to be able to change policies as well? At least in my mind that would complicate things.

", "time": "2023-07-24T20:27:02Z"}, {"author": "Konrad Kohbrok", "text": "

The easiest would probably be to put the policy as an extension into the MLS group state, which means that clients know and agree on the policy.

", "time": "2023-07-24T20:27:46Z"}, {"author": "Martin Thomson", "text": "

If the rule is \"kick users who mention nazis\" (Godwin's law), then the enforcer needs to be in the room. If you want that to be enforced before the message is forwarded, then the enforcer also needs to receive the message before forwarding. Totally doable, but maybe not desirable.

", "time": "2023-07-24T20:29:02Z"}, {"author": "Phillip Hallam-Baker", "text": "

Umm, the server has no idea who is in the group in my chat protocol.

", "time": "2023-07-24T20:29:07Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Martin, the way I enforce that in an E2E scheme is every message is moderated. So Alice makes a post, Bob's client checks for policy compliance and if so, tells the service to redistribute.

", "time": "2023-07-24T20:30:48Z"}, {"author": "Martin Thomson", "text": "

How do you prevent Carol from seeing the message then? Is Bob a moderator that gets the message first?

", "time": "2023-07-24T20:32:04Z"}, {"author": "Konrad Kohbrok", "text": "

@Phillip But then wouldn't Bob have to be online at the moment the message is distributed?

", "time": "2023-07-24T20:32:10Z"}, {"author": "Andrew Morgan", "text": "

If servers want to be able to evaluate the policies of other providers, then surely we do need a set of common policy definitions.

", "time": "2023-07-24T20:32:45Z"}, {"author": "Phillip Hallam-Baker", "text": "

@martin, the message is initially encrypted so only the moderator's clients can decrypt it. Then it is re-encrypted under the room key.

", "time": "2023-07-24T20:33:12Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Konrad, If you need that level of moderation, there will have to be at least one party in the conversation that can decrypt the message prior to general release. It does not necessarily mean Bob having to click 'approve' 'approve', there can be automation.

", "time": "2023-07-24T20:34:46Z"}, {"author": "Konrad Kohbrok", "text": "

:+1:\ud83c\udffb

", "time": "2023-07-24T20:35:04Z"}, {"author": "Pete Resnick", "text": "

Maybe it's because I don't understand available MLS mechanisms, but I'm still not clear how \"closed/open\" gets implemented (without being inside the encryption envelope). (Logging seems like just another client, not a policy enforceable by the server.)

", "time": "2023-07-24T20:39:21Z"}, {"author": "Martin Thomson", "text": "

isn't enforce thrice?

", "time": "2023-07-24T20:40:03Z"}, {"author": "Daniel Gillmor", "text": "

That's a policy that makes it possible to block messages that should not have been allowed. But it doesn't let the clients accept a message that the server decided to block against policy.

", "time": "2023-07-24T20:40:07Z"}, {"author": "Martin Thomson", "text": "

that is, don't the non-owning servers have a potential role in enforcement?

", "time": "2023-07-24T20:40:16Z"}, {"author": "Daniel Gillmor", "text": "

@Martin Thomson right, but there's an asymmetry between block and accept.

", "time": "2023-07-24T20:40:42Z"}, {"author": "Daniel Gillmor", "text": "

any enforcer can block, but all enforcers must accept

", "time": "2023-07-24T20:41:00Z"}, {"author": "Nick Doty", "text": "

be conservative in what you enforce before sending?

", "time": "2023-07-24T20:41:05Z"}, {"author": "Travis Ralston", "text": "

@Pete Resnick MLS supports a way for clients to say \"I'm adding this person, but you can't see the key material for that\" (and it's authenticated)

", "time": "2023-07-24T20:41:06Z"}, {"author": "Martin Thomson", "text": "

@Daniel Gillmor not following you entirely

", "time": "2023-07-24T20:41:17Z"}, {"author": "Martin Thomson", "text": "

blocking what? accepting what?

", "time": "2023-07-24T20:41:26Z"}, {"author": "Daniel Gillmor", "text": "

if the server blocks a message from distribution (based on whatever policy), then the receiving client can't tell that they've deviated from the published policy.

", "time": "2023-07-24T20:41:53Z"}, {"author": "Martin Thomson", "text": "

ah, good point, but I don't think that there is much recourse for a client in that position

", "time": "2023-07-24T20:42:11Z"}, {"author": "Daniel Gillmor", "text": "

aren't all clients in that position?

", "time": "2023-07-24T20:42:23Z"}, {"author": "Martin Thomson", "text": "

yeah, you are somewhat dependent on your server passing your messages in

", "time": "2023-07-24T20:42:40Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Martin, what about the UK hub which filters everything for OSB compliance?

", "time": "2023-07-24T20:42:56Z"}, {"author": "Pete Resnick", "text": "

@Daniel Gillmor If the server is outside the envelope, on what policy could it block a message?

", "time": "2023-07-24T20:42:59Z"}, {"author": "Jonathan Rosenberg", "text": "

To be clear - i was specifying a slight change to Richard's strawman - that we don't say \"enforced by the server\" but rather \"enforced by the server and client\"

", "time": "2023-07-24T20:43:01Z"}, {"author": "Martin Thomson", "text": "

for a case where your server isn't the hub/owner, then you are also subject to rules at the owning server

", "time": "2023-07-24T20:43:05Z"}, {"author": "Benjamin Schwartz", "text": "

It's certainly possible to make moderation work by flagging, and make selective removal of messages impossible

", "time": "2023-07-24T20:43:05Z"}, {"author": "Daniel Gillmor", "text": "

@Pete Resnick maybe based on timing, provenance, or size?

", "time": "2023-07-24T20:43:26Z"}, {"author": "Benjamin Schwartz", "text": "

What does having a hub do to migration of rooms across providers?

", "time": "2023-07-24T20:45:39Z"}, {"author": "Martin Thomson", "text": "

there is another one, wherein messages are sent from the home server of the client directly to all servers - though that would depend on the state of the being group known

", "time": "2023-07-24T20:46:37Z"}, {"author": "Daniel Gillmor", "text": "

@Martin Thomson that's the other CSSC (but the S's are different S's)

", "time": "2023-07-24T20:47:45Z"}, {"author": "Nick Doty", "text": "

\"client-server API\" sounded to me like an API for each client to talk to their home server ... so that there can be interoperable clients that can work with different server providers

", "time": "2023-07-24T20:48:05Z"}, {"author": "Pete Resnick", "text": "

If it looks just like another hub connecting, then it is a hub.

", "time": "2023-07-24T20:48:17Z"}, {"author": "Martin Thomson", "text": "

right, whch addresses JDR's concern, but creates a state consistency issue

", "time": "2023-07-24T20:48:19Z"}, {"author": "Pete Resnick", "text": "

s/hub/server

", "time": "2023-07-24T20:48:36Z"}, {"author": "Pete Resnick", "text": "

A single-client server is fine. An open access server that lets random clients join is fine (well, bad, but fine as far as protocol goes). CSSC is bad.

", "time": "2023-07-24T20:51:28Z"}, {"author": "Daniel Gillmor", "text": "

the CSSSC model is the same as an SMTP mailing list -- we have a lot of history of dealing with that.

", "time": "2023-07-24T20:52:49Z"}, {"author": "Konrad Kohbrok", "text": "

The CSSC model can also prevent leaking to my own server to which other server(s) I'm talking. So if at some point we discuss metadata, that might be an interesting consideration.

", "time": "2023-07-24T20:55:55Z"}, {"author": "Konrad Kohbrok", "text": "

*talking to

", "time": "2023-07-24T20:56:11Z"}, {"author": "Harald Alvestrand", "text": "

I keep hearing this word \"simultaneously\" - I don't understand what it means....

", "time": "2023-07-24T20:59:17Z"}, {"author": "Murray Kucherawy", "text": "

It's all about timing.

", "time": "2023-07-24T21:00:38Z"}, {"author": "Martin Thomson", "text": "

@Harald Alvestrand it's a tic, but I hope you understand the concept of race conditions

", "time": "2023-07-24T21:00:40Z"}, {"author": "Richard Barnes", "text": "

Strawman for consensus

\n", "time": "2023-07-24T21:01:17Z"}, {"author": "Daniel Gillmor", "text": "

@Konrad Kohbrok won't the backflow in CSSC (of your own messages in the chat to your own client) make it clear to your server that you're involved in a chat with that server?

", "time": "2023-07-24T21:01:33Z"}, {"author": "Benjamin Schwartz", "text": "

@Richard Barnes Is the policy envelope \"policy that can be applied from outside the encryption envelope\"?

", "time": "2023-07-24T21:01:58Z"}, {"author": "Martin Thomson", "text": "

@Richard Barnes do you want to add that clients (or maybe even other servers) can request that the policy be changed by the owning provider?

", "time": "2023-07-24T21:02:11Z"}, {"author": "Travis Ralston", "text": "

@Richard Barnes can we get definitions added to ralston-mimi-terminolgy please? :innocent:

", "time": "2023-07-24T21:02:36Z"}, {"author": "Konrad Kohbrok", "text": "

@Daniel Gillmor True. It certainly depends on the specifics of the fan-out protocol. But at least there's the possibility.

", "time": "2023-07-24T21:02:39Z"}, {"author": "Martin Thomson", "text": "

@Travis Ralston isn't that your responsibility? I'm assuming that the name match is no coincidence.

", "time": "2023-07-24T21:03:09Z"}, {"author": "Richard Barnes", "text": "

@Travis Ralston - Yes, though I think we need to elaborate -terminology into -architecture

", "time": "2023-07-24T21:03:42Z"}, {"author": "Benjamin Schwartz", "text": "

I think we should consider keying each message from a hash of the previous message, so that messages cannot be removed from the room once admitted. Then we can be sure that all servers are applying a strictly consistent view of the \"policy envelope\"

", "time": "2023-07-24T21:03:59Z"}, {"author": "Richard Barnes", "text": "

@Benjamin Schwartz - No, that means \"the range of acceptable policies\"

", "time": "2023-07-24T21:04:03Z"}, {"author": "Travis Ralston", "text": "

@Martin Thomson the draft is largely treated as a WG item without being a WG item (yet?). (it is technically my problem though, yes)

", "time": "2023-07-24T21:04:09Z"}, {"author": "Richard Barnes", "text": "

@Martin Thomson - That's what i mean by \"Clients specify the details of the policy\". I don't think clients can request changes to the policy envelope that the owning provider sets

", "time": "2023-07-24T21:04:50Z"}, {"author": "Konrad Kohbrok", "text": "

Benjamin Schwartz said:

\n
\n

I think we should consider keying each message from a hash of the previous message, so that messages cannot be removed from the room once admitted. Then we can be sure that all servers are applying a strictly consistent view of the \"policy envelope\"

\n
\n

MLS already does that, at least for handshake-type messages. Application type messages are trickier, because they are not ordered.

", "time": "2023-07-24T21:04:58Z"}, {"author": "Martin Thomson", "text": "

@Richard Barnes thanks, that helps

", "time": "2023-07-24T21:05:24Z"}, {"author": "Cullen Jennings", "text": "

I agree with Rohan on we need a design that facilitates batch processing of large number of messages.

", "time": "2023-07-24T21:05:52Z"}, {"author": "Raphael Robert", "text": "

Konrad Kohbrok said:

\n
\n

Benjamin Schwartz said:

\n
\n

I think we should consider keying each message from a hash of the previous message, so that messages cannot be removed from the room once admitted. Then we can be sure that all servers are applying a strictly consistent view of the \"policy envelope\"

\n
\n

MLS already does that, at least for handshake-type messages. Application type messages are trickier, because they are not ordered.

\n
\n

And for application messages we potentially have the AppAck extension.

", "time": "2023-07-24T21:05:53Z"}, {"author": "Richard Barnes", "text": "

@Benjamin Schwartz The standard approach to this is a \"causality DAG\", where each message includes a hash of its predecessors (not plural, though, bc async). It could be added on top of MLS, in principle.

", "time": "2023-07-24T21:06:13Z"}, {"author": "Benjamin Schwartz", "text": "

@Richard Barnes Not just including a hash, but being keyed off of that hash, so that the message is not decipherable without its preceding messages. That ensures that servers don't apply differing policies, as that would immediately render the room unusable.

", "time": "2023-07-24T21:07:42Z"}, {"author": "Benjamin Schwartz", "text": "

But this is mostly a detail. My point is that we should be cautious about providing servers with the technical ability to implement differing policies.

", "time": "2023-07-24T21:08:52Z"}, {"author": "Pete Resnick", "text": "

IMAP has been doing this asynchronous stuff just fine for a long time.

", "time": "2023-07-24T21:11:05Z"}, {"author": "Pete Resnick", "text": "

We know how to do this stuff without the client \"helping\".

", "time": "2023-07-24T21:11:26Z"}, {"author": "Daniel Gillmor", "text": "

trouble is that a DAG represents the actual causality pretty well. but it can't be easily be displayed in a way that humans understand.

", "time": "2023-07-24T21:11:31Z"}, {"author": "Pete Resnick", "text": "

Submarines ought not batch at the upper layer. They should buffer at the lower layer.

", "time": "2023-07-24T21:13:52Z"}, {"author": "Daniel Gillmor", "text": "

(note that \"represents the actual causality pretty well\" only works for messages where the parentage relationship is cryptographically strong pointers (e.g., digests). Otherwise, there is the possibility of maliciously (or accidentally) injected cycles, at which point it's no longer a DAG.

", "time": "2023-07-24T21:13:52Z"}, {"author": "Benjamin Schwartz", "text": "

@Daniel Gillmor I don't think we need the DAG to be user-visible at all. The idea I'm floating is that if a message reaches some users but not others, this quickly breaks the room. That allows servers to say \"sorry, I don't have the technical ability to drop certain messages\".

", "time": "2023-07-24T21:14:00Z"}, {"author": "Martin Thomson", "text": "

I will also point out that batching is harder to specify and implement, which for a questionable performance gain is probably not worth it

", "time": "2023-07-24T21:14:56Z"}, {"author": "Daniel Gillmor", "text": "

Pete Resnick said:

\n
\n

Submarines ought not batch at the upper layer. They should buffer at the lower layer.

\n
\n

upper meaning above the surface of the ocean?

", "time": "2023-07-24T21:14:58Z"}, {"author": "Konrad Kohbrok", "text": "

@Benjamin Schwartz This is already built into MLS. At least for messages the server can read. For the others, we might be able to build something like @Richard Barnes suggested and, for example, feed it into the MLS key schedule.

", "time": "2023-07-24T21:16:35Z"}, {"author": "Benjamin Schwartz", "text": "

@Konrad Kohbrok Yes, I'm talking about the end-to-end application messages.

", "time": "2023-07-24T21:17:17Z"}, {"author": "Martin Thomson", "text": "

isn't a linearized matrix a vector?

", "time": "2023-07-24T21:17:51Z"}, {"author": "Harald Alvestrand", "text": "

Batching can be problematic if the server you're talking to is in fact a distributor for a set of backend servers - it has to break up the batch, and forcing it to reassemble the responses is a large architectural burden. If the operations in the batch can be answered directly and separately, the batching is no more useful than sending all the messages end-to-end on a (QUIC, I assume) connection.

", "time": "2023-07-24T21:17:59Z"}, {"author": "Martin Thomson", "text": "

that you might remove encryption entirely seems like an undesirable \"feature\"

", "time": "2023-07-24T21:21:09Z"}, {"author": "Andrew Morgan", "text": "

I largely agree, but in some private deployments, potentially with very low-bandwidth or high-latency requirements, you may not want encryption.

", "time": "2023-07-24T21:22:14Z"}, {"author": "Britta Hale", "text": "

@Harald Alvestrand That depends on the computational power of respective points (clients vs distributor, etc.) and potentially bandwidth differences as well.

", "time": "2023-07-24T21:22:47Z"}, {"author": "Daniel Gillmor", "text": "

@Andrew Morgan perhaps in that environment MLS/MIMI is not the appropriate technology choice.

", "time": "2023-07-24T21:22:57Z"}, {"author": "Martin Thomson", "text": "

Can we do CSSSC over ATSSS?

", "time": "2023-07-24T21:24:01Z"}, {"author": "Richard Barnes", "text": "

Matthew is operating at about 0.8 EKR

", "time": "2023-07-24T21:24:01Z"}, {"author": "Benjamin Schwartz", "text": "

\"h2c\" (cleartext HTTP/2) seems like a good precedent here: the unencrypted form of the protocol does exist for testing and unusual cases, but in practice it is not possible to deploy it for public use.

", "time": "2023-07-24T21:24:16Z"}, {"author": "Richard Barnes", "text": "

@Benjamin Schwartz that's exactly what i enqueued to say

", "time": "2023-07-24T21:24:28Z"}, {"author": "Martin Thomson", "text": "

In retrospect, a great number of people regard \"h2c\" as a mistake. At best, it was a waste of effort.

", "time": "2023-07-24T21:24:58Z"}, {"author": "Andrew Morgan", "text": "

Going back to the room policy agreement discussion, if someone does try it in the wild you can refuse to participate in a group that does not have encrypted messaging.

", "time": "2023-07-24T21:25:25Z"}, {"author": "Nick Doty", "text": "

is there any significant cost to creating a new room? banning spammers one by one and having to create a new room every time could become a frequent operation

", "time": "2023-07-24T21:25:30Z"}, {"author": "Martin Thomson", "text": "
\n

The \"h2c\" string was previously used as a token for use in the HTTP Upgrade mechanism's Upgrade header field (Section 7.8 of [HTTP]). This usage was never widely deployed and is deprecated by this document. The same applies to the HTTP2-Settings header field, which was used with the upgrade to \"h2c\".

\n
\n

-- https://datatracker.ietf.org/doc/html/rfc9113#section-3.1-2.2.1

", "time": "2023-07-24T21:25:53Z"}, {"author": "Richard Barnes", "text": "

@Nick Doty seems like a local provider policy decision

", "time": "2023-07-24T21:26:03Z"}, {"author": "Konrad Kohbrok", "text": "

MLS is extensible. You can always extend it with a proprietary extension that defines an unencrypted application message.

", "time": "2023-07-24T21:26:24Z"}, {"author": "Richard Barnes", "text": "

not helpful @Konrad Kohbrok :)

", "time": "2023-07-24T21:26:38Z"}, {"author": "Martin Thomson", "text": "

@Konrad Kohbrok but you should not do that

", "time": "2023-07-24T21:26:38Z"}, {"author": "Raphael Robert", "text": "

The MLSWG would strongly push back on such an extension I think

", "time": "2023-07-24T21:27:32Z"}, {"author": "Daniel Gillmor", "text": "

we have the same argument all the time in SSH (\"what about authenticated cleartext for ham radio operators?\") and TLS itself (\"why not an authenticated only mode with NULL encryption algorithm?\"). let's just not.

", "time": "2023-07-24T21:27:37Z"}, {"author": "Martin Thomson", "text": "

Just as the TLS WG now pushes back against NULL ciphersuites

", "time": "2023-07-24T21:27:47Z"}, {"author": "Konrad Kohbrok", "text": "

That's why I said _proprietary_.

", "time": "2023-07-24T21:28:11Z"}, {"author": "Raphael Robert", "text": "

Richard Barnes said:

\n
\n

Matthew is operating at about 0.8 EKR

\n
\n

And now EKR operates at 1.1 EKR

", "time": "2023-07-24T21:33:59Z"}, {"author": "Martin Thomson", "text": "

Let's be clear, inflation has really gotten to the EKR as a unit of measure. One 2023 EKR is worth far less than a 2011 EKR.

", "time": "2023-07-24T21:35:38Z"}, {"author": "Martin Thomson", "text": "

this is making a really good case for MLS being the only option

", "time": "2023-07-24T21:37:14Z"}, {"author": "Andrew Morgan", "text": "

reference_hash = hash(redact(event))

\n

\"unimportant things\" like message text is removed when the event is redacted. The content hash is kept, and feeds into the reference hash.

", "time": "2023-07-24T21:37:18Z"}, {"author": "Nick Doty", "text": "

please use the mic

", "time": "2023-07-24T21:37:32Z"}, {"author": "Ted Hardie", "text": "

At level 100, you can protest your rank, and nothing else.

", "time": "2023-07-24T21:38:19Z"}, {"author": "Jonathan Rosenberg", "text": "

So auth rules in linear matrix are - linear

", "time": "2023-07-24T21:38:52Z"}, {"author": "Benjamin Schwartz", "text": "

This seems excessively linear

", "time": "2023-07-24T21:38:53Z"}, {"author": "Benjamin Schwartz", "text": "

Also I believe Telegram has more flexibility than this.

", "time": "2023-07-24T21:39:17Z"}, {"author": "Martin Thomson", "text": "

attribute-based authorization seems more flexible than this

", "time": "2023-07-24T21:39:28Z"}, {"author": "Jonathan Rosenberg", "text": "

Did I hear Matthew say that this concept can be mapped to a bunch of systems but NOT Discord?

", "time": "2023-07-24T21:39:31Z"}, {"author": "Daniel Gillmor", "text": "

@Jonathan Rosenberg yes, that's what he said

", "time": "2023-07-24T21:39:43Z"}, {"author": "Jonathan Rosenberg", "text": "

well, that seems like a problem

", "time": "2023-07-24T21:39:52Z"}, {"author": "Martin Thomson", "text": "

that is, can add person, can remove person, etc...

", "time": "2023-07-24T21:40:05Z"}, {"author": "Daniel Gillmor", "text": "

many things have more flexibility than linear levels

", "time": "2023-07-24T21:40:21Z"}, {"author": "Daniel Gillmor", "text": "

the question is do we need the flexibility

", "time": "2023-07-24T21:40:31Z"}, {"author": "Martin Thomson", "text": "

well, usually you have the ability to add some at a lower level than the ability to kick someone, but I can imagine a moderator role that only has the ability to kick

", "time": "2023-07-24T21:41:06Z"}, {"author": "Mallory Knodel", "text": "

100 will never be as awesome as 777

", "time": "2023-07-24T21:41:35Z"}, {"author": "Nick Doty", "text": "

@chairs, will you ask Matthew to use the mic, please?

", "time": "2023-07-24T21:41:57Z"}, {"author": "Thom Wiggers", "text": "

power levels should at least go over 9000

", "time": "2023-07-24T21:43:33Z"}, {"author": "Pete Resnick", "text": "

Nobody loves fixed-point anymore.

", "time": "2023-07-24T21:44:00Z"}, {"author": "Andrew Morgan", "text": "

we have seen people often set the max power level in matrix to 9001

", "time": "2023-07-24T21:44:04Z"}, {"author": "Mohammad Al Abbadi", "text": "

The ones will overcome

", "time": "2023-07-24T21:45:02Z"}, {"author": "Daniel Gillmor", "text": "

rlidwka

", "time": "2023-07-24T21:45:18Z"}, {"author": "Mallory Knodel", "text": "

Enumerating the capabilities is more helpful than defining categories

", "time": "2023-07-24T21:45:36Z"}, {"author": "Martin Thomson", "text": "

maybe we could have a linearized matrix of bits instead of an integer

", "time": "2023-07-24T21:46:01Z"}, {"author": "Martin Thomson", "text": "

rank ordering might be determined by $\\Sum_i bit_i * 2^i$

", "time": "2023-07-24T21:46:43Z"}, {"author": "Raphael Robert", "text": "

qubits could provide even more flexibility

", "time": "2023-07-24T21:48:43Z"}, {"author": "Martin Thomson", "text": "

maybe the way to deal with different provider capabilities is to provide a function supported([capabilities]) -> bool that tells client whether a given expression can be supported by the system

", "time": "2023-07-24T21:48:54Z"}, {"author": "Ted Hardie", "text": "

I left the queue here, but I was going to point out that in any ordinal system you can't assume that the two different systems have the same \"power\" unless there is a mapping to a capability. A brigadier general has more power than an EVP, even if both are 99s in their respective systems. So I think Alissa's point is true even if you have two different, linked systems using linearized powers.

", "time": "2023-07-24T21:48:57Z"}, {"author": "Richard Barnes", "text": "

yeah can we just enumerate capabilities here? there are not that many

", "time": "2023-07-24T21:49:30Z"}, {"author": "Darrel Miller", "text": "

It is not clear to me what the value of the ranking is, other than a shortcut to determining capabilities that then brings a host of limitations.

", "time": "2023-07-24T21:49:56Z"}, {"author": "Andrew Morgan", "text": "

https://www.ietf.org/rfc/rfc9232.html

", "time": "2023-07-24T21:51:14Z"}, {"author": "Martin Thomson", "text": "

gRPC will probably result in some strong reactions

", "time": "2023-07-24T21:51:29Z"}, {"author": "Daniel Gillmor", "text": "

Richard Barnes said:

\n
\n

yeah can we just enumerate capabilities here? there are not that many

\n
\n

can we get consensus among the would-be interoperators of an exhaustive list of capabilities?

", "time": "2023-07-24T21:53:12Z"}, {"author": "Richard Barnes", "text": "

how many layers of the stack can we reinvent at once?

", "time": "2023-07-24T21:53:21Z"}, {"author": "Benjamin Schwartz", "text": "

I think \"add/remove users but not read\" admin bots and \"read but not add/remove users\" ordinary user roles are both going to be valuable, so the space is not linearizable.

", "time": "2023-07-24T21:53:26Z"}, {"author": "Richard Barnes", "text": "

@Daniel Gillmor the nice thing about using capabilities is that you can extend the set of capabilities, and not have to touch all the combos

", "time": "2023-07-24T21:53:49Z"}, {"author": "Daniel Gillmor", "text": "

not to mention \"add but not kick\" and \"kick but not add\"

", "time": "2023-07-24T21:53:58Z"}, {"author": "Daniel Gillmor", "text": "

Richard Barnes said:

\n
\n

Daniel Gillmor the nice thing about using capabilities is that you can extend the set of capabilities, and not have to touch all the combos

\n
\n

the challenge here is how to deploy a new capability across multiple interoperating providers

", "time": "2023-07-24T21:54:27Z"}, {"author": "Martin Thomson", "text": "

TLS grammar is NOT extremely compact

", "time": "2023-07-24T21:54:36Z"}, {"author": "Martin Thomson", "text": "

it's quite wasteful in a few ways

", "time": "2023-07-24T21:54:47Z"}, {"author": "Raphael Robert", "text": "

Martin Thomson said:

\n
\n

TLS grammar is NOT extremely compact

\n
\n

Forgot say with the QUIC variable length encoding

", "time": "2023-07-24T21:55:19Z"}, {"author": "Konrad Kohbrok", "text": "

We have it in the DS draft because MLS already uses it. But we're open to other options.

", "time": "2023-07-24T21:55:46Z"}, {"author": "Darrel Miller", "text": "

Does anyone have any pointers to perf comparisons between gRPC and HTTP/3 using a binary payload? Most comparisons I have seen compare gRPC vs HTTP/1.1 + uncompressed JSON.

", "time": "2023-07-24T21:57:37Z"}, {"author": "Martin Thomson", "text": "

binary HTTP (RFC 9292) has a very compact form; you can generate a 2 byte response. Requests are a tiny bit bigger, but still they can be small. HTTP/3 has a little more overhead, but it also has header compression.

", "time": "2023-07-24T22:00:45Z"}, {"author": "Mohammad Al Abbadi", "text": "

Featured bug

", "time": "2023-07-24T22:00:58Z"}, {"author": "Mallory Knodel", "text": "

This shows that maybe that Matrix interoperates with MIMI but it\u2019s likely not the architecture that underpins it? Useful to arrive at that

", "time": "2023-07-24T22:02:12Z"}, {"author": "Mallory Knodel", "text": "

And really useful to have this fully built out set of examples for discussion

", "time": "2023-07-24T22:03:02Z"}, {"author": "Daniel Gillmor", "text": "

it seems much more complicated to try to reason about many various parts moving together than it does to reason about a single particular widely-analyzed protocol at the core of the upper layers.

", "time": "2023-07-24T22:03:21Z"}, {"author": "Richard Barnes", "text": "

@Mallory Knodel - I think we might end up slicing Matrix in two, with some parts above the E2EE line and some parts below

", "time": "2023-07-24T22:04:15Z"}, {"author": "Richard Barnes", "text": "

strong diagree with @Phillip Hallam-Baker here. if we need different crypto in 10 years, we can make a new thing

", "time": "2023-07-24T22:05:17Z"}, {"author": "Raphael Robert", "text": "

MLS is in the charter, so we would have to recharter if we want to change that

", "time": "2023-07-24T22:06:12Z"}]