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