Re: [MLS] MLS in decentralised environments

Matthew Hodgson <> Wed, 04 April 2018 18:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 350FE12D779 for <>; Wed, 4 Apr 2018 11:08:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tJ7WWWVwp-S1 for <>; Wed, 4 Apr 2018 11:08:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 774EB126BFD for <>; Wed, 4 Apr 2018 11:08:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=hermes; h=To:References:Message-Id:Content-Transfer-Encoding:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=1KMPht7JuQsNZGUu7NdlWDOW1X7eMS0TnUITGA6/4oU=; b=svg55QSkHl8zku6uAkwL2Dh22Jfek6w1hRFTNx7YESc2n8zTxm8ve85zf+XnEXTJkB609Np8Yfj1YirpJrNxhNUUX52ziFqUlxvBJLKyjkZrK1kbJiPaY4t6krpKStFFcFm9JF6j+ei9l4eha+BXD++gdDbUZlMUyh8o/Lap2sYm68pHH7UF14DShtjwCi94B/m27jT0IhSIvvxD42XEfMmtESUzUuUmSzZDjYpnm+TFsXEe69F14UjqO0vx/9fTBy2XmClhOJLCeZg1rFIvN0vxkyE4fJC8HJimCdNnzf+3C/bgJLOsN+wDKeqmsn94ze4ziYbSUawPha/Yw+h5Zg==;
Received: from ([] helo=[]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1f3mpv-0007gb-SC; Wed, 04 Apr 2018 18:08:43 +0000
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Matthew Hodgson <>
X-Mailer: iPhone Mail (15D100)
In-Reply-To: <>
Date: Wed, 4 Apr 2018 19:08:37 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
Archived-At: <>
Subject: Re: [MLS] MLS in decentralised environments
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Messaging Layer Security <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Apr 2018 18:08:47 -0000

> On 4 Apr 2018, at 17:58, Simon Friedberger <> wrote:
> I think the use-case for allowing splits is pretty weak.

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”.

> 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.

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.

> 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 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.

> 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.

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.