Re: [Tools-discuss] matrix tests

Glen <glen@amsl.com> Sun, 13 December 2020 23:02 UTC

Return-Path: <glen@amsl.com>
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967313A02BC for <tools-discuss@ietfa.amsl.com>; Sun, 13 Dec 2020 15:02:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.01
X-Spam-Level:
X-Spam-Status: No, score=-100.01 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2IRefMuxEqw for <tools-discuss@ietfa.amsl.com>; Sun, 13 Dec 2020 15:02:15 -0800 (PST)
Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 138FE3A0100 for <tools-discuss@ietf.org>; Sun, 13 Dec 2020 15:02:15 -0800 (PST)
Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 9F5BA38AEBD for <tools-discuss@ietf.org>; Sun, 13 Dec 2020 15:02:14 -0800 (PST)
Received: from [192.168.86.10] (173-8-133-94-SFBA.hfc.comcastbusiness.net [173.8.133.94]) by c8a.amsl.com (Postfix) with ESMTPSA id 8DEF938A1E1 for <tools-discuss@ietf.org>; Sun, 13 Dec 2020 15:02:14 -0800 (PST)
To: tools-discuss@ietf.org
References: <e547d7be-8838-ce7f-fad5-61af474f7d12@cs.tcd.ie> <15081.1607893032@localhost>
From: Glen <glen@amsl.com>
Organization: AMS
Message-ID: <a798569d-0873-c199-1554-8c3aa85e0923@amsl.com>
Date: Sun, 13 Dec 2020 15:02:14 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <15081.1607893032@localhost>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-discuss/bdGVrXm7GxMu704HPIXYkJPH6NQ>
Subject: Re: [Tools-discuss] matrix tests
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-discuss/>
List-Post: <mailto:tools-discuss@ietf.org>
List-Help: <mailto:tools-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Dec 2020 23:02:20 -0000

Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> It didn't occur to me to create any matrix rooms. If it had, I'm not
> sure if that'd have been useful but I can imagine it being so in
> future, e.g. for a bar bof. Before that'd be a standard procedure I'd
> like to understand the duration for which any such rooms might last,
> how closed/open they may be etc.

I can actually report some technical data on that.

As I was performing server maintenance over the past few days, I 
discovered that the Matrix database was taking up a significant amount 
of space (91 GB for 37 local users.)  I put in an inquiry but didn't 
find anyone online (likely people are offline for the weekend) so I did 
some digging myself.

I discovered that our Matrix server was actually mirroring, and storing 
a local copy of, every single Matrix room that every local user had 
joined.  Here in no particular order are ten of the largest and most 
amusing rooms out of the 166 rooms that were found being served by our 
server:

#GodotLatino:matrix.org
#hedgedoc:matrix.org
#projectalice-shitpost:matrix.org
#marcopolo:matrix.org
#matrix:matrix.org
#monero:matrix.org
#lounge:privacytools.io
#rules:hive-mind.network
#synapse:matrix.org
#litecoin:matrix.org

Unlike Jabber, where a room is hosted on a single server; in Matrix, it 
turns out that every room that anyone belongs to is co-hosted on every 
server used by any of that room's users. [1] Even if all (local) users 
leave the room, the room remains on the server, along with all of the 
shared data.

Moreover, if I understand what the developers explained to me, it is not 
possible to delete a room "everywhere".  I can delete a room that exists 
on the local server, but that does not delete the room from other 
servers to which the room was shared.  And if our server somehow became 
disconnected from the rest, all of the rooms that had been shared out to 
other servers would continue to exist on those other servers forever as 
orphaned clones (for, as we like to say, some value of "forever"), 
outside of our ability to control (or perhaps even enumerate.)

So unlike operating a Jabber server, where the conference server is the 
"authoritative" location of the room (and logs are captured there), and, 
it turns out, unlike operating a Zulip server (which also has an 
authoritative location).... operating a Matrix server isn't really 
"operating" a server so much as "joining a huge network of peer servers."

As the IETF's operator, I do not set policy, so this is just my 
opinion... but I *think* that having our Matrix server mirroring some of 
the rooms in my list above seems... problematic.  If it turns out that 
this is the behavior desired by the IETF, then no changes are needed. 
If, however, the IETF wants to operate the Matrix server in a 
more-or-less authoritative, "Note Well"-compliant kind of way, then I 
*think* the Matrix server would need to be deployed with federation 
disabled (meaning, local user signups only, and no room sharing across 
the world), and public room sharing disabled as well.  We can certainly 
do this, but we have not tested that kind of setup yet.

But unless they make that choice, then the answer to Stephen's questions 
seem to be:

 > the duration for which any such rooms might last,

"forever", with no option to delete/close unless federation is disabled, and

 > how closed/open they may be etc.

"wide open to every Matrix server of every participating user."

Again speaking only for myself, my feeling is that all of the focus thus 
far on the technologies in this trial has been on how well we can bridge 
said technologies over to Jabber.  I suggest that if the IETF reaches a 
"trial2" stage, it would be more useful to focus on the technology 
itself (as if, as Michael suggests, a transition is the goal), rather 
than on how well things bridge to Jabber.  Bridging is fun... but I'm 
not sure it should really be the point... or, for that matter, even a 
factor.  I personally would be much more interested in how well each 
technology works *on its own*, rather than "as a copy of Jabber."

Hope this helps!

Glen

[1] ( https://matrix.org/faq/ , section: "Where do my conversations get 
stored?" which says, "Each replicated across all of the homeservers 
whose users are participating in a given room", and, farther down, under 
their definition of Federation, "data about rooms and message history is 
shared between servers of participating users.")