Subject: [MLS] MLS in decentralised environments

From: Matthew Hodgson <[email-masked]>
Date: Tue, 3 Apr 2018 10:29:06 +0100

Hi all,

[TL;DR: MLS doesn't seem to support decentralisation.  Can we fix that, 
especially given it'll help solve other problems too?  I have a 
handwavey proposal.]

Since IETF101 I've been trying to work out how well MLS could be applied 
in fully decentralised environments which lack any single controlling 
server, as it seems that the current proposal effectively rules this out 
due to the state sequencing requirements (thanks to Ben Schwartz for 
spelling this out to me after the BOF!).

This feels like it could be quite a large oversight, given there are 
many real-time communication protocols and services (e.g. Matrix[1], 
Tox[2], Briar[3], Secure Scuttlebutt[4], Whisper[5], PSS[6], psyc2[7], 
XMPP FMUCs[8] (and MIX?), even NNTP and SMTP) where messages are 
replicated over a network of peers without any single controlling server 
- all of which could benefit from the well specified, interoperable & 
scalable group e2e encryption that MLS promises!  There's also a more 
ideological argument that interoperable communication is such a 
fundamental right that the IETF should support services which support 
communication without a necessary central logical point of control (much 
as the internet itself is decentralised).

More practically, there may be some benefit to considering 
decentralisation in MLS in general: for instance, general solutions to 
races and key synchronisation within a decentralised network could also 
solve races in a centralised deployment.  It could also improve 
scalability and geo-redundancy by avoiding the need for an atomic 
ordering system for state changes.

To give some concrete context: all conversations in Matrix are expressed 
as Merkle DAGs of messages which are replicated over the participating 
servers using eventual consistency semantics (a bit like a full mesh of 
Git repositories all constantly pushing commits to one another).  As a 
result the conversation DAG often forks: either due to races, 
partitioned networks, disconnected or offline servers etc - but these 
temporary forks are very much a desirable feature, allowing partially 
disconnected operation (e.g. letting a site continue communicating 
locally even when isolated from the wider network), and aiding 
scalability (no need for global locks or sequencing).

Currently Matrix uses Olm[9] (a Double Ratchet Algorithm implementation) 
to maintain a full mesh of secure 1:1 channels between devices, and then 
shares a group ratchet (Megolm[10]) per sender over these channels.  The 
megolm ratchet is a simple hash ratchet which advances every message, 
and is replaced every N messages (or when group membership changes). 
The cost of replacement is O(N) with the size of the group, as is the 
cost of adding users to the group, which obviously makes ART & MLS’s 
O(log N) behaviour appealing.

However, the eventual consistency semantics of a decentralised protocol 
introduce challenges for E2E encryption: for instance, the membership of 
a given room is not well defined, as there may be a partition of the 
room (either due to races or netsplit) which include devices or users 
that a sender is not yet aware of.  This mandates a way of 
retrospectively syncing message keys between devices after such a fork: 
deliberately prioritising UX (ensuring messages that users expect to be 
able to decrypt can be decrypted) over forward secrecy.  The same 
mechanism can be used for cross-device history sync or sharing history 
from before users join a group.

In Matrix we solve this by letting devices share group ratchet key state 
between each other over Olm by making so-called 'keyshare requests'. 
Devices must have explicitly verified and trusted the identity of the 
requesting device before they share keys to it (and currently, keyshare 
is only supported between a given user's devices - in future we could 
also support keyshare between all the group's devices if the requester 
is verified and can provide a proof of permission to view the requested 
content).  This obviously puts a large onus on the device verification 
mechanism to ensure an attacker isn't able to exfiltrate keys, but our 
experience has been that the improved UX is worth the risk (plus can 
always be disabled if needed, e.g. in a single-server centralised 
deployment).

So, how can we support something like this in MLS?

There seem to be two main obstacles: 1) the requirement for strict 
sequencing of state changes, 2) the lack of keyshare semantics to 
recover from the missing key data which is inevitable in an eventually 
consistent view of a room.  I'm going to ignore the second for now as it 
can be fixed out of band (although much like attachments, it feels like 
something which MLS should make /some/ recommendation on, given it can 
be incredibly useful as a primitive)

However, for state sequencing: Am I right in saying that a race between 
B and C joining a group can cause one client to see a DH binary tree 
with frontier (AB, C) versus (AC, B), and thus have inconsistent root 
group keys - messages encrypted during the partition are going to 
inevitably be undecryptable by the other side?

Is there a way where MLS could allow a group to recover from a partition 
like this by (partially?) rebalancing the DH binary tree into a 
canonical form once the partition heals?  Thus if a partition was 
detected at the application layer (in Matrix's case, we'd do this by 
noting that the B-join and C-join events share the same A-join parent), 
the servers participating in the room would rebalance (AB,C) and (AC,B) 
to both be (AB,C) and then the conversation could proceed as normal. 
One might be able to avoid rebalancing the whole tree to minimise CPU 
impact (although in practice healing these races are fairly rare edge 
cases).  Obviously this assumes that one has a way to request keys to 
recover the messages lost when the groups were out of sync.

If this mechanism makes sense, it seems that it could provide a way to 
eliminate the "Sequencing of State Changes" requirement entirely from 
MLS - or at least provide an alternative for folks where either 
server-side or client-side strict sequencing isn't an option, and so 
solve the general 'how to handle races' problem mentioned at the BOF 
(whilst also necessitating an interoperable solution to history/key 
sharing, similar to the earlier “Use cases for avoiding forward secrecy” 
thread[11])

Anyway, apologies for the stream of consciousness - feedback from those 
who properly understand ART & MLS would be hugely appreciated :)

thanks,

Matthew

[1] https://matrix.org/docs/spec
[2] https://toktok.ltd/spec.html#introduction
[3] 
https://code.briarproject.org/akwizgran/briar-spec/blob/master/protocols/BTP.md
[4] https://ssbc.github.io/scuttlebutt-protocol-guide/
[5] https://github.com/ethereum/go-ethereum/wiki/Whisper
[6] https://gist.github.com/zelig/d52dab6a4509125f842bbd0dce1e9440
[7] https://gnunet.org/sites/default/files/gnunet-psyc.pdf
[8] https://xmpp.org/extensions/xep-0289.html
[9] https://git.matrix.org/git/olm/about/docs/olm.rst
[10] https://git.matrix.org/git/olm/about/docs/megolm.rst
[11] https://mailarchive.ietf.org/arch/msg/mls/b5YoQfdeFcoLYrFdxbZmdX__jWA

P.S. This has probably already been fixed, but the [signal] footnote on 
https://tools.ietf.org/html/draft-barnes-mls-protocol-00 is credited to 
"T. and M. Marlinspike" - I think you are missing a 'Perrin'?

-- 
Matthew Hodgson
Matrix.org

---

From: Dave Cridland <[email-masked]>
Date: Tue, 3 Apr 2018 10:51:35 +0100

On 3 April 2018 at 10:29, Matthew Hodgson <[email-masked]> wrote:

> This feels like it could be quite a large oversight, given there are many
> real-time communication protocols and services (e.g. Matrix[1], Tox[2],
> Briar[3], Secure Scuttlebutt[4], Whisper[5], PSS[6], psyc2[7], XMPP
> FMUCs[8] (and MIX?), even NNTP and SMTP) where messages are replicated over
> a network of peers without any single controlling server

Just as a side-note, the only environment I know of using XMPP FMUC also
bans use of end-to-end encryption. MIX (XEP-0369) uses the same model of a
single definitive sequence of messages, currently. Neither MUC nor MIX
require a single server, however - just a single domain.

FMUC differs in simply having multiple "correct" sequences, where the
various sequence domains are split by having very lo links in between. This
is a trade-off in terms of UX, however - having a single sequence of
messages known to all participants (not just their clients) is useful, and
of absolutely critical importance in some environments.

Dave.

---

From: "Katriel Cohn-Gordon" <[email-masked]>
Date: Tue, 03 Apr 2018 11:41:51 +0100

Hi Matthew,

Thanks for thinking about this. I agree that it's a problem I think
exists even in the centralised world, since it's much nicer to build a
system that doesn't have to provide strict sequencing guarantees.
# The problem

I'll sketch out the underlying problem first, even though I think you
spotted it pretty well, just to make sure we're on the same page. The
problem is from the ratcheting tree construction: two updates which
both want to change a particular intermediate node cannot both be
applied at the same time. Let me try out some ASCII art: consider a
simple tree like
root
├── x
│   ├── a
│   └── b
└── y
    ├── c
    └── d

and suppose c wants to update to c', giving the following tree and
publishing g^i(y') where y'=g^c'd
root
├── x
│   ├── a
│   └── b
└── y'
    ├── c'
    └── d

while d also wants to update to d', giving the following tree and
publishing g^i(y'') where y''=g^cd'
root
├── x
│   ├── a
│   └── b
└── y''
    ├── c
    └── d'

These can't both be applied by A: A can either set their view of the
last node on their copath to be y' or y'', but not both of them.
Moreover, A has no way of "combining" the two updates.
# Not the problem

One thing I should highlight up front is that this does not necessarily
prevent decrypting messages, only applying key updates. Specifically, if
A receives either C's or D's update they can apply it and compute the
resulting root key, then decrypt the message. Of course, if the update
is one that should have bounced, then they might have to "un-apply" it.
Moreover, if A wants to send their own update, they need to pick one of
y' and y'' to base it on. This is something I don't think we've reasoned
about in detail yet.
For other reasons due to malicious group members, I think we're likely
to come up with a system where each participant has various "proposed"
updates sitting around, and then only confirms them after receiving
some other message. This sort of algorithm should also help here,
because I think it will also need the ability to unwind or not apply a
potential update.
# Things we tried that don't yet work

One thing we thought about was using some tricks with Diffie-Hellman to
allow both updates to be processed at the same time. Unfortunately we
couldn't actually come up with a system that works  (using a KDF to
turn group elements back into integers hurts here), but there might
well be one.
Another thing is the observation that in fact it is sometimes
possible to apply two updates at once: specifically, if two updates
change different copath elements with respect to a recipient, then
that recipient can apply both of them. Unfortunately this only helps
some recipients, not all of them, so it doesn't really solve the
whole problem.
Another thing is having the server do some clever re-ordering. The
challenge  is that in the end, by construction the correct value of the
intermediate node should only be computable by its children, so there's
only so much the server can do.
For the same reason, I'm not sure the server can unilaterally rebalance
the tree; I think it would need some help from one of the participants.
I'd have to think more carefully about the precise keys which it would
need to do so, though. In particular, if you are more worried about re-
ordering join events than re-ordering key updates, there might be some
specialised tricks that work.
# Question about the Matrix context

In the Matrix setup, do nodes actually know when there is consensus on a
particular set of messages? That is, is there some point at which they
can conclude "ok, I know that the following messages are actually the
right ones, and haven't been pre-empted or undone by successors"? (If so
then I think the "multiple proposed updates" ideas will help here too.)

does that make sense? :)

best,
K

---

From: Matthew Hodgson <[email-masked]>
Date: Tue, 3 Apr 2018 22:59:41 +0100

On 03/04/2018 11:41, Katriel Cohn-Gordon wrote:
> applied at the same time.

Thanks for the speedy & comprehensive answer (and sorry for being slow 
at grokking this in person at IETF!)

Yup, I think we're on the same page - the only difference is that I've 
been fixating on races between adding devices to the group (as that's 
the one which has historically bitten us badly on Matrix) versus races 
betwen key updates, which is I guess is the more common failure mode for 
MLS.

> # Not the problem
>
> One thing I should highlight up front is that this does not 
> necessarily prevent decrypting messages, only applying key updates. 
> Specifically, if A receives either C's or D's update they can apply it 
> and compute the resulting root key, then decrypt the message. Of 
> course, if the update is one that should have bounced, then they might 
> have to "un-apply" it.

Aaaah, interesting. Does this mean that a 'many worlds' style approach 
can work here, where each client calculates the possible trees resulting 
in the state changes arriving in different orders, and tries to decrypt 
the messages using the tree which 'works' (thus avoiding the need for 
keysharing)?

> Moreover, if A wants to send their own update, they need to pick one 
> of y' and y'' to base it on. This is something I don't think we've 
> reasoned about in detail yet.
>

Okay. Is this the same as the proposed v. committed update strategy 
mentioned at 
https://tools.ietf.org/html/draft-barnes-mls-protocol-00#section-9.2?

> One thing we thought about was using some tricks with Diffie-Hellman 
> to allow both updates to be processed at the same time. Unfortunately 
> we couldn't actually come up with a system that works (using a KDF to 
> Another thing is the observation that in fact it is sometimes possible 
> to apply two updates at once: specifically, if two updates change 
> different copath elements with respect to a recipient, then that 
> recipient can apply both of them. Unfortunately this only helps some 
> recipients, not all of them, so it doesn't really solve the whole problem.
>
> intermediate node should only be computable by its children, so 
> there's only so much the server can do.
>
> For the same reason, I'm not sure the server can unilaterally 
> rebalance the tree; I think it would need some help from one of the 
> participants. I'd have to think more carefully about the precise keys 
> which it would need to do so, though. In particular, if you are more 
> worried about re-ordering join events than re-ordering key updates, 
> there might be some specialised tricks that work.

I wasn't thinking of the server rebalancing the tree, but instead there 
being some kind of mechanism that alerts clients to the fact that there 
is been a race (e.g. two messages arriving with the same logical 
timestamp), causing them to all go and rebalance their trees to ensure 
everyone is back on the same page (to the best of their knowledge) 
rather than trying to apply the update to the 'wrong' base.  It feels 
like i'm missing something about the practicality of doing this in terms 
of the actual DH exchanges though?

In a 'many world' model, I guess this would just mean selecting the 
correct tree from the possibilities being maintained, rather than having 
to rebalance the currently 'wrong' tree to make it 'correct', which 
seems a bit cleaner.

> In the Matrix setup, do nodes actually know when there is consensus on 
> a particular set of messages?

They do not. We don't currently have a consensus mechanism which seals 
the history - instead, it's perfectly valid for a netsplit to cause a 
room to go off on a long-lived evolutionary fork.

We have considered sealing history in the context of transcript 
consistency however, as having a canonical version of the room can 
obviously be useful to avoid situations where folks insert or reject 
messages in their local fork of the room in order to twist the 
conversation.  It could also be useful when changing the replication 
algorithm (atomically sealing the history of the room on the old 
protocol before switching over to the new).

However, we'd prefer to avoid forcing participants into committing to a 
'one true copy of the room' as it effectively introduces centralisation, 
as well breaking the whole long-lived fork use cases.  Instead it'd 
probably be nicer to commit to transcript consistency *for a given 
partition of the room*, which we effectively already have via the Merkle 
signing of the Matrix room DAG.

> That is, is there some point at which they can conclude "ok, I know 
> that the following messages are actually the right ones, and haven't 
> been pre-empted or undone by successors"? (If so then I think the 
> "multiple proposed updates" ideas will help here too.)

So I wonder if the "many worlds" or "multiple proposed updates" idea 
works even if your forks can be longlived - it's just that the proposals 
can drag on for a long time and are never necessarily fully committed 
to.  Is this actually a problem?  I think I'm missing the attacks which 
you are considering...

> does that make sense? :)

mostly, I think!

M

-- 
Matthew Hodgson
Matrix.org

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Apr 2018 12:23:19 +1000

Is it possible to have a common tie-breaker process and force the
loser to rebase?

That is, if the change c->c' wins, then d needs to apply their d->d'
change again on top of that change (or move to d'').

A simple tie breaker process would inform all participants of the head
of both forks and to pick a winner based on the one that gets the
largest result from H(root).  That's open to participants choosing
keys to influence the result, so you probably don't want that precise
design (esp. if forks include removals), but hopefully the idea makes
sense.

The next problem would be that repair of a fork can be expensive.  If
there are multiple changes on the losing fork, then all those changes
might also compete as the updates propagate.

On Tue, Apr 3, 2018 at 8:41 PM, Katriel Cohn-Gordon <[email-masked]> wrote:
> Hi Matthew,
>
> Thanks for thinking about this. I agree that it's a problem I think exists
> even in the centralised world, since it's much nicer to build a system that
> doesn't have to provide strict sequencing guarantees.
>
> # The problem
>
> problem is from the ratcheting tree construction: two updates which both
> want to change a particular intermediate node cannot both be applied at the
> same time. Let me try out some ASCII art: consider a simple tree like
>
> root
> ├── x
> │   ├── a
> │   └── b
> └── y
>     ├── c
>     └── d
>
> while d also wants to update to d', giving the following tree and publishing
> g^i(y'') where y''=g^cd'
>
> root
> ├── x
> │   ├── a
> │   └── b
> └── y''
>     ├── c
>     └── d'
>
> These can't both be applied by A: A can either set their view of the last
> node on their copath to be y' or y'', but not both of them. Moreover, A has
> no way of "combining" the two updates.
>
> # Not the problem
>
> prevent decrypting messages, only applying key updates. Specifically, if A
> receives either C's or D's update they can apply it and compute the
> resulting root key, then decrypt the message. Of course, if the update is
> one that should have bounced, then they might have to "un-apply" it.
> Moreover, if A wants to send their own update, they need to pick one of y'
> and y'' to base it on. This is something I don't think we've reasoned about
> in detail yet.
>
> For other reasons due to malicious group members, I think we're likely to
> come up with a system where each participant has various "proposed" updates
> sitting around, and then only confirms them after receiving some other
> message. This sort of algorithm should also help here, because I think it
> will also need the ability to unwind or not apply a potential update.
>
> couldn't actually come up with a system that works (using a KDF to turn
> group elements back into integers hurts here), but there might well be one.
>
> Another thing is the observation that in fact it is sometimes possible to
> apply two updates at once: specifically, if two updates change different
> copath elements with respect to a recipient, then that recipient can apply
> both of them. Unfortunately this only helps some recipients, not all of
> them, so it doesn't really solve the whole problem.
>
> Another thing is having the server do some clever re-ordering. The challenge
> is that in the end, by construction the correct value of the intermediate
> node should only be computable by its children, so there's only so much the
> server can do.
>
> For the same reason, I'm not sure the server can unilaterally rebalance the
> tree; I think it would need some help from one of the participants. I'd have
> to think more carefully about the precise keys which it would need to do so,
> though. In particular, if you are more worried about re-ordering join events
> than re-ordering key updates, there might be some specialised tricks that
> work.
>
> particular set of messages? That is, is there some point at which they can
> conclude "ok, I know that the following messages are actually the right
> ones, and haven't been pre-empted or undone by successors"? (If so then I
> think the "multiple proposed updates" ideas will help here too.)
>
>
>
>
> does that make sense? :)
>
> best,
> K
>
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls
>

---

From: "Katriel Cohn-Gordon" <[email-masked]>
Date: Wed, 04 Apr 2018 11:16:12 +0100

> Is it possible to have a common tie-breaker process and force the

Yes, I think so. Another one would be "the person who has least recently done an update wins ties", which would help with starvation issues. As you point out, the downside is that endpoints might have to keep quite a lot of potential state around in case an old message comes through and requires a large rebase.

I was wondering whether you could have a cap like "never rebase more than five updates ago" or something to prevent that case, but the challenge there is that without a centralised server you don't have a consistent view of how many updates have actually happened. The particularly problematic case is when e.g. A and B do a whole bunch of updates, and then C comes in and preempts them.

Having a centralised sequencing server makes this whole problem go away, sadly.

Katriel

---

From: Simon Friedberger <[email-masked]>
Date: Wed, 4 Apr 2018 18:58:32 +0200

XMPP has long had problems with MUCs because they are used for both

"group chats": private, few users, users usually constant, consistent
timeline important (the Whatsapp model)

"chat rooms": public, many users, users dynamic, splitting would be
acceptable, transcript optional (the IRC model)

In general "group chats" have the stricter requirements and are probably
better served by a centralized server.

I think the use-case for allowing splits is pretty weak.

1. Users mostly don't want it because it doesn't fit the model of a
modern group chat where your presence in the room is independent of the
connection of your devices. In fact it is essentially a case of "lost
messages". Which is probably the main complaint about XMPP and Signal
that I hear.

2. It seems to me it also doesn't force centralization as long as
multiple servers can host chats. They would just be different chats to
the user as well.

Having said that, allowing p2p messengers would be great but maybe they
just have to elect a leader. Supporting distributed setups is a
necessity but at the level of MLS they can probably be treated as one
server.

Best Regards,
Simon

On 03.04.2018 11:29, Matthew Hodgson wrote:
> Hi all,
>
> [TL;DR: MLS doesn't seem to support decentralisation.  Can we fix
> that, especially given it'll help solve other problems too?  I have a
> handwavey proposal.]
>
> Since IETF101 I've been trying to work out how well MLS could be
> applied in fully decentralised environments which lack any single
> controlling server, as it seems that the current proposal effectively
> rules this out due to the state sequencing requirements (thanks to Ben
> Schwartz for spelling this out to me after the BOF!).
>
> replicated over a network of peers without any single controlling
> server - all of which could benefit from the well specified,
> interoperable & scalable group e2e encryption that MLS promises! 
> There's also a more ideological argument that interoperable
> communication is such a fundamental right that the IETF should support
> services which support communication without a necessary central
> logical point of control (much as the internet itself is decentralised).
>
> races and key synchronisation within a decentralised network could
> also solve races in a centralised deployment.  It could also improve
> To give some concrete context: all conversations in Matrix are
> expressed as Merkle DAGs of messages which are replicated over the
> participating servers using eventual consistency semantics (a bit like
> a full mesh of Git repositories all constantly pushing commits to one
> another).  As a result the conversation DAG often forks: either due to
> races, partitioned networks, disconnected or offline servers etc - but
> these temporary forks are very much a desirable feature, allowing
> partially disconnected operation (e.g. letting a site continue
> communicating locally even when isolated from the wider network), and
> aiding scalability (no need for global locks or sequencing).
>
> Currently Matrix uses Olm[9] (a Double Ratchet Algorithm
> implementation) to maintain a full mesh of secure 1:1 channels between
> devices, and then shares a group ratchet (Megolm[10]) per sender over
> these channels.  The megolm ratchet is a simple hash ratchet which
> advances every message, and is replaced every N messages (or when
> group membership changes). The cost of replacement is O(N) with the
> size of the group, as is the cost of adding users to the group, which
> obviously makes ART & MLS’s O(log N) behaviour appealing.
>
> However, the eventual consistency semantics of a decentralised
> protocol introduce challenges for E2E encryption: for instance, the
> membership of a given room is not well defined, as there may be a
> partition of the room (either due to races or netsplit) which include
> devices or users that a sender is not yet aware of.  This mandates a
> way of retrospectively syncing message keys between devices after such
> a fork: deliberately prioritising UX (ensuring messages that users
> expect to be able to decrypt can be decrypted) over forward secrecy. 
> The same mechanism can be used for cross-device history sync or
> sharing history from before users join a group.
>
> In Matrix we solve this by letting devices share group ratchet key
> state between each other over Olm by making so-called 'keyshare
> requests'. Devices must have explicitly verified and trusted the
> identity of the requesting device before they share keys to it (and
> currently, keyshare is only supported between a given user's devices -
> in future we could also support keyshare between all the group's
> devices if the requester is verified and can provide a proof of
> permission to view the requested content).  This obviously puts a
> large onus on the device verification mechanism to ensure an attacker
> isn't able to exfiltrate keys, but our experience has been that the
> improved UX is worth the risk (plus can always be disabled if needed,
> e.g. in a single-server centralised deployment).
>
> consistent view of a room.  I'm going to ignore the second for now as
> it can be fixed out of band (although much like attachments, it feels
> like something which MLS should make /some/ recommendation on, given
> it can be incredibly useful as a primitive)
>
> However, for state sequencing: Am I right in saying that a race
> between B and C joining a group can cause one client to see a DH
> binary tree with frontier (AB, C) versus (AC, B), and thus have
> inconsistent root group keys - messages encrypted during the partition
> are going to inevitably be undecryptable by the other side?
>
> Is there a way where MLS could allow a group to recover from a
> partition like this by (partially?) rebalancing the DH binary tree
> into a canonical form once the partition heals?  Thus if a partition
> was detected at the application layer (in Matrix's case, we'd do this
> by noting that the B-join and C-join events share the same A-join
> parent), the servers participating in the room would rebalance (AB,C)
> and (AC,B) to both be (AB,C) and then the conversation could proceed
> as normal. One might be able to avoid rebalancing the whole tree to
> minimise CPU impact (although in practice healing these races are
> fairly rare edge cases).  Obviously this assumes that one has a way to
> request keys to recover the messages lost when the groups were out of
> sync.
>
> sharing, similar to the earlier “Use cases for avoiding forward
> secrecy” thread[11])
>
> Anyway, apologies for the stream of consciousness - feedback from
> those who properly understand ART & MLS would be hugely appreciated :)
>
> thanks,
>
> Matthew
>
> [11]
> https://mailarchive.ietf.org/arch/msg/mls/b5YoQfdeFcoLYrFdxbZmdX__jWA
>
> P.S. This has probably already been fixed, but the [signal] footnote
> on https://tools.ietf.org/html/draft-barnes-mls-protocol-00 is
> credited to "T. and M. Marlinspike" - I think you are missing a 'Perrin'?
>
>

---

From: Matthew Hodgson <[email-masked]>
Date: Wed, 4 Apr 2018 19:08:37 +0100

> On 4 Apr 2018, at 17:58, Simon Friedberger <[email-masked]> wrote:
> 

I think you have misunderstood my use of the word “netsplit”. I was not talking about IRC style netsplits where network partitions cause users to vanish from either side of the partition and messages to be lost. Instead, I’m talking about modern decentralised or p2p protocols like Matrix where a network partition allows both sets of connected nodes to keep talking to each other... and the history is synced over to the rest of the network when the partition is healed. No messages are lost, and it’s equally valuable for public chatrooms, private group chats or 1:1 conversations. Instead, it provides an eventually consistent conversation history which is immune to network races and partitions (not dissimilar to SMTP). Short outages end up being completely transparent; long outages can be modelled as threaded conversations. For instance: “Oh, look, the NY office just fixed their internet access: there’s the sidebar discussion they had whilst they were disconnected”.

> messages". Which is probably the main complaint about XMPP and Signal

As per above, no messages get lost. In fact the consideration here is a mechanism to *avoid* message getting lost in the face of a network partition.

> multiple servers can host chats. They would just be different chats to

Having a single logical server responsible for the policy and existence of any given conversation is (to me) very centralised. If that service goes down or can’t scale or has bad connectivity or is somehow compromised or broken or hosted in an environment you don’t trust... then you are screwed unless you migrate to another room, with all the social and UX disruption that entails. Hence trying to ensure that conversations themselves are decentralised.

It’s the same reason that DVCSes like Git are often considered more desirable and flexible than centralised repos like Subversion.

> necessity but at the level of MLS they can probably be treated as one

For the reasons given in my answer above; selecting a centralised leader for a decentralised conversation eliminates the whole point of the conversation being decentralised in the first place.

M