diff options
author | Bryan Bishop <kanzure@gmail.com> | 2023-11-07 09:37:22 -0600 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2023-11-07 15:37:42 +0000 |
commit | 01e06c67cdaaf041bd226f2aa1c58dd8abcdd08f (patch) | |
tree | f570d019e8ad8db4a0126273bf82fb3799b7e4de | |
parent | 832bc20d33669abd32ff836ea360929d0f5ef86c (diff) | |
download | pi-bitcoindev-01e06c67cdaaf041bd226f2aa1c58dd8abcdd08f.tar.gz pi-bitcoindev-01e06c67cdaaf041bd226f2aa1c58dd8abcdd08f.zip |
[bitcoin-dev] Future of the bitcoin-dev mailing list
-rw-r--r-- | 2d/dc9c7926f756dca07e6bb5c0cdb32a3ee917a0 | 572 |
1 files changed, 572 insertions, 0 deletions
diff --git a/2d/dc9c7926f756dca07e6bb5c0cdb32a3ee917a0 b/2d/dc9c7926f756dca07e6bb5c0cdb32a3ee917a0 new file mode 100644 index 000000000..05c01dea7 --- /dev/null +++ b/2d/dc9c7926f756dca07e6bb5c0cdb32a3ee917a0 @@ -0,0 +1,572 @@ +Return-Path: <kanzure@gmail.com> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id A2747C0032 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 7 Nov 2023 15:37:42 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp2.osuosl.org (Postfix) with ESMTP id 7A3964183D + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 7 Nov 2023 15:37:42 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 7A3964183D +Authentication-Results: smtp2.osuosl.org; + dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com + header.a=rsa-sha256 header.s=20230601 header.b=ccwSdu95 +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.098 +X-Spam-Level: +X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, + SPF_PASS=-0.001] autolearn=ham autolearn_force=no +Received: from smtp2.osuosl.org ([127.0.0.1]) + by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id WORLZqlT2yZG + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 7 Nov 2023 15:37:40 +0000 (UTC) +Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com + [IPv6:2a00:1450:4864:20::231]) + by smtp2.osuosl.org (Postfix) with ESMTPS id 6FFDF408C0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 7 Nov 2023 15:37:39 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6FFDF408C0 +Received: by mail-lj1-x231.google.com with SMTP id + 38308e7fff4ca-2c50cf61f6dso79428191fa.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 07 Nov 2023 07:37:39 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=gmail.com; s=20230601; t=1699371456; x=1699976256; + darn=lists.linuxfoundation.org; + h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject + :date:message-id:reply-to; + bh=v6SDgJj7o2NJb9dPe45w2PP+ieUFiOS7ooTMyWmkx2g=; + b=ccwSdu95rlBuufIakr+Acj/yVqnkFHOjYR+8bzT6Gk2tM4cDIMEmHEHiGPzQ9y4jIL + +J2Aw8z9u77oiNt00RKzW1djrRYRzIrnZfgQmzVlC8A6rdCMhhYnfO23XNxMTa2NkwmE + DQWN6XUJlwf5hGSk47CwgSJqm+k3LyjZ6cXLxsBfxC+/jmNLt8rKQianGBHrgDPtWMw1 + 8xiHcdn0vcbzaRtmAHq74U97RZ9qabXXvmTnUxwdAcrU/litaMvVR/+0faTrO1Qm6jqG + vWUGg5g0y0qgMTaX7NOIjd/Wyb2sgEoWsayAh7XkotZRiA80ulUyl42gJbp8gMeMu7ml + EIvw== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20230601; t=1699371456; x=1699976256; + h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state + :from:to:cc:subject:date:message-id:reply-to; + bh=v6SDgJj7o2NJb9dPe45w2PP+ieUFiOS7ooTMyWmkx2g=; + b=Fc00ryE0W/2iekgEoALsi+M6iZ08KfUao87lDQFGmOG9G3njucVy87MFw0AJXEt0lc + 7XlQcJgyPWyfa4Wh+lHlbNms2jYq56htmDroZF1eoEspgYPXttvJq1gWPsyrvo0WSKBz + OBD4E8nydf0K92qtwDI4oRXGwj3aAbj9LvOLWEeaq3ADtm1GVucpqxfrqVDeJ3omXu68 + MpHrN2V4G3/Y+5C59lRoF0VfqOd3xBLg46jkFKHN3H1Ym5lXOmSkDHZBiu5ZVxS4MaNy + ewFBDSK8CaKL4bVOuBwAzTha+KflUQScPWjLoPD89VbmKLmtiBdhEq5cHCQmSSsErCS2 + cLbQ== +X-Gm-Message-State: AOJu0Yw6wyBOSIbxaIkuyNi1G3KczT+O9ZTrZDoctpxVbTYgUXf8F2dB + peyVu0jW/rReg1AHf+HLVEccjy66JHsRIqSq5pF+88mGUok= +X-Google-Smtp-Source: AGHT+IHa2L8g7kU8R8Ur6HrkKC6Wr3wdS4lWhIVdy74XAwQ3xFVSzvY6useRKG/KAzGOKk6CCX1+06C35cs72ygJM0A= +X-Received: by 2002:a2e:8054:0:b0:2c5:1542:6147 with SMTP id + p20-20020a2e8054000000b002c515426147mr25550907ljg.15.1699371456021; Tue, 07 + Nov 2023 07:37:36 -0800 (PST) +MIME-Version: 1.0 +From: Bryan Bishop <kanzure@gmail.com> +Date: Tue, 7 Nov 2023 09:37:22 -0600 +Message-ID: <CABaSBaz9OTSVa1KNk0GOrH3T-kRF_7OPVu0AtpuaFGVB=zhdwQ@mail.gmail.com> +To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="000000000000fa4a75060991bff2" +Subject: [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: Tue, 07 Nov 2023 15:37:42 -0000 + +--000000000000fa4a75060991bff2 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +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 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +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. Back then we were given accounts to +try the 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=E2=80=99t going to fix the ong= +oing +maintenance burden created by antiquated limitations of mailman2. + +Permalinks +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +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 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 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +https://public-inbox.org/README.html + +=E2=80=9CPublic Inbox=E2=80=9D decentralized archiving - no matter what mai= +ling 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 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +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 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 +=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 + +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 +=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 + +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 +=3D=3D=3D=3D=3D=3D=3D + +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/ =E2=80=93 see https://lwn.net/Articles/901744/ = +; or +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 or +delvingbitcoin.org? There are many options available. Maybe what we +actually want isn=E2=80=99t 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 as two remaining +options. + +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 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. ((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 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 +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +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. + +--=20 +- Bryan +https://twitter.com/kanzure + +--000000000000fa4a75060991bff2 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Hello,<br><br>We would like to request community=C2=A0feed= +back and proposals on the future of the mailing list.<div><br><div>Our curr= +ent 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 tha= +t, but recently LF has informed a moderator that they will cease hosting an= +y mailing lists later this year.</div><div><br>In this email, we will go ov= +er some of the history, options, and invite discussion ahead of the cutoff.= + We have some ideas but want to solicit feedback and proposals.<br><br>Back= +ground<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br><br>The bitcoin-dev mailing lis= +t was originally hosted on Sourceforge.net. The bitcoin development mailing= + list has been a source of proposals, analysis, and developer discussion fo= +r many years in the bitcoin community, with many thousands of participants.= + Later, the mailing list was migrated to the Linux Foundation, and after th= +at OSUOSL began to help.<br><br>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 defi= +nitely qualifies as.. large.<br><br>2019 migration plan: LF was to turn off= + mailman and all lists would migrate to the paid service provider <a href= +=3D"http://groups.io">groups.io</a>. Back then we were given accounts to tr= +y the <a href=3D"http://groups.io">groups.io</a> interface and administrati= +on features. Apparently we were not the only dev community who resisted cha= +nge. To our surprise LF gave us several years of reprieve by instead handin= +g the subdomain and server-side data to the non-profit OSUOSL lab who inste= +ad operated mailman2 for the past ~4 years.<br><br>OSUOSL has for decades b= +een well known for providing server infrastructure for Linux and Open Sourc= +e development so they were a good fit. This however became an added mainten= +ance burden for the small non-profit with limited resources. Several member= +s 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=E2=80=99t going to fix the ongoing maintenance burden creat= +ed by antiquated limitations of mailman2.<br><br>Permalinks<br>=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D<br><br>Linux Foundation has either offered or agreed to = +maintain archive permalinks so that content of historic importance is not l= +ost. Fortunately for us while <a href=3D"http://lists.linuxfoundation.org">= +lists.linuxfoundation.org</a> mailman will go down, they have agreed the re= +ad-only pipermail archives will remain online. So all old URLs will continu= +e to remain valid. However, the moderators strongly advise that the communi= +ty supplements with public-inbox instances to have canonical archive urls t= +hat are separate from any particular email software host.<br><br>Public-Inb= +ox<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br><br><a href=3D"https://public= +-inbox.org/README.html">https://public-inbox.org/README.html</a><br><br>=E2= +=80=9CPublic Inbox=E2=80=9D decentralized archiving - no matter what mailin= +g list server solution is used, anyone can use git to maintain their own ma= +iling list archive and make it available to read on the web.<br><br>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.<br><br>We = +should try to have one or more canonical archives that are served using pub= +lic-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.<b= +r><br>These git commits can also be stamped using opentimestamps, inserting= + their hashes into the bitcoin blockchain.<br><br>LKML mailing list readers= + often use public-inbox's web interface, and they use the reply-to head= +ers to populate their mail client and reply to threads of interest. This al= +lows their reply to be properly threaded even if they were not a previous s= +ubscriber to that mailing list to receive the headers.<br><br>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 e= +lsewhere. The archive gets disconnected from the mailing list host in terms= + of posting. We could have a few canonical URLs for the hosts, separate fro= +m the 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 numb= +er of problems with mailman2 especially as it pertains to content moderatio= +n. There are presently a handful of different moderators, but mailman2 only= + has a single password for logging into the email management interface. The= +re are no moderator audit logs to see which user (there is no concept of di= +fferent 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 investigat= +ing the veracity of an email, another moderator would come in and approve a= + suspect email by accident.<br><br>Anti spam has been an issue for the mode= +rators. It's relentless. Without access to the underlying server, it ha= +s been difficult to fight spam. There is some support for filters in mailma= +n2 but it's not great.<br><br>100% active moderation and approval of ev= +ery email is unsustainable for volunteer moderators. A system that requires= + moderation is a heavy burden on the moderators and it slows down overall c= +ommunication and productivity. There's lots of problems with this. Also= +, moderators can be blamed when they are merely slow while they are not act= +ually censoring.<br><br>Rejection emails can optionally be sent to <a href= +=3D"mailto:bitcoin-dev-moderation@lists.ozlabs.org">bitcoin-dev-moderation@= +lists.ozlabs.org</a> but this is an option that a moderator has to remember= + to type in each time.<br><br>Not to mention numerous bugs and vulnerabilit= +ies that have accumulated over the years for relatively unmaintained softwa= +re. (Not 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 prope= +rties 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 f= +or the public to copy or verify so that the system can be brought up elsewh= +ere if necessary.<br><br>Second, there seems to be demand for both an email= + threading interface (using mailing list software) as well as web-accessibl= +e interfaces (such as forum software). There seems to be very few options t= +hat 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 ema= +il user participation.<br><br>Third, there should be better support for mod= +erator tools and management of the mailing list. See above for complaints a= +bout problems with the 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 n= +ever operated your own MTA you have no idea how difficult it is to keep sec= +ure and functional in the face of numerous challenges to deliverability. An= +ti-spam filtering is essential to prevent forwarding spam. The moment you f= +orward even a single spam message you 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 presumed guilty even if they have no prior spam = +history, such as if their network or subnetwork had spam issues in the past= +.<br><br>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 pr= +oblem is so bad that most IPs are automatically on a guilty-until-proven-in= +nocent blacklist.<br><br>Often there is nothing you can do to get server IP= + addresses removed from spam blacklists or from "bad reputation" = +lists.<br><br>Ironically, hashcash-style proof-of-work stamps to prevent sp= +am are an appealing solution but not widely used in this community. Or anyw= +here.<br><br>Infinite rejection or forwarding loops happen. They often need= + to be detected through vigilance and require manual sysadmin intervention = +to solve.<br><br>Bitcoin's dev lists being hosted alongside other Open = +Source projects was previously protective. If that mailing list server beca= +me blacklisted there were a lot of other people who would notice and compla= +in. 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.<br><br>Options= +<br>=3D=3D=3D=3D=3D=3D=3D<br><br>Web forums are an interesting option, but = +often don't have good email user integration. At most you can usually h= +ope for email notifications and an ability to reply by email. It changes th= +e model of the community from push (email) to pull (logging into a forum to= + read). RSS feeds can help a little bit.<br><br>Many other projects have mo= +ved from mailing lists to forums (eg <a href=3D"https://discuss.python.org/= +">https://discuss.python.org/</a> =E2=80=93 see <a href=3D"https://lwn.net/= +Articles/901744/">https://lwn.net/Articles/901744/</a> ; or <a href=3D"http= +s://ethresear.ch/">https://ethresear.ch/</a>), which seem easier to maintai= +n and moderate, and can have lots of advanced features beyond plaintext, ma= +ybe-threading and maybe-HTML-markup.<br><br>Who would host the forum? Would= + there be agreement around which forum software to use or which forum host?= + What about <a href=3D"http://bitcointalk.org">bitcointalk.org</a> or <a hr= +ef=3D"http://delvingbitcoin.org">delvingbitcoin.org</a>? There are many opt= +ions available. Maybe what we actually want isn=E2=80=99t so much a discuss= +ion forum, as an 'arxiv of our own' where anons can post BIP drafts= + and the like?<br><br>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 <a href=3D= +"http://groups.io">groups.io</a> as two remaining options.<br><br><a href= +=3D"http://groups.io">groups.io</a> is an interesting option: they are a pa= +id service that implements email communities along with online web forum su= +pport. However, their public changelog indicates it has been a few years si= +nce their last public change. They might be a smaller company and it is unc= +lear how long they will be around or if this would be the right fit for hos= +ting sometimes contentious bitcoin development discussions...<br><br>Google= + Groups is another interesting option, and comes with different tradeoffs. = +It's the lowest effort to maintain option, and has both an email interf= +ace and web forum interface. Users can choose which mode they want to inter= +act with.<br><br>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 d= +o. 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 e= +mail from their non-gmail non-google email accounts. Tor seems to work for = +the web interface. <br><br>Will Google shut it down, will they cut us off, = +will they shut down non-google users? The same problem exists with other th= +ird-party hosts.<br><br>The moderation capabilities for Google Groups and <= +a href=3D"http://groups.io">groups.io</a> seem to be comparable. It seems m= +ore likely that Google Groups will be able to handle email delivery issues = +far better than a small resource-constrained operation like <a href=3D"http= +://groups.io">groups.io</a>. ((During feedback for this draft, luke-jr indi= +cates that Google Workspaces has been known to use blacklisted IPs for busi= +ness email!))<br><br>On the other hand, <a href=3D"http://groups.io">groups= +.io</a> is a paid service and you get what you pay for... hopefully?<br><br= +>Finally, another option is to do literally nothing. It's less work ove= +rall. Users can switch to forums or other websites, or private one-on-one c= +ommunication. It would remove a point of semi-centralization from the bitco= +in ecosystem. It would hasten ossification, but on the other hand it would = +hasten ossification and this could be a negative too. Moderators would be l= +ess of a target.<br><br>Unfortunately, by doing nothing, there would be no = +more widely used group email communication system between bitcoin developer= +s. Developers become less coordinated, mayhem and chaos as people go to dif= +ferent communication platforms, a divided community is more vulnerable, etc= +. BIP1 and BIP2 would need to be revised for other venues.<br><br>The main = +categories of what to move to are: web forums, mailing lists, and hybrids o= +f those two options. Most everything is either self-hosted or you pay someo= +ne else to host it. It's kind of the same problem though. It largely de= +pends on how good is the software and unfortunately running your own MTA th= +at forwards 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= + from the community, and see what options are available. One potential opti= +on is a migration to Google Groups, but we're open to ideas at this poi= +nt. We apologize for any inconvenience this disruption has caused.<br><br><= +br>Bitcoin-dev mailing list moderation team<br><br>Bryan Bishop<br>Ruben So= +msen<br>Warren Togami<br>various others.<br><div><br></div><span class=3D"g= +mail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signat= +ure" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">- Bryan<br><a href= +=3D"https://twitter.com/kanzure" target=3D"_blank">https://twitter.com/kanz= +ure</a></div></div></div></div></div> + +--000000000000fa4a75060991bff2-- + |