path: root/b2/be16cea0b824f2ce3f07665acd81b1fa1424a9

Return-Path: <email@yancy.lol>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1FF65C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Nov 2023 09:13:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id E91A74169E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Nov 2023 09:13:31 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org E91A74169E
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Level: 
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7,
 RCVD_IN_RP_RNBL=0.001, RCVD_IN_VALIDITY_RPBL=1.31,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id E27gXZVenH2O
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Nov 2023 09:13:29 +0000 (UTC)
Received: from mslow1.mail.gandi.net (mslow1.mail.gandi.net [217.70.178.240])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 0768F4169B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Nov 2023 09:13:28 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 0768F4169B
Received: from relay4-d.mail.gandi.net (unknown [IPv6:2001:4b98:dc4:8::224])
 by mslow1.mail.gandi.net (Postfix) with ESMTP id E3CBBCABD2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Nov 2023 09:05:39 +0000 (UTC)
Received: by mail.gandi.net (Postfix) with ESMTPA id A97FBE000D;
 Wed,  8 Nov 2023 09:05:34 +0000 (UTC)
MIME-Version: 1.0
Date: Wed, 08 Nov 2023 10:05:34 +0100
From: email@yancy.lol
To: Andrew Chow <lists@achow101.com>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <a2435f58-9aff-4cfe-8d7a-8e7258e4f64e@achow101.com>
References: <CABaSBaz9OTSVa1KNk0GOrH3T-kRF_7OPVu0AtpuaFGVB=zhdwQ@mail.gmail.com>
 <a2435f58-9aff-4cfe-8d7a-8e7258e4f64e@achow101.com>
Message-ID: <0648792e3ed99ce9504b4227eb60ae89@yancy.lol>
X-Sender: email@yancy.lol
Content-Type: multipart/alternative;
 boundary="=_976d33f014f84f1ae6f7af940d498a55"
X-GND-Sasl: email@yancy.lol
X-Mailman-Approved-At: Thu, 09 Nov 2023 00:14:08 +0000
Subject: Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Nov 2023 09:13:32 -0000

--=_976d33f014f84f1ae6f7af940d498a55
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed


On 2023-11-07 17:12, Andrew Chow via bitcoin-dev wrote:

> I would prefer that we continue to have a mailing list where email is a
> functional and first class user interface. So that would be to migrate
> to groups.io or Google Groups. I think Google Groups is probably the
> better choice of the two.

+1 to migrating to a different email service.  That seems like the most 
straightforward solution.

On 2023-11-08 04:56, Anthony Towns via bitcoin-dev wrote:

> delvingbitcoin.org is something I setup

Cool, thanks!  It's great to have more channels of discussion.  Same 
with IRC etc.

Cheers,
-Yancy

> Andrew Chow
> 
> On 11/07/2023 10:37 AM, Bryan Bishop via bitcoin-dev wrote:
> 
>> Hello,
>> 
>> We would like to request community feedback and proposals on the 
>> future
>> of the mailing list.
>> 
>> Our current mailing list host, Linux Foundation, has indicated for 
>> years
>> that they have wanted to stop hosting mailing lists, which would mean
>> the bitcoin-dev mailing list would need to move somewhere else. We
>> temporarily avoided that, but recently LF has informed a moderator 
>> that
>> they will cease hosting any mailing lists later this year.
>> 
>> In this email, we will go over some of the history, options, and 
>> invite
>> discussion ahead of the cutoff. We have some ideas but want to solicit
>> feedback and proposals.
>> 
>> Background
>> ==========
>> 
>> The bitcoin-dev mailing list was originally hosted on Sourceforge.net.
>> The bitcoin development mailing list has been a source of proposals,
>> analysis, and developer discussion for many years in the bitcoin
>> community, with many thousands of participants. Later, the mailing 
>> list
>> was migrated to the Linux Foundation, and after that OSUOSL began to 
>> help.
>> 
>> Linux Foundation first asked us to move the mailing list in 2017. They
>> internally attempted to migrate all LF mailing lists from mailman2 to
>> mailman3, but ultimately gave up. There were reports of scalability
>> issues with mailman3 for large email communities. Ours definitely
>> qualifies as.. large.
>> 
>> 2019 migration plan: LF was to turn off mailman and all lists would
>> migrate to the paid service provider groups.io <http://groups.io>. 
>> Back
>> then we were given accounts to try the groups.io <http://groups.io>
>> interface and administration features. Apparently we were not the only
>> dev community who resisted change. To our surprise LF gave us several
>> years of reprieve by instead handing the subdomain and server-side 
>> data
>> to the non-profit OSUOSL lab who instead operated mailman2 for the 
>> past
>> ~4 years.
>> 
>> OSUOSL has for decades been well known for providing server
>> infrastructure for Linux and Open Source development so they were a 
>> good
>> fit. This however became an added maintenance burden for the small
>> non-profit with limited resources. Several members of the Bitcoin dev
>> community contributed funding to the lab in support of their Open 
>> Source
>> development infrastructure goals. But throwing money at the problem
>> isn't going to fix the ongoing maintenance burden created by 
>> antiquated
>> limitations of mailman2.
>> 
>> Permalinks
>> ==========
>> 
>> Linux Foundation has either offered or agreed to maintain archive
>> permalinks so that content of historic importance is not lost.
>> Fortunately for us while lists.linuxfoundation.org
>> <http://lists.linuxfoundation.org> mailman will go down, they have
>> agreed the read-only pipermail archives will remain online. So all old
>> URLs will continue to remain valid. However, the moderators strongly
>> advise that the community supplements with public-inbox instances to
>> have canonical archive urls that are separate from any particular 
>> email
>> software host.
>> 
>> Public-Inbox
>> ============
>> 
>> https://public-inbox.org/README.html 
>> <https://public-inbox.org/README.html>
>> 
>> "Public Inbox" decentralized archiving - no matter what mailing list
>> server solution is used, anyone can use git to maintain their own
>> mailing list archive and make it available to read on the web.
>> 
>> Public Inbox is a tool that you can run yourself. You can transform 
>> your
>> mbox file and it makes it browsable and viewable online. It commits
>> every post to a git repository. It's kind of like a decentralized mail
>> archiving tool. Anyone can publish the mail archive to any web server
>> they wish.
>> 
>> We should try to have one or more canonical archives that are served
>> using public-inbox. But it doesn't matter if these are lost because
>> anyone else can archive the mailing list in the same way and 
>> re-publish
>> the archives.
>> 
>> These git commits can also be stamped using opentimestamps, inserting
>> their hashes into the bitcoin blockchain.
>> 
>> LKML mailing list readers often use public-inbox's web interface, and
>> they use the reply-to headers to populate their mail client and reply 
>> to
>> threads of interest. This allows their reply to be properly threaded
>> even if they were not a previous subscriber to that mailing list to
>> receive the headers.
>> 
>> public-inbox makes it so that it doesn't really matter where the list 
>> is
>> hosted, as pertaining to reading the mailing list. There is still a
>> disruption if the mailing list goes away, but the archives live on and
>> then people can post elsewhere. The archive gets disconnected from the
>> mailing list host in terms of posting. We could have a few canonical
>> URLs for the hosts, separate from the mailing list server.
>> 
>> mailman problems
>> ================
>> 
>> Over the years we have identified a number of problems with mailman2
>> especially as it pertains to content moderation. There are presently a
>> handful of different moderators, but mailman2 only has a single 
>> password
>> for logging into the email management interface. There are no 
>> moderator
>> audit logs to see which user (there is no concept of different users)
>> acted on an email. There is no way to mark an email as being
>> investigated by one or more of the moderators. Sometimes, while
>> investigating the veracity of an email, another moderator would come 
>> in
>> and approve a suspect email by accident.
>> 
>> Anti spam has been an issue for the moderators. It's relentless. 
>> Without
>> access to the underlying server, it has been difficult to fight spam.
>> There is some support for filters in mailman2 but it's not great.
>> 
>> 100% active moderation and approval of every email is unsustainable 
>> for
>> volunteer moderators. A system that requires moderation is a heavy
>> burden on the moderators and it slows down overall communication and
>> productivity. There's lots of problems with this. Also, moderators can
>> be blamed when they are merely slow while they are not actually 
>> censoring.
>> 
>> Rejection emails can optionally be sent to
>> bitcoin-dev-moderation@lists.ozlabs.org
>> <mailto:bitcoin-dev-moderation@lists.ozlabs.org> but this is an option
>> that a moderator has to remember to type in each time.
>> 
>> Not to mention numerous bugs and vulnerabilities that have accumulated
>> over the years for relatively unmaintained software. (Not disclosed 
>> here)
>> 
>> Requirements and considerations
>> ===============================
>> 
>> Looking towards the future, there are a number of properties that seem
>> to be important for the bitcoin-dev mailing list community. First, it 
>> is
>> important that backups of the entire archive should be easy for the
>> public to copy or verify so that the system can be brought up 
>> elsewhere
>> if necessary.
>> 
>> Second, there seems to be demand for both an email threading interface
>> (using mailing list software) as well as web-accessible interfaces 
>> (such
>> as forum software). There seems to be very few options that cater to
>> both email and web. Often, in forum software, email support is limited
>> to email notifications and there is limited if any support for email
>> user participation.
>> 
>> Third, there should be better support for moderator tools and 
>> management
>> of the mailing list. See above for complaints about problems with the
>> mailman2 system.
>> 
>> Burdens of running your own mailing list and email server
>> =========================================================
>> 
>> If you have never operated your own MTA you have no idea how difficult
>> it is to keep secure and functional in the face of numerous challenges
>> to deliverability. Anti-spam filtering is essential to prevent
>> forwarding spam. The moment you forward even a single spam message you
>> run the risk of the server IP address being added to blacklists.
>> 
>> The problem of spam filtering is so bad that most IP addresses are
>> presumed guilty even if they have no prior spam history, such as if
>> their network or subnetwork had spam issues in the past.
>> 
>> Even if you put unlimited time into managing your own email server,
>> other people may not accept your email. Or you make one mistake, and
>> then you get into permanent blacklists and it's hard to remove. The 
>> spam
>> problem is so bad that most IPs are automatically on a
>> guilty-until-proven-innocent blacklist.
>> 
>> Often there is nothing you can do to get server IP addresses removed
>> from spam blacklists or from "bad reputation" lists.
>> 
>> Ironically, hashcash-style proof-of-work stamps to prevent spam are an
>> appealing solution but not widely used in this community. Or anywhere.
>> 
>> Infinite rejection or forwarding loops happen. They often need to be
>> detected through vigilance and require manual sysadmin intervention to
>> solve.
>> 
>> Bitcoin's dev lists being hosted alongside other Open Source projects
>> was previously protective. If that mailing list server became
>> blacklisted there were a lot of other people who would notice and
>> complain. If we run a Bitcoin-specific mail server we are on our own.
>> 100% of the administrative burden falls upon our own people. There is
>> also nothing we can do if some unknown admin decides they don't like 
>> us.
>> 
>> Options
>> =======
>> 
>> Web forums are an interesting option, but often don't have good email
>> user integration. At most you can usually hope for email notifications
>> and an ability to reply by email. It changes the model of the 
>> community
>> from push (email) to pull (logging into a forum to read). RSS feeds 
>> can
>> help a little bit.
>> 
>> Many other projects have moved from mailing lists to forums (eg
>> https://discuss.python.org/ <https://discuss.python.org/> - see
>> https://lwn.net/Articles/901744/ <https://lwn.net/Articles/901744/> ; 
>> or
>> https://ethresear.ch/ <https://ethresear.ch/>), which seem easier to
>> maintain and moderate, and can have lots of advanced features beyond
>> plaintext, maybe-threading and maybe-HTML-markup.
>> 
>> Who would host the forum? Would there be agreement around which forum
>> software to use or which forum host? What about bitcointalk.org
>> <http://bitcointalk.org> or delvingbitcoin.org
>> <http://delvingbitcoin.org>? There are many options available. Maybe
>> what we actually want isn't so much a discussion forum, as an 'arxiv 
>> of
>> our own' where anons can post BIP drafts and the like?
>> 
>> Given the problems with mailman2, and the decline of email communities
>> in general, it seems that moving to mailman3 would not be a viable
>> long-term option. This leaves us with Google Groups or groups.io
>> <http://groups.io> as two remaining options.
>> 
>> groups.io <http://groups.io> is an interesting option: they are a paid
>> service that implements email communities along with online web forum
>> support. However, their public changelog indicates it has been a few
>> years since their last public change. They might be a smaller company
>> and it is unclear how long they will be around or if this would be the
>> right fit for hosting sometimes contentious bitcoin development
>> discussions...
>> 
>> Google Groups is another interesting option, and comes with different
>> tradeoffs. It's the lowest effort to maintain option, and has both an
>> email interface and web forum interface. Users can choose which mode
>> they want to interact with.
>> 
>> For the Google Groups web interface, you can use it with a non-gmail
>> account, but you must create a Google Account which is free to do. it
>> does not require any personal information to do so. This also allows 
>> you
>> to add 2FA. Non-gmail non-google users are able to subscribe and post
>> email from their non-gmail non-google email accounts. Tor seems to 
>> work
>> for the web interface.
>> 
>> Will Google shut it down, will they cut us off, will they shut down
>> non-google users? The same problem exists with other third-party 
>> hosts.
>> 
>> The moderation capabilities for Google Groups and groups.io
>> <http://groups.io> seem to be comparable. It seems more likely that
>> Google Groups will be able to handle email delivery issues far better
>> than a small resource-constrained operation like groups.io
>> <http://groups.io>. ((During feedback for this draft, luke-jr 
>> indicates
>> that Google Workspaces has been known to use blacklisted IPs for
>> business email!))
>> 
>> On the other hand, groups.io <http://groups.io> is a paid service and
>> you get what you pay for... hopefully?
>> 
>> Finally, another option is to do literally nothing. It's less work
>> overall. Users can switch to forums or other websites, or private
>> one-on-one communication. It would remove a point of 
>> semi-centralization
>> from the bitcoin ecosystem. It would hasten ossification, but on the
>> other hand it would hasten ossification and this could be a negative
>> too. Moderators would be less of a target.
>> 
>> Unfortunately, by doing nothing, there would be no more widely used
>> group email communication system between bitcoin developers. 
>> Developers
>> become less coordinated, mayhem and chaos as people go to different
>> communication platforms, a divided community is more vulnerable, etc.
>> BIP1 and BIP2 would need to be revised for other venues.
>> 
>> The main categories of what to move to are: web forums, mailing lists,
>> and hybrids of those two options. Most everything is either 
>> self-hosted
>> or you pay someone else to host it. It's kind of the same problem
>> though. It largely depends on how good is the software and 
>> unfortunately
>> running your own MTA that forwards mail is not a good option.
>> 
>> Going forward
>> ===========
>> 
>> We'd like to invite feedback and proposals from the community, and see
>> what options are available. One potential option is a migration to
>> Google Groups, but we're open to ideas at this point. We apologize for
>> any inconvenience this disruption has caused.
>> 
>> Bitcoin-dev mailing list moderation team
>> 
>> Bryan Bishop
>> Ruben Somsen
>> Warren Togami
>> various others.
>> 
>> --
>> - Bryan
>> https://twitter.com/kanzure <https://twitter.com/kanzure>
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--=_976d33f014f84f1ae6f7af940d498a55
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family: Verdana,Gen=
eva,sans-serif'>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
On 2023-11-07 17:12, Andrew Chow via bitcoin-dev wrote:
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">I would prefer that we continue to have a mailing list=
 where email is a <br />functional and first class user interface. So that =
would be to migrate <br />to groups.io or Google Groups. I think Google Gro=
ups is probably the <br />better choice of the two.</blockquote>
<br />+1 to migrating to a different email service.&nbsp; That seems like t=
he most straightforward solution.<br /><br />On 2023-11-08 04:56, Anthony T=
owns via bitcoin-dev wrote:</div>
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
delvingbitcoin.org is something I setup</div>
</blockquote>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
&nbsp;</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
Cool, thanks!&nbsp; It's great to have more channels of discussion.&nbsp; S=
ame with IRC etc.</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
&nbsp;</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
Cheers,</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
-Yancy<br /><br />
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0"><br /><br />Andrew Chow<br /><br />On 11/07/2023 10:37=
 AM, Bryan Bishop via bitcoin-dev wrote:
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">Hello,<br /><br />We would like to request community&n=
bsp;feedback and proposals on the future<br />of the mailing list.<br /><br=
 />Our current mailing list host, Linux Foundation, has indicated for years=
<br />that they have wanted to stop hosting mailing lists, which would mean=
<br />the bitcoin-dev mailing list would need to move somewhere else. We<br=
 />temporarily avoided that, but recently LF has informed a moderator that<=
br />they will cease hosting any mailing lists later this year.<br /><br />=
In this email, we will go over some of the history, options, and invite<br =
/>discussion ahead of the cutoff. We have some ideas but want to solicit<br=
 />feedback and proposals.<br /><br />Background<br />=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D<br /><br />The bitcoin-dev mailing list was originally hosted on =
Sourceforge.net.<br />The bitcoin development mailing list has been a sourc=
e of proposals,<br />analysis, and developer discussion for many years in t=
he bitcoin<br />community, with many thousands of participants. Later, the =
mailing list<br />was migrated to the Linux Foundation, and after that OSUO=
SL began to help.<br /><br />Linux Foundation first asked us to move the ma=
iling list in 2017. They<br />internally attempted to migrate all LF mailin=
g lists from mailman2 to<br />mailman3, but ultimately gave up. There were =
reports of scalability<br />issues with mailman3 for large email communitie=
s. Ours definitely<br />qualifies as.. large.<br /><br />2019 migration pla=
n: LF was to turn off mailman and all lists would<br />migrate to the paid =
service provider groups.io &lt;<a href=3D"http://groups.io" target=3D"_blan=
k" rel=3D"noopener noreferrer">http://groups.io</a>&gt;. Back<br />then we =
were given accounts to try the groups.io &lt;<a href=3D"http://groups.io" t=
arget=3D"_blank" rel=3D"noopener noreferrer">http://groups.io</a>&gt;<br />=
interface and administration features. Apparently we were not the only<br /=
>dev community who resisted change. To our surprise LF gave us several<br /=
>years of reprieve by instead handing the subdomain and server-side data<br=
 />to the non-profit OSUOSL lab who instead operated mailman2 for the past<=
br />~4 years.<br /><br />OSUOSL has for decades been well known for provid=
ing server<br />infrastructure for Linux and Open Source development so the=
y were a good<br />fit. This however became an added maintenance burden for=
 the small<br />non-profit with limited resources. Several members of the B=
itcoin dev<br />community contributed funding to the lab in support of thei=
r Open Source<br />development infrastructure goals. But throwing money at =
the problem<br />isn&rsquo;t going to fix the ongoing maintenance burden cr=
eated by antiquated<br />limitations of mailman2.<br /><br />Permalinks<br =
/>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br /><br />Linux Foundation has either off=
ered or agreed to maintain archive<br />permalinks so that content of histo=
ric importance is not lost.<br />Fortunately for us while lists.linuxfounda=
tion.org<br />&lt;<a href=3D"http://lists.linuxfoundation.org" target=3D"_b=
lank" rel=3D"noopener noreferrer">http://lists.linuxfoundation.org</a>&gt; =
mailman will go down, they have<br />agreed the read-only pipermail archive=
s will remain online. So all old<br />URLs will continue to remain valid. H=
owever, the moderators strongly<br />advise that the community supplements =
with public-inbox instances to<br />have canonical archive urls that are se=
parate from any particular email<br />software host.<br /><br />Public-Inbo=
x<br />=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br /><br /><a href=3D"https://p=
ublic-inbox.org/README.html" target=3D"_blank" rel=3D"noopener noreferrer">=
https://public-inbox.org/README.html</a> &lt;<a href=3D"https://public-inbo=
x.org/README.html" target=3D"_blank" rel=3D"noopener noreferrer">https://pu=
blic-inbox.org/README.html</a>&gt;<br /><br />&ldquo;Public Inbox&rdquo; de=
centralized archiving - no matter what mailing list<br />server solution is=
 used, anyone can use git to maintain their own<br />mailing list archive a=
nd make it available to read on the web.<br /><br />Public Inbox is a tool =
that you can run yourself. You can transform your<br />mbox file and it mak=
es it browsable and viewable online. It commits<br />every post to a git re=
pository. It's kind of like a decentralized mail<br />archiving tool. Anyon=
e can publish the mail archive to any web server<br />they wish.<br /><br /=
>We should try to have one or more canonical archives that are served<br />=
using public-inbox. But it doesn't matter if these are lost because<br />an=
yone else can archive the mailing list in the same way and re-publish<br />=
the archives.<br /><br />These git commits can also be stamped using openti=
mestamps, inserting<br />their hashes into the bitcoin blockchain.<br /><br=
 />LKML mailing list readers often use public-inbox's web interface, and<br=
 />they use the reply-to headers to populate their mail client and reply to=
<br />threads of interest. This allows their reply to be properly threaded<=
br />even if they were not a previous subscriber to that mailing list to<br=
 />receive the headers.<br /><br />public-inbox makes it so that it doesn't=
 really matter where the list is<br />hosted, as pertaining to reading the =
mailing list. There is still a<br />disruption if the mailing list goes awa=
y, but the archives live on and<br />then people can post elsewhere. The ar=
chive gets disconnected from the<br />mailing list host in terms of posting=
=2E We could have a few canonical<br />URLs for the hosts, separate from th=
e mailing list server.<br /><br />mailman problems<br />=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br /><br />Over the years we have identified=
 a number of problems with mailman2<br />especially as it pertains to conte=
nt moderation. There are presently a<br />handful of different moderators, =
but mailman2 only has a single password<br />for logging into the email man=
agement interface. There are no moderator<br />audit logs to see which user=
 (there is no concept of different users)<br />acted on an email. There is =
no way to mark an email as being<br />investigated by one or more of the mo=
derators. Sometimes, while<br />investigating the veracity of an email, ano=
ther moderator would come in<br />and approve a suspect email by accident.<=
br /><br />Anti spam has been an issue for the moderators. It's relentless.=
 Without<br />access to the underlying server, it has been difficult to fig=
ht spam.<br />There is some support for filters in mailman2 but it's not gr=
eat.<br /><br />100% active moderation and approval of every email is unsus=
tainable for<br />volunteer moderators. A system that requires moderation i=
s a heavy<br />burden on the moderators and it slows down overall communica=
tion and<br />productivity. There's lots of problems with this. Also, moder=
ators can<br />be blamed when they are merely slow while they are not actua=
lly censoring.<br /><br />Rejection emails can optionally be sent to<br /><=
a href=3D"mailto:bitcoin-dev-moderation@lists.ozlabs.org">bitcoin-dev-moder=
ation@lists.ozlabs.org</a><br />&lt;mailto:<a href=3D"mailto:bitcoin-dev-mo=
deration@lists.ozlabs.org">bitcoin-dev-moderation@lists.ozlabs.org</a>&gt; =
but this is an option<br />that a moderator has to remember to type in each=
 time.<br /><br />Not to mention numerous bugs and vulnerabilities that hav=
e accumulated<br />over the years for relatively unmaintained software. (No=
t disclosed here)<br /><br />Requirements and considerations<br />=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D<br /><br />Looking towards the future, there are a number of prop=
erties that seem<br />to be important for the bitcoin-dev mailing list comm=
unity. First, it is<br />important that backups of the entire archive shoul=
d be easy for the<br />public to copy or verify so that the system can be b=
rought up elsewhere<br />if necessary.<br /><br />Second, there seems to be=
 demand for both an email threading interface<br />(using mailing list soft=
ware) as well as web-accessible interfaces (such<br />as forum software). T=
here seems to be very few options that cater to<br />both email and web. Of=
ten, in forum software, email support is limited<br />to email notification=
s and there is limited if any support for email<br />user participation.<br=
 /><br />Third, there should be better support for moderator tools and mana=
gement<br />of the mailing list. See above for complaints about problems wi=
th the<br />mailman2 system.<br /><br />Burdens of running your own mailing=
 list and email server<br />=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br /><br />If you have =
never operated your own MTA you have no idea how difficult<br />it is to ke=
ep secure and functional in the face of numerous challenges<br />to deliver=
ability. Anti-spam filtering is essential to prevent<br />forwarding spam. =
The moment you forward even a single spam message you<br />run the risk of =
the server IP address being added to blacklists.<br /><br />The problem of =
spam filtering is so bad that most IP addresses are<br />presumed guilty ev=
en if they have no prior spam history, such as if<br />their network or sub=
network had spam issues in the past.<br /><br />Even if you put unlimited t=
ime into managing your own email server,<br />other people may not accept y=
our email. Or you make one mistake, and<br />then you get into permanent bl=
acklists and it's hard to remove. The spam<br />problem is so bad that most=
 IPs are automatically on a<br />guilty-until-proven-innocent blacklist.<br=
 /><br />Often there is nothing you can do to get server IP addresses remov=
ed<br />from spam blacklists or from "bad reputation" lists.<br /><br />Iro=
nically, hashcash-style proof-of-work stamps to prevent spam are an<br />ap=
pealing solution but not widely used in this community. Or anywhere.<br /><=
br />Infinite rejection or forwarding loops happen. They often need to be<b=
r />detected through vigilance and require manual sysadmin intervention to<=
br />solve.<br /><br />Bitcoin's dev lists being hosted alongside other Ope=
n Source projects<br />was previously protective. If that mailing list serv=
er became<br />blacklisted there were a lot of other people who would notic=
e and<br />complain. If we run a Bitcoin-specific mail server we are on our=
 own.<br />100% of the administrative burden falls upon our own people. The=
re is<br />also nothing we can do if some unknown admin decides they don't =
like us.<br /><br />Options<br />=3D=3D=3D=3D=3D=3D=3D<br /><br />Web forum=
s are an interesting option, but often don't have good email<br />user inte=
gration. At most you can usually hope for email notifications<br />and an a=
bility to reply by email. It changes the model of the community<br />from p=
ush (email) to pull (logging into a forum to read). RSS feeds can<br />help=
 a little bit.<br /><br />Many other projects have moved from mailing lists=
 to forums (eg<br /><a href=3D"https://discuss.python.org/" target=3D"_blan=
k" rel=3D"noopener noreferrer">https://discuss.python.org/</a> &lt;<a href=
=3D"https://discuss.python.org/" target=3D"_blank" rel=3D"noopener noreferr=
er">https://discuss.python.org/</a>&gt; &ndash; see<br /><a href=3D"https:/=
/lwn.net/Articles/901744/" target=3D"_blank" rel=3D"noopener noreferrer">ht=
tps://lwn.net/Articles/901744/</a> &lt;<a href=3D"https://lwn.net/Articles/=
901744/" target=3D"_blank" rel=3D"noopener noreferrer">https://lwn.net/Arti=
cles/901744/</a>&gt; ; or<br /><a href=3D"https://ethresear.ch/" target=3D"=
_blank" rel=3D"noopener noreferrer">https://ethresear.ch/</a> &lt;<a href=
=3D"https://ethresear.ch/" target=3D"_blank" rel=3D"noopener noreferrer">ht=
tps://ethresear.ch/</a>&gt;), which seem easier to<br />maintain and modera=
te, and can have lots of advanced features beyond<br />plaintext, maybe-thr=
eading and maybe-HTML-markup.<br /><br />Who would host the forum? Would th=
ere be agreement around which forum<br />software to use or which forum hos=
t? What about bitcointalk.org<br />&lt;<a href=3D"http://bitcointalk.org" t=
arget=3D"_blank" rel=3D"noopener noreferrer">http://bitcointalk.org</a>&gt;=
 or delvingbitcoin.org<br />&lt;<a href=3D"http://delvingbitcoin.org" targe=
t=3D"_blank" rel=3D"noopener noreferrer">http://delvingbitcoin.org</a>&gt;?=
 There are many options available. Maybe<br />what we actually want isn&rsq=
uo;t so much a discussion forum, as an 'arxiv of<br />our own' where anons =
can post BIP drafts and the like?<br /><br />Given the problems with mailma=
n2, and the decline of email communities<br />in general, it seems that mov=
ing to mailman3 would not be a viable<br />long-term option. This leaves us=
 with Google Groups or groups.io<br />&lt;<a href=3D"http://groups.io" targ=
et=3D"_blank" rel=3D"noopener noreferrer">http://groups.io</a>&gt; as two r=
emaining options.<br /><br />groups.io &lt;<a href=3D"http://groups.io" tar=
get=3D"_blank" rel=3D"noopener noreferrer">http://groups.io</a>&gt; is an i=
nteresting option: they are a paid<br />service that implements email commu=
nities along with online web forum<br />support. However, their public chan=
gelog indicates it has been a few<br />years since their last public change=
=2E They might be a smaller company<br />and it is unclear how long they wi=
ll be around or if this would be the<br />right fit for hosting sometimes c=
ontentious bitcoin development<br />discussions...<br /><br />Google Groups=
 is another interesting option, and comes with different<br />tradeoffs. It=
's the lowest effort to maintain option, and has both an<br />email interfa=
ce and web forum interface. Users can choose which mode<br />they want to i=
nteract with.<br /><br />For the Google Groups web interface, you can use i=
t with a non-gmail<br />account, but you must create a Google Account which=
 is free to do. it<br />does not require any personal information to do so.=
 This also allows you<br />to add 2FA. Non-gmail non-google users are able =
to subscribe and post<br />email from their non-gmail non-google email acco=
unts. Tor seems to work<br />for the web interface.<br /><br />Will Google =
shut it down, will they cut us off, will they shut down<br />non-google use=
rs? The same problem exists with other third-party hosts.<br /><br />The mo=
deration capabilities for Google Groups and groups.io<br />&lt;<a href=3D"h=
ttp://groups.io" target=3D"_blank" rel=3D"noopener noreferrer">http://group=
s.io</a>&gt; seem to be comparable. It seems more likely that<br />Google G=
roups will be able to handle email delivery issues far better<br />than a s=
mall resource-constrained operation like groups.io<br />&lt;<a href=3D"http=
://groups.io" target=3D"_blank" rel=3D"noopener noreferrer">http://groups.i=
o</a>&gt;. ((During feedback for this draft, luke-jr indicates<br />that Go=
ogle Workspaces has been known to use blacklisted IPs for<br />business ema=
il!))<br /><br />On the other hand, groups.io &lt;<a href=3D"http://groups.=
io" target=3D"_blank" rel=3D"noopener noreferrer">http://groups.io</a>&gt; =
is a paid service and<br />you get what you pay for... hopefully?<br /><br =
/>Finally, another option is to do literally nothing. It's less work<br />o=
verall. Users can switch to forums or other websites, or private<br />one-o=
n-one communication. It would remove a point of semi-centralization<br />fr=
om the bitcoin ecosystem. It would hasten ossification, but on the<br />oth=
er hand it would hasten ossification and this could be a negative<br />too.=
 Moderators would be less of a target.<br /><br />Unfortunately, by doing n=
othing, there would be no more widely used<br />group email communication s=
ystem between bitcoin developers. Developers<br />become less coordinated, =
mayhem and chaos as people go to different<br />communication platforms, a =
divided community is more vulnerable, etc.<br />BIP1 and BIP2 would need to=
 be revised for other venues.<br /><br />The main categories of what to mov=
e to are: web forums, mailing lists,<br />and hybrids of those two options.=
 Most everything is either self-hosted<br />or you pay someone else to host=
 it. It's kind of the same problem<br />though. It largely depends on how g=
ood is the software and unfortunately<br />running your own MTA that forwar=
ds mail is not a good option.<br /><br />Going forward<br />=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D<br /><br />We'd like to invite feedback and proposals fr=
om the community, and see<br />what options are available. One potential op=
tion is a migration to<br />Google Groups, but we're open to ideas at this =
point. We apologize for<br />any inconvenience this disruption has caused.<=
br /><br /><br />Bitcoin-dev mailing list moderation team<br /><br />Bryan =
Bishop<br />Ruben Somsen<br />Warren Togami<br />various others.<br /><br /=
>--<br />- Bryan<br /><a href=3D"https://twitter.com/kanzure" target=3D"_bl=
ank" rel=3D"noopener noreferrer">https://twitter.com/kanzure</a> &lt;<a hre=
f=3D"https://twitter.com/kanzure" target=3D"_blank" rel=3D"noopener norefer=
rer">https://twitter.com/kanzure</a>&gt;</blockquote>
<br />_______________________________________________<br />bitcoin-dev mail=
ing list<br /><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitc=
oin-dev@lists.linuxfoundation.org</a><br /><a href=3D"https://lists.linuxfo=
undation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank" rel=3D"noopene=
r noreferrer">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-de=
v</a></blockquote>
</div>
</body></html>

--=_976d33f014f84f1ae6f7af940d498a55--