[{"author": "Pete Resnick", "text": "

Either way, you do have to stop sharing the old version and then share the new version.

", "time": "2023-03-30T00:30:03Z"}, {"author": "Pete Resnick", "text": "

(Happened to me earlier in the week.)

", "time": "2023-03-30T00:30:23Z"}, {"author": "Richard Barnes", "text": "

:mask::thumbsup:

", "time": "2023-03-30T00:31:11Z"}, {"author": "Pete Resnick", "text": "

(The boring part where the notetakers can take a break because Rohan is presenting stuff for all the people too lazy to read the draft.)

", "time": "2023-03-30T00:42:40Z"}, {"author": "Tim Geoghegan", "text": "

+1 to Daniel. Duplicating information just seems like an opportunity for implementations to get it wrong.

", "time": "2023-03-30T00:47:38Z"}, {"author": "Richard Barnes", "text": "

HTTP Host is distinct from SNI...

", "time": "2023-03-30T00:49:58Z"}, {"author": "Tim Geoghegan", "text": "

If you were designing TLS and HTTP together today, would you include both of those things?

", "time": "2023-03-30T00:50:30Z"}, {"author": "Richard Barnes", "text": "

Also, the MLS credential might authenticate multiple identities, which means the application layer needs to present a name to be authenticated

", "time": "2023-03-30T00:50:36Z"}, {"author": "Jonathan Lennox", "text": "

This seems more similar to the difference between SMTP Envelope-From and RCPT, vs. RFC822 From: and To:

", "time": "2023-03-30T00:51:10Z"}, {"author": "Harald Alvestrand", "text": "

I was actually thinking that a recorded from and to was analogous to RFC 822 Received:

", "time": "2023-03-30T00:52:17Z"}, {"author": "Harald Alvestrand", "text": "

If I was designing HTTP at any time after 1990, the Host: would not be part of the protocol.

", "time": "2023-03-30T00:53:02Z"}, {"author": "Richard Barnes", "text": "

Thus sayeth MLS:> Using the terminology from [RFC6125], a Credential provides \"presented identifiers\", and it is up to the application to supply a \"reference identifier\" for the authenticated client, if any.

", "time": "2023-03-30T00:55:07Z"}, {"author": "Eric Rescorla", "text": "

I don't think Cullen's \"history\" is a good reason, because you create whatever your store

", "time": "2023-03-30T00:55:10Z"}, {"author": "Eric Rescorla", "text": "

As opposed to it being provided by someone else

", "time": "2023-03-30T00:55:26Z"}, {"author": "Richard Barnes", "text": "

+1 EKR

", "time": "2023-03-30T00:55:35Z"}, {"author": "Harald Alvestrand", "text": "

what's a reasonable size of an MLS group these days?

", "time": "2023-03-30T00:57:03Z"}, {"author": "Richard Barnes", "text": "

Webex supports up to 1000 in production, and Matrix is testing support out to 10^6 https://arewemlsyet.com/

", "time": "2023-03-30T00:58:21Z"}, {"author": "Harald Alvestrand", "text": "

10^6 sounds good.

", "time": "2023-03-30T00:58:58Z"}, {"author": "Richard Barnes", "text": "

(note that that is individual devices, since each device appears as a separate MLS client)

", "time": "2023-03-30T00:59:18Z"}, {"author": "Richard Barnes", "text": "

@Harald happy to give you the full run-down on where the scaling pain points are sometime

", "time": "2023-03-30T00:59:36Z"}, {"author": "Harald Alvestrand", "text": "

that graph effectively says 1000 at the moment. Nice test.

", "time": "2023-03-30T01:00:19Z"}, {"author": "Jonathan Rosenberg", "text": "

On In-Reply-To: what is the behavior when a user replies to a message, and the referred-to message has been edited or deleted... we may need to specify this behavior

", "time": "2023-03-30T01:00:46Z"}, {"author": "Andrew Sullivan", "text": "

I have to say that the claim Slack's approach to threading is an \"excellent\" implementation is not actually the way I feel about it. It's definitely a way.

", "time": "2023-03-30T01:01:25Z"}, {"author": "Martin D\u00fcrst", "text": "

@Andrew Sullivan totally agree

", "time": "2023-03-30T01:03:28Z"}, {"author": "Eric Rescorla", "text": "

Jonathan Rosenberg said:

\n
\n

On In-Reply-To: what is the behavior when a user replies to a message, and the referred-to message has been edited or deleted... we may need to specify this behavior

\n
\n

Well this happens with threads too

", "time": "2023-03-30T01:04:15Z"}, {"author": "Harald Alvestrand", "text": "

in my opinion, all threading mechanisms that postdate gnus are inferior.....

", "time": "2023-03-30T01:04:29Z"}, {"author": "Eric Rescorla", "text": "

This is why I wanted a DAG :)

", "time": "2023-03-30T01:05:01Z"}, {"author": "Mallory Knodel", "text": "

Does timestamp come from sender client, user client or server? Feels like if it\u2019s server then problem solved in terms of consistency.

", "time": "2023-03-30T01:07:31Z"}, {"author": "Travis Ralston", "text": "

I'd expect it to come from the server because clients tend to have very different concepts of time

", "time": "2023-03-30T01:08:11Z"}, {"author": "Eric Rescorla", "text": "

The assumption in this doc is that the timestamp is in the message and thus created by the sender

", "time": "2023-03-30T01:08:29Z"}, {"author": "Daniel Gillmor", "text": "

ekr's proposal of \"just a DAG\" should meet that bar, no?

", "time": "2023-03-30T01:08:31Z"}, {"author": "Darrel Miller", "text": "

When I was first exposed to the threads concept in Microsoft Teams is was very confusing to me. When we designed the Microsoft Graph API we made the Teams team rename threadId to replyToId to hide the \"thread\" concept.

", "time": "2023-03-30T01:08:41Z"}, {"author": "Harald Alvestrand", "text": "

\"underspecified and needs more work\" seems to be the most uncontroversial statement of the discussion.

", "time": "2023-03-30T01:09:19Z"}, {"author": "Martin D\u00fcrst", "text": "

Just a DAG meets many requirements, but very difficult to expose in UI, and most users will be confused

", "time": "2023-03-30T01:10:14Z"}, {"author": "Richard Barnes", "text": "

there are multiple systems that use DAGs today. they don't manifest them to the user, they just use them to make a timeline.

", "time": "2023-03-30T01:11:14Z"}, {"author": "Harald Alvestrand", "text": "

DAG (and not tree) means multivalued in-reply-to, yes?

", "time": "2023-03-30T01:11:40Z"}, {"author": "Travis Ralston", "text": "

The client-server interactions tend to linearize the DAG into near-timestamp ordering for the client.

", "time": "2023-03-30T01:11:42Z"}, {"author": "Mallory Knodel", "text": "

Vittorio private conversation data is not subject to the Gdpr. There were proposals in some EU countries about data retention (Belgium 2021) and they failed. It\u2019s not useful to design around this anyway

", "time": "2023-03-30T01:13:12Z"}, {"author": "Daniel Gillmor", "text": "

tons of controversy!

", "time": "2023-03-30T01:14:13Z"}, {"author": "Michael B", "text": "

@Mallory Knodel does the same apply to enterprise use-cases? (Not withstanding that its hard to design around anyway)

", "time": "2023-03-30T01:14:59Z"}, {"author": "Daniel Gillmor", "text": "

enterprises might have both data deletion obligations and data retention obligations -- and in some cases, conflicting requirements, because there are bugs in the jurisdictions they are subject to. i don't think we can bake all that in here.

", "time": "2023-03-30T01:16:16Z"}, {"author": "Daniel Gillmor", "text": "

Harald Alvestrand said:

\n
\n

DAG (and not tree) means multivalued in-reply-to, yes?

\n
\n

right, it would mean that, which is not permitted in rohan's draft as i understand it.

", "time": "2023-03-30T01:17:39Z"}, {"author": "Martin D\u00fcrst", "text": "

@Richard Barnes any pointers (re. DAG)?

", "time": "2023-03-30T01:17:58Z"}, {"author": "Richard Barnes", "text": "

@Martin - core principle of Matrix https://www.ietf.org/id/draft-ralston-mimi-linearized-matrix-00.html

", "time": "2023-03-30T01:18:42Z"}, {"author": "Daniel Gillmor", "text": "

i also note that rohan's draft doesn't even prohibit cycles. any sender (or set of senders) can collude to create a cycle

", "time": "2023-03-30T01:18:43Z"}, {"author": "Pete Resnick", "text": "

The scribes invite all to https://notes.ietf.org/notes-ietf-116-mimi to make sure we've captured your comments reasonably.

", "time": "2023-03-30T01:18:50Z"}, {"author": "Richard Barnes", "text": "

i'm just disappointed he didn't name it something clever like \"eigensystem\" or \"SVD\"

", "time": "2023-03-30T01:21:44Z"}, {"author": "Daniel Gillmor", "text": "

if the message id was derived deterministically (with a cryptographically-strong digest) from the content of the message, it should be able to prevent cycles, but then an update would change the message id of the mesage :(

", "time": "2023-03-30T01:21:47Z"}, {"author": "Pete Resnick", "text": "

@Rohan Mahy While I have a moment: What is the semantic difference in your view between a contribution to a thread that is not a reply and a reply to the root message of the thread?

", "time": "2023-03-30T01:28:21Z"}, {"author": "Richard Barnes", "text": "

@dkg that doesn't seem insurmountable. you could have the DAG hash cover an immutable subset of the message, e.g., message id and list of predecessors

", "time": "2023-03-30T01:28:33Z"}, {"author": "Martin D\u00fcrst", "text": "

@Richard Barnes Thanks!

", "time": "2023-03-30T01:30:27Z"}, {"author": "Andrew Sullivan", "text": "

The message-id in this discussion (which needs some different name) seems to me to have a lot in common with serial numbers for DNS zone data in cases where you treat every individual update of a zone as a separate change (so you increment the serial). So perhaps \"serial id\" is a term that could be useful.

", "time": "2023-03-30T01:35:45Z"}, {"author": "Richard Barnes", "text": "

see, timestamps are unreliable!

", "time": "2023-03-30T01:48:27Z"}, {"author": "Martin D\u00fcrst", "text": "

ekr's slide 3 doesn't have 'delivery service' (previous talk), so

", "time": "2023-03-30T01:51:30Z"}, {"author": "Richard Barnes", "text": "

@Martin - I think the assumption is that the DS function is part of what the transport does

", "time": "2023-03-30T01:51:54Z"}, {"author": "Martin D\u00fcrst", "text": "

... do we actually need 'delivery service (as a server)? (I tend to think no)

", "time": "2023-03-30T01:52:43Z"}, {"author": "Richard Barnes", "text": "

we need something that provides a bundle of functions that are collectively known as DS

", "time": "2023-03-30T01:53:09Z"}, {"author": "Richard Barnes", "text": "

those could be distributed across multiple services / servers / etc.

", "time": "2023-03-30T01:53:26Z"}, {"author": "Britta Hale", "text": "

An assumption that the transport can provide the DS will not work in some use cases.

", "time": "2023-03-30T01:53:59Z"}, {"author": "Richard Barnes", "text": "

@Britta - say more?

", "time": "2023-03-30T01:54:11Z"}, {"author": "Richard Barnes", "text": "

(to be clear, when we see \"transport\" here, we're not talking like TCP / UDP / QUIC, we're talking about some application layer thing like the things that were just presented)

", "time": "2023-03-30T01:55:00Z"}, {"author": "Daniel Gillmor", "text": "

perhaps this conversation just needs to be clear the semantics of the guarantees that the various servers can provide to the clients.

", "time": "2023-03-30T01:57:32Z"}, {"author": "Daniel Gillmor", "text": "

(without defining the explicit client\u2190\u2192server protocol)

", "time": "2023-03-30T01:57:59Z"}, {"author": "Alissa Cooper", "text": "

+1 DKG

", "time": "2023-03-30T01:58:11Z"}, {"author": "Richard Barnes", "text": "

+1 Matthew

", "time": "2023-03-30T02:02:02Z"}, {"author": "Andrew Sullivan", "text": "

It also seems to me that overloading terms like message-id, transport, and so on is going to cause confusion in drafts.

", "time": "2023-03-30T02:02:42Z"}, {"author": "Travis Ralston", "text": "

+1 to terms being overloaded. It's even been difficult to write drafts :sweat_smile:

", "time": "2023-03-30T02:03:16Z"}, {"author": "Britta Hale", "text": "

@Richard: Something application layer-ish would be viable, but locking that in to e.g. XMPP starts to assume a use case/restriction set. At the very least, we need a selection of such transports and not to lock into one.

", "time": "2023-03-30T02:03:37Z"}, {"author": "Raphael Robert", "text": "

+1
\nHence my proposal to dissociate the DS from the transport layer

", "time": "2023-03-30T02:04:19Z"}, {"author": "Britta Hale", "text": "

Agreed on that

", "time": "2023-03-30T02:04:32Z"}, {"author": "Andrew Sullivan", "text": "

I don't have any horse in this race, but I think the idea of trying to do something beyond just-SSI at the outset is ocean-boiling.

", "time": "2023-03-30T02:06:29Z"}, {"author": "Britta Hale", "text": "

If we assume e.g. XMPP (not to keep focusing on that example, but it is illustrative), then we may choose a DS design that works well in 50% of use cases but not the rest... that is the danger of not recommending a least a couple ways to interoperate so that all instantiations in similar environments can do so.

", "time": "2023-03-30T02:07:43Z"}, {"author": "Rohan Mahy", "text": "

Pete Resnick said:

\n
\n

Rohan Mahy While I have a moment: What is the semantic difference in your view between a contribution to a thread that is not a reply and a reply to the root message of the thread?

\n
\n

a reply to the root of the thread would NOT appear in the thread, it would appear in the owning channel. and that would be intention of the end user. In other words it could be days/months later and would be seen by everyone in the channel, even if they were muted on the thread.

", "time": "2023-03-30T02:07:58Z"}, {"author": "Daniel Gillmor", "text": "

when i hear \"it's an opportunity to solve the PKI problem\"\u2026 :fear:

", "time": "2023-03-30T02:08:03Z"}, {"author": "Britta Hale", "text": "

+1 Daniel

", "time": "2023-03-30T02:08:32Z"}, {"author": "Andrew Sullivan", "text": "

Glad I am not the only one who instantly developed hives at that article.

", "time": "2023-03-30T02:08:33Z"}, {"author": "Richard Barnes", "text": "

can we please do 2? do the easy thing first then the hard thing

", "time": "2023-03-30T02:09:55Z"}, {"author": "Daniel Gillmor", "text": "

divide and conquer

", "time": "2023-03-30T02:10:18Z"}, {"author": "Pete Resnick", "text": "

@Jonathan Rosenberg So you think we should not do discovery now, but agree that we'll need it soon?

", "time": "2023-03-30T02:10:25Z"}, {"author": "Daniel Gillmor", "text": "

now i'm confused, because i think Jon's version of \"discovery\" is different from what i thought \"discovery\" meant here.

", "time": "2023-03-30T02:11:59Z"}, {"author": "Benson Muite", "text": "

Tools such as jami.net, otr.to and p2p.chat use client-to-client though maybe challenging to interoperate with these. Solving discovery problem may also help these seperately.

", "time": "2023-03-30T02:12:03Z"}, {"author": "Travis Ralston", "text": "

SSIs in many (all?) federated environments I believe are routable

", "time": "2023-03-30T02:12:58Z"}, {"author": "Daniel Gillmor", "text": "

that's what i understood as an SSI too, @Travis Ralston

", "time": "2023-03-30T02:13:23Z"}, {"author": "Rohan Mahy", "text": "

Andrew Sullivan said:

\n
\n

I have to say that the claim Slack's approach to threading is an \"excellent\" implementation is not actually the way I feel about it. It's definitely a way.

\n
\n

excellent? IMO, compared to other widely deployed IM systems, yes. If you think there is a better example of this for IM, please tell me what systems you think do this really well.

", "time": "2023-03-30T02:15:31Z"}, {"author": "Richard Barnes", "text": "

i would note that we might have to support multiple of these modes

", "time": "2023-03-30T02:15:51Z"}, {"author": "Andrew Sullivan", "text": "

@Rohan Mahy I don't know that I'd say there is a better example, but I still think it's a hack.

", "time": "2023-03-30T02:16:27Z"}, {"author": "Andrew Sullivan", "text": "

Surely the answer to this is that (3) can be made to operate in modes (1) and (2) depending on the user's preferences, but you can never get (3) if you start with (1).

", "time": "2023-03-30T02:17:30Z"}, {"author": "Andrew Sullivan", "text": "

(\"this\" meaning the \"which modes\" slide up right now)

", "time": "2023-03-30T02:17:44Z"}, {"author": "Richard Barnes", "text": "

i expect we will end up with (1) + (3). There are clearly major apps that do both of those. (2) just seems goofy.

", "time": "2023-03-30T02:18:09Z"}, {"author": "Richard Barnes", "text": "

good point @Andrew

", "time": "2023-03-30T02:18:17Z"}, {"author": "Matthew Hodgson", "text": "

matrix does (2) today and works well, fwiw

", "time": "2023-03-30T02:18:24Z"}, {"author": "Matthew Hodgson", "text": "

the 'consent' question is a classic example of needing to consider the UX, though. if the existing apps do (1), they won't want the protocol to force them to do (3)

", "time": "2023-03-30T02:18:45Z"}, {"author": "Matthew Hodgson", "text": "

so i think you need a hybrid approach.

", "time": "2023-03-30T02:18:51Z"}, {"author": "Matthew Hodgson", "text": "

that said, doing (2) in Matrix means that you then get invite spam as the main flavour of spam to contend with (and, what data do you expose on an invite, in terms of being a spam vector?)

", "time": "2023-03-30T02:19:28Z"}, {"author": "Andrew Sullivan", "text": "

But if the existing app does (1) its answer is that (3) entails \"auto permit\" and now you have (1) anyway.

", "time": "2023-03-30T02:19:32Z"}, {"author": "Richard Barnes", "text": "

@Matthew does the above \"simulate\" (1) with (3) (e.g., by auto-accepting) not seem plausible to you?

", "time": "2023-03-30T02:19:35Z"}, {"author": "Rohan Mahy", "text": "

Mallory Knodel said:

\n
\n

Does timestamp come from sender client, user client or server? Feels like if it\u2019s server then problem solved in terms of consistency.

\n
\n

Mallory, for the client timestamp, I think this has to come from the client and represents the time when the client encrypts the message. If the client can have a timestamp at all, I think we need help constraining when these timestamps are \"valid\", which probably needs help from the AS/DS.

", "time": "2023-03-30T02:19:58Z"}, {"author": "Matthew Hodgson", "text": "

yeah, you can autoaccept as a way to simulate (1)

", "time": "2023-03-30T02:20:05Z"}, {"author": "Richard Barnes", "text": "

we just need https://http.cat/401

", "time": "2023-03-30T02:23:18Z"}, {"author": "Mallory Knodel", "text": "

It is not hard to imagine users choosing services based on how well they manage spam. That was a way to differential email service once.

", "time": "2023-03-30T02:26:30Z"}, {"author": "Daniel Gillmor", "text": "

i confess i'm tempted by @Harald Alvestrand 's simplified user-controlled model, though i'm not sure how well it would work

", "time": "2023-03-30T02:28:49Z"}, {"author": "Richard Barnes", "text": "

counterpoint to what EKR said -- frequent virtual interims worked well for MLS, which was also pretty complicated. though we did that later in the lifecycle, so there was more of a foundation.

", "time": "2023-03-30T02:31:06Z"}, {"author": "Daniel Gillmor", "text": "

+1 for an issue tracker

", "time": "2023-03-30T02:31:56Z"}, {"author": "Raphael Robert", "text": "

agree with Richard, we should have interims, April 10 sounds quite early though

", "time": "2023-03-30T02:32:06Z"}]