[TOOLS-DEVELOPMENT] Fwd: Re: [Tools-discuss] Etherpad no longer on standard port

Robert Sparks <rjsparks@nostrum.com> Fri, 06 March 2020 22:20 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: tools-development@ietfa.amsl.com
Delivered-To: tools-development@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994E03A0BF7 for <tools-development@ietfa.amsl.com>; Fri, 6 Mar 2020 14:20:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.079
X-Spam-Level:
X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
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 LR9JZByruNBp for <tools-development@ietfa.amsl.com>; Fri, 6 Mar 2020 14:20:12 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29A813A0BF6 for <tools-development@ietf.org>; Fri, 6 Mar 2020 14:20:12 -0800 (PST)
Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 026MKAmt031514 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 6 Mar 2020 16:20:11 -0600 (CST) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1583533211; bh=Q5ZCIH1ZvhyqMPJixYtBZE+Mn7f1nCojEjLYr7OgVGs=; h=Subject:References:To:Cc:From:Date:In-Reply-To; b=ubNnYzb80wA0rHd+9/bZb47AJ3HjiWiS9+i6ZPCWpLFAPQzw8dtYwBBQopyyhEhRD V2LyzR09IULZbWWQpBQBs4T1Ld2cXVk1lL2hzjwXPd35n7F6YJz3uGx7DbLV9VkfOs ar+TDAwI3fVjv8JTn94YOeIE6AabdAumayqCUAgQ=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local
References: <D17E43EE-27AB-4471-9E8A-420EECD4BB79@tzi.org>
To: IETF Tools Development <tools-development@ietf.org>
Cc: Carsten Bormann <cabo@tzi.org>
From: Robert Sparks <rjsparks@nostrum.com>
X-Forwarded-Message-Id: <D17E43EE-27AB-4471-9E8A-420EECD4BB79@tzi.org>
Message-ID: <1d345839-14a3-af07-bd8b-58df5528d328@nostrum.com>
Date: Fri, 06 Mar 2020 16:20:09 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <D17E43EE-27AB-4471-9E8A-420EECD4BB79@tzi.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-development/SQCBUzmvCpauhu-33ZpF6oyub_Q>
Subject: [TOOLS-DEVELOPMENT] Fwd: Re: [Tools-discuss] Etherpad no longer on standard port
X-BeenThere: tools-development@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Tools Development list server <tools-development.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-development>, <mailto:tools-development-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-development/>
List-Post: <mailto:tools-development@ietf.org>
List-Help: <mailto:tools-development-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-development>, <mailto:tools-development-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Mar 2020 22:20:14 -0000

Carsten wrote:

>
> So my take is that there is additional incentive to look for what’s 
> next after Etherpad, for functional as much as for those operational 
> reasons.
> I repeat my ceterum censeo that hackmd/CodiMD is a viable candidate, 
> but that observation is not addressed at operational people at this 
> point (although we’d have to figure out whether that can be run 
> reliably — the sysadmins at my university tell me they can).

This looks like it would be easy to deploy to me and it passes a first 
sniff-test at keeping it going.

I was able to do a one-click deploy in heroku, and tweaking options to 
make it be fairly wide open was simple.

By default, it requires some simple registration (it allows on-instance 
registration with an email address that it doesn't verify). In the long 
run, it could be made to require datatracker credentials with what I 
currently think isn't a _lot_ of work (depending on the current quality 
of the django libraries to facilitate becoming an OAUTH2 provider).

I'd like to see us seriously investigate supporting this soon.

RjS