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.")
- [Tools-discuss] matrix tests Stephen Farrell
- Re: [Tools-discuss] matrix tests Michael Richardson
- Re: [Tools-discuss] matrix tests Matthew Wild
- Re: [Tools-discuss] matrix tests Glen
- Re: [Tools-discuss] matrix tests Stephen Farrell
- Re: [Tools-discuss] matrix tests Michael Richardson
- Re: [Tools-discuss] matrix tests Carsten Bormann
- Re: [Tools-discuss] matrix tests Matthew Hodgson