From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1FC30C0032 for ; Tue, 7 Nov 2023 22:20:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 0140E403E7 for ; Tue, 7 Nov 2023 22:20:13 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 0140E403E7 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=disroot.org header.i=@disroot.org header.a=rsa-sha256 header.s=mail header.b=EkD3RzK+ X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, 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 QH8PO97GZ1bQ for ; Tue, 7 Nov 2023 22:20:09 +0000 (UTC) X-Greylist: delayed 549 seconds by postgrey-1.37 at util1.osuosl.org; Tue, 07 Nov 2023 22:20:08 UTC DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org E72F740182 Received: from layka.disroot.org (layka.disroot.org [178.21.23.139]) by smtp2.osuosl.org (Postfix) with ESMTPS id E72F740182 for ; Tue, 7 Nov 2023 22:20:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id BAE6841930; Tue, 7 Nov 2023 23:10:56 +0100 (CET) X-Virus-Scanned: SPAM Filter at disroot.org Received: from layka.disroot.org ([127.0.0.1]) by localhost (disroot.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHF61C-fUHP6; Tue, 7 Nov 2023 23:10:54 +0100 (CET) Date: Tue, 07 Nov 2023 23:10:39 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1699395053; bh=ijjeG94XTvq7ORABZGwXnsgFOdBcOAMjX05SAnRk6hg=; h=Date:From:To:Subject:In-Reply-To:References; b=EkD3RzK+3qkDzsczahxtJbLdiCgFpNl7UrRK4sagMi30CphWB/IsKtw8b27N5zx64 U0Mv4yyWn6QlUcq1sIERq61WHj0TyzicHpyikQQpkiVGNNjMKKIeXjZuu+MUxyod66 U1LhZBrkxUnaBeZ66F5ku7JE7Vyq7KlCWX3bF3EsUTphRw+QMk9sYaN57hGtQBJsUv UcSNnPJxRb+1cStC6bcSV3AMHtczferXsiUDB0Mk7qnvSCCHJoseIJch2SvD7RGfi+ q0eKCOrB1iPeVv4vRIY+KSCiso/7giINK37GyquGrJFAdm1qNvFAx+oxNEGZ3VvDaq RlNr3DgfszDLQ== From: ponymontana To: Bryan Bishop , Bitcoin Protocol Discussion In-Reply-To: References: Message-ID: Autocrypt: addr=ponymontana@disroot.org; prefer-encrypt=mutual; keydata= mQINBGEmnsoBEADHGXNSbk5UzJ2l5Nuoo3K1lhI86zJMvSm/oh9sGe0Qyki9f4uNJgsmVm6YI47O 4rXr9a8J/JIWKNt+CnmXVH8USfl87N4aU1SdbhO97ykGGGS7TkYScOQS8uK6CtXS75SaHevY2wUI TCz1J7kqZPYyPZTBOk+8araizCWgronlh+B617uRHMXtl/DRJFvQhqDyPbuo/VRjOWiKY7rGrph2 aUFpJUkAtLh3t3GhGG0EDyFTM/i5NsiWWKRIocg0Jcfof4MS15AMuH/aEpoEdlHyo4DPTI6WdKso +Gj6wDnuFqs3/l3XhIgbyKYJIdiFJk4hNJ+El3JzSODECcXCvOlqrru0P0+qENovxcExql9ILaxo X3UDqAEE2wc7J89676Svma/N/FHjw8YwVIajjyjNoWaFUhOnjxtorfaRq+KzTGnP3L1fYrt4WMwK nWzNDVzNrt+kUlpJxAQwaEhM0r9FK+GZVi7IFygbafW38xorwNhqqgmOPs3MdnY9rtmgCju6RiSS qudAnxTqzZ/1dEquUPaS7/i6ruF/55vIRP42I2S5RrbfYGcUJK3dlheSjYcYERd/V30vifGws+4C ToqqclEiMo27F51FT4wgzSePnMH5JTJ9lhyeqxzT9t+tpIFdR+4GZXy03wNJzcB60MftGBBUGDKe ET3ccP/h1TcVEQARAQABtCVwb255bW9udGFuYSA8cG9ueW1vbnRhbmFAZGlzcm9vdC5vcmc+iQJR BBMBCAA7AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAFiEEReAEp626xVCWRNXpJwyOCOq+J8cF AmH/AU4CGQEACgkQJwyOCOq+J8d7Zg//ePV8ERy1Hn2zvZqKHDX0TClzbB4fY1stbLkdw2DnmJLE xaNBxeuXR2ZCH8eKO801l4i0+p+he0l39X8inBqqSli0v5u7KGxjIYUAPMA4HIK/l5F5zbE75w/o cIfrQ6GM7P+gXyTJIkLQmXZR6Ol5vJ/J3YT5CFEkGUxDVgad12yym+Z2T6c6ePWozXSjJ4WEs67H ZmgdYTEFzD7ffMWkJDTohuWxG4/gYIpBFf7b9h2HuIYY1i8VQDgBXqR+XZMh/x1Jxvc0qLnqXEvo qG6PWjuu5uFO5tZkZSvbNCJOSrZ9PMUymvk04JPBAQjidhqX7j9CS2qt+YwmF3EHT20+uC7zoGYb 3UN3W/OS248uXadLEM8Ao4AOh/12lF67C+7RGsHbnaakhviriJ3owQ1jjcyuGHYToc06lSJn2fkH Batp/GuhAArN2sDPRrcZ9Ogd09OiVNcx7buwq5j/6vu40xAu3cuo5tWEUOvqlQnuRqCwqcsXwpbt JER4AUkvHtKnYnrADn3NtbqjQciAhAAbEs90EciC5tuVYYAjtrVJA0RdC5T3NILaeLNgq51Xn9kL JUplFHQ+FkyOIj8D7sjspJbw5sDm4mR1+KheNy1GaFnPTA5SlsJGKMKW1OnOAyHCLc+dLz6r3Nuf XdTrm4g3WqKy3XRVwdKx9VhifGuODcS5Ag0EYSaeygEQAM7cQtgP28BgzXV4639oAcjCV8yaLQ+9 q96CWG/frhXTSEgGETgqswwXkS45TRJs6rK7VX9dr/iFKGPOAvOWmroGsN+hCdYuLI/HY/jHhF2P ncYOzHrXANDkqyJ8T3O6V0ujDw3s/n88godpp51yI5AGA7H5/TJY8I+CyeObAfsRr6sI/TfmFaik S/+jVt8o/eXVwKbW6HTAbQDinSNTdkTH90plrQlW1O+SvqZuxL+1BD59tUQGzbMXvJgxZplpjpIK MHaXMVqsNn4neTkavTUnta3oKmY1MHO3INp6Y0csuJFT42kC1DsaO54WCZH84DyUiX+7yJvql7ZA b6AtEuTU6VffQH+5GrNWndYPSSPCR7CCAIIZHaXMLritpQ1W2SJ4dE4X5cH9bCMNPdn1KSfJPRaf jd/+O1d3kKaOpw6Mp8RUEOW88nzD+RsZVrDaeqXwQFZ+G7lWa/GlkuhZzyI1BhcWaXUnPGFuKJn1 s/A4PzXIL4xOk0E2WHwpcRGQ5llJiDIx16QtRxBq+bxsAZ+Z0EZ7g0UQfYQXEvoMDNp3+XW0I4D6 QQvHBQwg80SdUPlwEMwOoGBJA7yi3PbEgzbcTyYYcGEtyy23ggP7b/W9kZkekauqOe9GaKExSnsK K8w+rbW3gV2yqa59Go7K9Y5x+i7KPRPBW/rnzXwKezpTABEBAAGJAjYEGAEIACAWIQRF4ASnrbrF UJZE1eknDI4I6r4nxwUCYSaeygIbDAAKCRAnDI4I6r4nxwZYEACebZCTUtjTDtcCgyAIVeF3kzDf 8etWMSeKCa9jp8wlmq24S1kDRBdxbF58iMj0wpwWU2TWmhinL3iMaZHDepTgxizwXDZD1Pvg9qiL MT3uq18FszIr/wNNyTrigfrlcpn29M0eW+PNwFGIZhZ5YFoVgOv08dn43LXDgDv9gpv1hcbq4aMI Zq0E9V+TP3R3vbenGmt5xX56OAEPmU5s7YafJI74dj1FgYVonTDTg9Oa5i0vqQF3g6TA7kY2JCAc WEczdeKHE0oYVhF7pUQC5yinqO8ghCwTJYjka4lq/Xc4hsdsUA7dXGYx6mNw1CP2JPE8KLFVyNgP mBHFRm2sHEngdWwSBdqbRF0gb+65N8ZpEVQC7KThnwKTi4Aam3zmcyCFOPWPsoJh4yqCSvppv7f2 glaqYVZmE4d6aelcqZzvxtILj7HaEsfaQyGv/inbgOshII4ytDpYlECbqZKLugA9HfgRaVcEnn/Y lVglGcWnQlK50OE4jviQF9wsm5Der4LHW4L05IGm6+7UIw1Ednke6ooEzAdI6yrorjNCey697+78 6uMn1loqjj61twbUPIysDTJejFuxhZ95M9T/Ey2PVjetNMBru0RM3oACreb4ygS1Ux5iCzFMieT6 kM9ijIsGPzWQoDXHN9VmYiZFewxg8cOIFi764fEvlgdjjcOt+g== MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; boundary="----8UJQP0482RZDPA3TR4L5C2I3AN4Q9E"; protocol="application/pgp-signature"; micalg="pgp-sha512" X-Mailman-Approved-At: Tue, 07 Nov 2023 22:46:30 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2023 22:20:13 -0000 ------8UJQP0482RZDPA3TR4L5C2I3AN4Q9E Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=----BQDK1ASZAIRVOA5XYH4910P5V8G5X9 ------BQDK1ASZAIRVOA5XYH4910P5V8G5X9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,=20 This impellent deadline could be took with enthusiasm from people that are= anxious to experiment with new protocols and platforms that can replicate = mailing lists and offer, in theory, better solutions=2E I think this enthusiasm is totally positive and I encourage them to work o= n that ideas=2E But I also think that this mailing list fills a very particoular need of c= ommunication in the bitcoin space=2E=20 The stream of ideas hosted here is strictly dependant on the form it assum= es when formalized in the peculiar format of mails-threads=2E=20 Migrating these technical discussions to a forum or a pseudo-group-chat wo= uldn't replace this mailing list, even if the moderators behind and most of= the participants would be the same=2E It would eventually be a new and unstable solution, with no-guarantee to p= reserve the same goals reached here=2E Today exist a lot of places where people can exchange ideas about bitcoin; if new platforms will emerge as better suited to hosts BIP drafts and tech= nical discussions, people will move organically through them=2E In my opinion, "finding a new platform" is only marginally correlated to o= ur main topic here=2E If our problem is helping decide the "future of bitcoin-dev mailing list",= the only two solutions to me appear to tautologically be: 1) Give continuity to bitcoin-dev mailing list with a ready drop-in replac= ement=2E=20 2) Don't give continuity the bitcoin-dev mailing list=2E In the case 1) a solution could be find a new host for the mailing list an= d work around the problems exposed=2E In the case 2) is possible to do nothing OR to propose a new solution as a= sort of "spiritual continuation" of bitcoin-dev mailing list, and eventual= ly see if people will converge on it=2E Understanding all the difficulty behind the management of the bitcoin-dev = mailing list, I think it has worked very well for many years, and I hope it= will work for the years to come=2E I also want to say thanks to all the people behind this mailing list for a= ll your work and effort=2E ---PM Il 7 novembre 2023 16:37:22 CET, Bryan Bishop via bitcoin-dev ha scritto: >Hello, > >We would like to request community feedback and proposals on the future o= f >the mailing list=2E > >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=2E We temporar= ily >avoided that, but recently LF has informed a moderator that they will cea= se >hosting any mailing lists later this year=2E > >In this email, we will go over some of the history, options, and invite >discussion ahead of the cutoff=2E We have some ideas but want to solicit >feedback and proposals=2E > >Background >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >The bitcoin-dev mailing list was originally hosted on Sourceforge=2Enet= =2E The >bitcoin development mailing list has been a source of proposals, analysis= , >and developer discussion for many years in the bitcoin community, with ma= ny >thousands of participants=2E Later, the mailing list was migrated to the >Linux Foundation, and after that OSUOSL began to help=2E > >Linux Foundation first asked us to move the mailing list in 2017=2E They >internally attempted to migrate all LF mailing lists from mailman2 to >mailman3, but ultimately gave up=2E There were reports of scalability iss= ues >with mailman3 for large email communities=2E Ours definitely qualifies as= =2E=2E >large=2E > >2019 migration plan: LF was to turn off mailman and all lists would migra= te >to the paid service provider groups=2Eio=2E Back then we were given accou= nts to >try the groups=2Eio interface and administration features=2E Apparently w= e were >not the only dev community who resisted change=2E To our surprise LF gave= us >several years of reprieve by instead handing the subdomain and server-sid= e >data to the non-profit OSUOSL lab who instead operated mailman2 for the >past ~4 years=2E > >OSUOSL has for decades been well known for providing server infrastructur= e >for Linux and Open Source development so they were a good fit=2E This how= ever >became an added maintenance burden for the small non-profit with limited >resources=2E Several members of the Bitcoin dev community contributed fun= ding >to the lab in support of their Open Source development infrastructure >goals=2E But throwing money at the problem isn=E2=80=99t going to fix the= ongoing >maintenance burden created by antiquated limitations of mailman2=2E > >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=2E Fortunat= ely >for us while lists=2Elinuxfoundation=2Eorg mailman will go down, they hav= e >agreed the read-only pipermail archives will remain online=2E So all old = URLs >will continue to remain valid=2E 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=2E > >Public-Inbox >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >https://public-inbox=2Eorg/README=2Ehtml > >=E2=80=9CPublic Inbox=E2=80=9D decentralized archiving - no matter what m= ailing 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=2E > >Public Inbox is a tool that you can run yourself=2E You can transform you= r >mbox file and it makes it browsable and viewable online=2E It commits eve= ry >post to a git repository=2E It's kind of like a decentralized mail archiv= ing >tool=2E Anyone can publish the mail archive to any web server they wish= =2E > >We should try to have one or more canonical archives that are served usin= g >public-inbox=2E But it doesn't matter if these are lost because anyone el= se >can archive the mailing list in the same way and re-publish the archives= =2E > >These git commits can also be stamped using opentimestamps, inserting the= ir >hashes into the bitcoin blockchain=2E > >LKML mailing list readers often use public-inbox's web interface, and the= y >use the reply-to headers to populate their mail client and reply to threa= ds >of interest=2E This allows their reply to be properly threaded even if th= ey >were not a previous subscriber to that mailing list to receive the header= s=2E > >public-inbox makes it so that it doesn't really matter where the list is >hosted, as pertaining to reading the mailing list=2E There is still a >disruption if the mailing list goes away, but the archives live on and th= en >people can post elsewhere=2E The archive gets disconnected from the maili= ng >list host in terms of posting=2E We could have a few canonical URLs for t= he >hosts, separate from the mailing list server=2E > >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=2E There are presently a >handful of different moderators, but mailman2 only has a single password >for logging into the email management interface=2E There are no moderator >audit logs to see which user (there is no concept of different users) act= ed >on an email=2E There is no way to mark an email as being investigated by = one >or more of the moderators=2E Sometimes, while investigating the veracity = of >an email, another moderator would come in and approve a suspect email by >accident=2E > >Anti spam has been an issue for the moderators=2E It's relentless=2E With= out >access to the underlying server, it has been difficult to fight spam=2E T= here >is some support for filters in mailman2 but it's not great=2E > >100% active moderation and approval of every email is unsustainable for >volunteer moderators=2E A system that requires moderation is a heavy burd= en >on the moderators and it slows down overall communication and productivit= y=2E >There's lots of problems with this=2E Also, moderators can be blamed when >they are merely slow while they are not actually censoring=2E > >Rejection emails can optionally be sent to >bitcoin-dev-moderation@lists=2Eozlabs=2Eorg but this is an option that a >moderator has to remember to type in each time=2E > >Not to mention numerous bugs and vulnerabilities that have accumulated ov= er >the years for relatively unmaintained software=2E (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=2E First, it is >important that backups of the entire archive should be easy for the publi= c >to copy or verify so that the system can be brought up elsewhere if >necessary=2E > >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)=2E There seems to be very few options that cater to both >email and web=2E Often, in forum software, email support is limited to em= ail >notifications and there is limited if any support for email user >participation=2E > >Third, there should be better support for moderator tools and management = of >the mailing list=2E See above for complaints about problems with the mail= man2 >system=2E > >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=2E Anti-spam filtering is essential to prevent forwarding >spam=2E The moment you forward even a single spam message you run the ris= k of >the server IP address being added to blacklists=2E > >The problem of spam filtering is so bad that most IP addresses are presum= ed >guilty even if they have no prior spam history, such as if their network = or >subnetwork had spam issues in the past=2E > >Even if you put unlimited time into managing your own email server, other >people may not accept your email=2E Or you make one mistake, and then you= get >into permanent blacklists and it's hard to remove=2E The spam problem is = so >bad that most IPs are automatically on a guilty-until-proven-innocent >blacklist=2E > >Often there is nothing you can do to get server IP addresses removed from >spam blacklists or from "bad reputation" lists=2E > >Ironically, hashcash-style proof-of-work stamps to prevent spam are an >appealing solution but not widely used in this community=2E Or anywhere= =2E > >Infinite rejection or forwarding loops happen=2E They often need to be >detected through vigilance and require manual sysadmin intervention to >solve=2E > >Bitcoin's dev lists being hosted alongside other Open Source projects was >previously protective=2E If that mailing list server became blacklisted t= here >were a lot of other people who would notice and complain=2E If we run a >Bitcoin-specific mail server we are on our own=2E 100% of the administrat= ive >burden falls upon our own people=2E There is also nothing we can do if so= me >unknown admin decides they don't like us=2E > >Options >=3D=3D=3D=3D=3D=3D=3D > >Web forums are an interesting option, but often don't have good email use= r >integration=2E At most you can usually hope for email notifications and a= n >ability to reply by email=2E It changes the model of the community from p= ush >(email) to pull (logging into a forum to read)=2E RSS feeds can help a li= ttle >bit=2E > >Many other projects have moved from mailing lists to forums (eg >https://discuss=2Epython=2Eorg/ =E2=80=93 see https://lwn=2Enet/Articles/= 901744/ ; or >https://ethresear=2Ech/), which seem easier to maintain and moderate, and= can >have lots of advanced features beyond plaintext, maybe-threading and >maybe-HTML-markup=2E > >Who would host the forum? Would there be agreement around which forum >software to use or which forum host? What about bitcointalk=2Eorg or >delvingbitcoin=2Eorg? There are many options available=2E Maybe what we >actually want isn=E2=80=99t so much a discussion forum, as an 'arxiv of o= ur 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=2E This leaves us with Google Groups or groups=2Eio as two remaini= ng >options=2E > >groups=2Eio is an interesting option: they are a paid service that implem= ents >email communities along with online web forum support=2E However, their >public changelog indicates it has been a few years since their last publi= c >change=2E 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=2E=2E=2E > >Google Groups is another interesting option, and comes with different >tradeoffs=2E It's the lowest effort to maintain option, and has both an e= mail >interface and web forum interface=2E Users can choose which mode they wan= t to >interact with=2E > >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=2E it d= oes >not require any personal information to do so=2E This also allows you to = add >2FA=2E Non-gmail non-google users are able to subscribe and post email fr= om >their non-gmail non-google email accounts=2E Tor seems to work for the we= b >interface=2E > >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=2E > >The moderation capabilities for Google Groups and groups=2Eio seem to be >comparable=2E It seems more likely that Google Groups will be able to han= dle >email delivery issues far better than a small resource-constrained >operation like groups=2Eio=2E ((During feedback for this draft, luke-jr >indicates that Google Workspaces has been known to use blacklisted IPs fo= r >business email!)) > >On the other hand, groups=2Eio is a paid service and you get what you pay >for=2E=2E=2E hopefully? > >Finally, another option is to do literally nothing=2E It's less work over= all=2E >Users can switch to forums or other websites, or private one-on-one >communication=2E It would remove a point of semi-centralization from the >bitcoin ecosystem=2E It would hasten ossification, but on the other hand = it >would hasten ossification and this could be a negative too=2E Moderators >would be less of a target=2E > >Unfortunately, by doing nothing, there would be no more widely used group >email communication system between bitcoin developers=2E Developers becom= e >less coordinated, mayhem and chaos as people go to different communicatio= n >platforms, a divided community is more vulnerable, etc=2E BIP1 and BIP2 w= ould >need to be revised for other venues=2E > >The main categories of what to move to are: web forums, mailing lists, an= d >hybrids of those two options=2E Most everything is either self-hosted or = you >pay someone else to host it=2E It's kind of the same problem though=2E It >largely depends on how good is the software and unfortunately running you= r >own MTA that forwards mail is not a good option=2E > >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 wh= at >options are available=2E One potential option is a migration to Google >Groups, but we're open to ideas at this point=2E We apologize for any >inconvenience this disruption has caused=2E > > >Bitcoin-dev mailing list moderation team > >Bryan Bishop >Ruben Somsen >Warren Togami >various others=2E > >--=20 >- Bryan >https://twitter=2Ecom/kanzure ------BQDK1ASZAIRVOA5XYH4910P5V8G5X9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

This impellent deadl= ine could be took with enthusiasm from people that are anxious to experimen= t with new protocols and platforms that can replicate mailing lists and off= er, in theory, better solutions=2E
I think this enthusiasm is totally po= sitive and I encourage them to work on that ideas=2E

But I also thin= k that this mailing list fills a very particoular need of communication in = the bitcoin space=2E
The stream of ideas hosted here is strictly depend= ant on the form it assumes when formalized in the peculiar format of mails-= threads=2E
Migrating these technical discussions to a forum or a pseudo= -group-chat wouldn't replace this mailing list, even if the moderators behi= nd and most of the participants would be the same=2E
It would eventually= be a new and unstable solution, with no-guarantee to preserve the same goa= ls reached here=2E

Today exist a lot of places where people can exch= ange ideas about bitcoin;
if new platforms will emerge as better suited = to hosts BIP drafts and technical discussions, people will move organically= through them=2E
In my opinion, "finding a new platform" is only margina= lly correlated to our main topic here=2E


If our problem is helpi= ng decide the "future of bitcoin-dev mailing list", the only two solutions = to me appear to tautologically be:

1) Give continuity to bitcoin-dev= mailing list with a ready drop-in replacement=2E

2) Don't give con= tinuity the bitcoin-dev mailing list=2E


In the case 1) a solutio= n could be find a new host for the mailing list and work around the problem= s exposed=2E

In the case 2) is possible to do nothing OR to propose = a new solution as a sort of "spiritual continuation" of bitcoin-dev mailing= list, and eventually see if people will converge on it=2E


Under= standing all the difficulty behind the management of the bitcoin-dev mailin= g list, I think it has worked very well for many years, and I hope it will = work for the years to come=2E
I also want to say thanks to all the peopl= e behind this mailing list for all your work and effort=2E


---PM=


Il 7 novembre 20= 23 16:37:22 CET, Bryan Bishop via bitcoin-dev <bitcoin-dev@lists=2Elinux= foundation=2Eorg> ha scritto:
Hello,

We would like to request community fee= dback and proposals on the future of the mailing list=2E

Our c= urrent mailing list host, Linux Foundation, has indicated for years that th= ey have wanted to stop hosting mailing lists, which would mean the bitcoin-= dev mailing list would need to move somewhere else=2E We temporarily avoide= d that, but recently LF has informed a moderator that they will cease hosti= ng any mailing lists later this year=2E

In this email, we wil= l go over some of the history, options, and invite discussion ahead of the = cutoff=2E We have some ideas but want to solicit feedback and proposals=2E<= br>
Background
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The bitcoin-dev = mailing list was originally hosted on Sourceforge=2Enet=2E The bitcoin deve= lopment mailing list has been a source of proposals, analysis, and develope= r discussion for many years in the bitcoin community, with many thousands o= f participants=2E Later, the mailing list was migrated to the Linux Foundat= ion, and after that OSUOSL began to help=2E

Linux Foundation first a= sked us to move the mailing list in 2017=2E They internally attempted to mi= grate all LF mailing lists from mailman2 to mailman3, but ultimately gave u= p=2E There were reports of scalability issues with mailman3 for large email= communities=2E Ours definitely qualifies as=2E=2E large=2E

2019 mig= ration plan: LF was to turn off mailman and all lists would migrate to the = paid service provider groups=2Eio=2E Bac= k then we were given accounts to try the gro= ups=2Eio interface and administration features=2E Apparently we were no= t the only dev community who resisted change=2E 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 pas= t ~4 years=2E

OSUOSL has for decades been well known for providing s= erver infrastructure for Linux and Open Source development so they were a g= ood fit=2E This however became an added maintenance burden for the small no= n-profit with limited resources=2E Several members of the Bitcoin dev commu= nity contributed funding to the lab in support of their Open Source develop= ment infrastructure goals=2E But throwing money at the problem isn=E2=80=99= t going to fix the ongoing maintenance burden created by antiquated limitat= ions of mailman2=2E

Permalinks
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=
Linux Foundation has either offered or agreed to maintain archive perma= links so that content of historic importance is not lost=2E Fortunately for= us while lists=2Elinuxfou= ndation=2Eorg mailman will go down, they have agreed the read-only pipe= rmail archives will remain online=2E So all old URLs will continue to remai= n valid=2E However, the moderators strongly advise that the community suppl= ements with public-inbox instances to have canonical archive urls that are = separate from any particular email software host=2E

Public-Inbox
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

https://public-inbox=2Eorg/README=2Ehtml

= =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=2E

Pu= blic Inbox is a tool that you can run yourself=2E You can transform your mb= ox file and it makes it browsable and viewable online=2E It commits every p= ost to a git repository=2E It's kind of like a decentralized mail archiving= tool=2E Anyone can publish the mail archive to any web server they wish=2E=

We should try to have one or more canonical archives that are serve= d using public-inbox=2E But it doesn't matter if these are lost because any= one else can archive the mailing list in the same way and re-publish the ar= chives=2E

These git commits can also be stamped using opentimestamps= , inserting their hashes into the bitcoin blockchain=2E

LKML mailing= list readers often use public-inbox's web interface, and they use the repl= y-to headers to populate their mail client and reply to threads of interest= =2E This allows their reply to be properly threaded even if they were not a= previous subscriber to that mailing list to receive the headers=2E

= public-inbox makes it so that it doesn't really matter where the list is ho= sted, as pertaining to reading the mailing list=2E There is still a disrupt= ion if the mailing list goes away, but the archives live on and then people= can post elsewhere=2E The archive gets disconnected from the mailing list = host in terms of posting=2E We could have a few canonical URLs for the host= s, separate from the mailing list server=2E

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=2E There are presently a handful of different moderator= s, but mailman2 only has a single password for logging into the email manag= ement interface=2E There are no moderator audit logs to see which user (the= re is no concept of different users) acted on an email=2E There is no way t= o mark an email as being investigated by one or more of the moderators=2E S= ometimes, while investigating the veracity of an email, another moderator w= ould come in and approve a suspect email by accident=2E

Anti spam ha= s been an issue for the moderators=2E It's relentless=2E Without access to = the underlying server, it has been difficult to fight spam=2E There is some= support for filters in mailman2 but it's not great=2E

100% active m= oderation and approval of every email is unsustainable for volunteer modera= tors=2E A system that requires moderation is a heavy burden on the moderato= rs and it slows down overall communication and productivity=2E There's lots= of problems with this=2E Also, moderators can be blamed when they are mere= ly slow while they are not actually censoring=2E

Rejection emails ca= n optionally be sent to bitcoin-dev-moderation@lists=2Eozlabs=2Eorg but this is an = option that a moderator has to remember to type in each time=2E

Not = to mention numerous bugs and vulnerabilities that have accumulated over the= years for relatively unmaintained software=2E (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 towar= ds the future, there are a number of properties that seem to be important f= or the bitcoin-dev mailing list community=2E First, it is important that ba= ckups 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=2E

Seco= nd, there seems to be demand for both an email threading interface (using m= ailing list software) as well as web-accessible interfaces (such as forum s= oftware)=2E There seems to be very few options that cater to both email and= web=2E Often, in forum software, email support is limited to email notific= ations and there is limited if any support for email user participation=2E<= br>
Third, there should be better support for moderator tools and manage= ment of the mailing list=2E See above for complaints about problems with th= e mailman2 system=2E

Burdens of running your own mailing list and em= ail 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=2E Anti-spam filterin= g is essential to prevent forwarding spam=2E The moment you forward even a = single spam message you run the risk of the server IP address being added t= o blacklists=2E

The problem of spam filtering is so bad that most IP= addresses are presumed guilty even if they have no prior spam history, suc= h as if their network or subnetwork had spam issues in the past=2E

E= ven if you put unlimited time into managing your own email server, other pe= ople may not accept your email=2E Or you make one mistake, and then you get= into permanent blacklists and it's hard to remove=2E The spam problem is s= o bad that most IPs are automatically on a guilty-until-proven-innocent bla= cklist=2E

Often there is nothing you can do to get server IP address= es removed from spam blacklists or from "bad reputation" lists=2E

Ir= onically, hashcash-style proof-of-work stamps to prevent spam are an appeal= ing solution but not widely used in this community=2E Or anywhere=2E
Infinite rejection or forwarding loops happen=2E They often need to be det= ected through vigilance and require manual sysadmin intervention to solve= =2E

Bitcoin's dev lists being hosted alongside other Open Source pro= jects was previously protective=2E If that mailing list server became black= listed there were a lot of other people who would notice and complain=2E If= we run a Bitcoin-specific mail server we are on our own=2E 100% of the adm= inistrative burden falls upon our own people=2E There is also nothing we ca= n do if some unknown admin decides they don't like us=2E

Options
= =3D=3D=3D=3D=3D=3D=3D

Web forums are an interesting option, but ofte= n don't have good email user integration=2E At most you can usually hope fo= r email notifications and an ability to reply by email=2E It changes the mo= del of the community from push (email) to pull (logging into a forum to rea= d)=2E RSS feeds can help a little bit=2E

Many other projects have mo= ved from mailing lists to forums (eg https://discuss=2Epython=2Eorg/ =E2=80=93 see https://lwn=2Enet/Articles/901744/ ; or https://ethresear=2Ech/), which seem e= asier to maintain and moderate, and can have lots of advanced features beyo= nd plaintext, maybe-threading and maybe-HTML-markup=2E

Who would hos= t the forum? Would there be agreement around which forum software to use or= which forum host? What about bitcoint= alk=2Eorg or delvingbitcoin=2Eo= rg? There are many options available=2E 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 m= ailman3 would not be a viable long-term option=2E This leaves us with Googl= e Groups or groups=2Eio as two remaining= options=2E

groups=2Eio is an int= eresting option: they are a paid service that implements email communities = along with online web forum support=2E However, their public changelog indi= cates it has been a few years since their last public change=2E They might = be a smaller company and it is unclear how long they will be around or if t= his would be the right fit for hosting sometimes contentious bitcoin develo= pment discussions=2E=2E=2E

Google Groups is another interesting opti= on, and comes with different tradeoffs=2E It's the lowest effort to maintai= n option, and has both an email interface and web forum interface=2E Users = can choose which mode they want to interact with=2E

For the Google G= roups web interface, you can use it with a non-gmail account, but you must = create a Google Account which is free to do=2E it does not require any pers= onal information to do so=2E This also allows you to add 2FA=2E Non-gmail n= on-google users are able to subscribe and post email from their non-gmail n= on-google email accounts=2E Tor seems to work for the web interface=2E
=
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=2E
<= br>The moderation capabilities for Google Groups and groups=2Eio seem to be comparable=2E 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=2Eio=2E ((During feedback for this draft, luke-jr indicates tha= t Google Workspaces has been known to use blacklisted IPs for business emai= l!))

On the other hand, groups=2Eio is a paid service and you get what you pay for=2E=2E=2E hopefully?
Finally, another option is to do literally nothing=2E It's less work over= all=2E Users can switch to forums or other websites, or private one-on-one = communication=2E It would remove a point of semi-centralization from the bi= tcoin ecosystem=2E It would hasten ossification, but on the other hand it w= ould hasten ossification and this could be a negative too=2E Moderators wou= ld be less of a target=2E

Unfortunately, by doing nothing, there wou= ld be no more widely used group email communication system between bitcoin = developers=2E Developers become less coordinated, mayhem and chaos as peopl= e go to different communication platforms, a divided community is more vuln= erable, etc=2E BIP1 and BIP2 would need to be revised for other venues=2E
The main categories of what to move to are: web forums, mailing lists= , and hybrids of those two options=2E Most everything is either self-hosted= or you pay someone else to host it=2E It's kind of the same problem though= =2E It largely depends on how good is the software and unfortunately runnin= g your own MTA that forwards mail is not a good option=2E

Going forw= ard
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

We'd like to invite feedbac= k and proposals from the community, and see what options are available=2E O= ne potential option is a migration to Google Groups, but we're open to idea= s at this point=2E We apologize for any inconvenience this disruption has c= aused=2E


Bitcoin-dev mailing list moderation team

Bryan B= ishop
Ruben Somsen
Warren Togami
various others=2E

------BQDK1ASZAIRVOA5XYH4910P5V8G5X9-- ------8UJQP0482RZDPA3TR4L5C2I3AN4Q9E Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQJDBAABCgAtJhxwb255bW9udGFuYSA8cG9ueW1vbnRhbmFAZGlzcm9vdC5vcmc+ BQJlSrXfAAoJECcMjgjqvifHQvwP/jj75+sLw0YYCTzR8dCxvhd9IFqvNqJU1c0s 7xyc6N3VW6nHSKKAV9yhODf5pqbDjTk5xZiEbJOfRlBzpYz1xf/9nuETBS1fmUxp I/io0P7Ccub+d0TTb8lYKoX5E13rHSPG0AtAPGuFPUmRUTn2XcAMFewPmgXUv22R eI9BltbNyIsJfGy35tWyWn1Z06xa1GnxV+6bIoUNtPeynaRUottB12zNaWV4t31p /AyHqrX8CSAvlPykG7SUci3pUvSlSkIjW990Ay+FYfve4XpeKGzKJFZUIMHZV2MQ AAb2msum5OqH9FAYL6GdQ43Auns/F5ZzQnIGKYuw5EDhM+fF5MTTcW+FiO6hYriW 3hJEx7P+iAmDePyV7qqFSewRMP/s8xyrRS3Yz3zZYClF8uyxKX7pTgvk9cyCIPLE ChtfeOuiDUZWbJdSwR8ZVW6VvPinqY4Lk7XKLUCKtCQU4rUf5w0x3sf8nkgq4BXV 0D9oie1JDglOdU7D4ZZVbzsn0QeRnMiD0Ra0kXamEYfS1weHgQkvySaTarUbuTqi txsQBXfaV9VVaKOSuDjZu5xhubhYVYGao9n7s+Mu8mUKco28NWAPG5BXERsHPZpz cWg0S7rVaTQVu/JemI3XbC37w4+jj7aNFja9ty4+jmfzPeswFj+u5osLmQHKvJ2n n5sB29ny =Ns4E -----END PGP SIGNATURE----- ------8UJQP0482RZDPA3TR4L5C2I3AN4Q9E--