summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorBryan Bishop <kanzure@gmail.com>2023-11-07 09:37:22 -0600
committerbitcoindev <bitcoindev@gnusha.org>2023-11-07 15:37:42 +0000
commit01e06c67cdaaf041bd226f2aa1c58dd8abcdd08f (patch)
treef570d019e8ad8db4a0126273bf82fb3799b7e4de
parent832bc20d33669abd32ff836ea360929d0f5ef86c (diff)
downloadpi-bitcoindev-01e06c67cdaaf041bd226f2aa1c58dd8abcdd08f.tar.gz
pi-bitcoindev-01e06c67cdaaf041bd226f2aa1c58dd8abcdd08f.zip
[bitcoin-dev] Future of the bitcoin-dev mailing list
-rw-r--r--2d/dc9c7926f756dca07e6bb5c0cdb32a3ee917a0572
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&#39;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&#39;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&#39;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&#39;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&#39;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&#39;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&#39;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&#39;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 &quot;bad reputation&quot; =
+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&#39;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&#39;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&#39;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 &#39;arxiv of our own&#39; 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&#39;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&#39;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&#39;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&#39;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&#39;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--
+