From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id A3C60C0032 for ; Mon, 13 Nov 2023 02:58:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 7B15E41730 for ; Mon, 13 Nov 2023 02:58:19 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 7B15E41730 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=c6Y0TSrr 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 smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Cy9vDNHySvI for ; Mon, 13 Nov 2023 02:58:17 +0000 (UTC) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) by smtp4.osuosl.org (Postfix) with ESMTPS id D28A541725 for ; Mon, 13 Nov 2023 02:58:16 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org D28A541725 Received: by mail-io1-xd31.google.com with SMTP id ca18e2360f4ac-7a69a1b51baso119278139f.1 for ; Sun, 12 Nov 2023 18:58:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699844296; x=1700449096; darn=lists.linuxfoundation.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=q/ADHXlmNmTP+BR6zIzGfKE0ogR29Z1WGwZ/1oWDXfA=; b=c6Y0TSrrYES1CQrLrfqcUDTCjqBwRaNHNfFV5TUQjHJG1fxLPkOHOgHnGMykrqlI0x NXOfthcqc2XWGwXz5hbC3e+svHMejjXHvFzfIrYqKPefiIqlukBBO/BbDE50TJMAS7h3 yYJKRlA3XP+jEI1GyWnrNwNJwDFlSE5FHSzum555ENEtzO9BH+Ech7YwXehg7GI2GWKl IeCSfHBcMpcZEVywUBXaJ/4krTSS2E2NY8zOQi1Wc78hs9xQdkFz+Cx8O+J8OZmFQ6Rg kHnjwBlOc2YSsLdAnHGHkgfsTncTRkN227HTGKj9fpp/UUQYvEoUXWamS+gXhmZzLAdS yamA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699844296; x=1700449096; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=q/ADHXlmNmTP+BR6zIzGfKE0ogR29Z1WGwZ/1oWDXfA=; b=g8p9HaATGVNii5F/oKNJxd+QFpYmMK+y988uMTIdWGSbFGGBE3uTzDUSbyTCp7C4Hb K7wXrv44n1H6dJCKQcNM/CflmUnSGdSysOyjLs6xb8G3NatbbdtOqr2Rra/V8IHCtlft 20z/dwv1cLTb/2pQZif3xCxVcwO0Ecw8j+YCLeVgD9iXaErLWX/JuAaO/Bj1OfrOMv4e 9P9Z9gjrknaxjX5tU8psGyZdDT/9Pg+nstRxRxxxGB2sAGpdhZewPBqeoug0TPKBFCts imr5gglYvzQDz+1U6kwdOo4kGuT9njb33+y9ck1j31W+SnBRsi1rIF6JE3uh/lKszJVN ApQQ== X-Gm-Message-State: AOJu0YzPUA2MeovuadV3XbWMg9rItKfiJPbDIF/XEBvvn5GK8kQaQaFn xHQPjVoHWRPwSz2T7LjwAhDQXqi4XHHZIqlt3zg= X-Google-Smtp-Source: AGHT+IEBOEXQXrBjkrBIcGHy+zALazsdIV/Q2G+dZMzJwZLZyC5mG4qm07tgz2cQ9UhgzeNhdENiZzb4iZf1BKyxIB4= X-Received: by 2002:a05:6e02:1107:b0:357:592a:8c4a with SMTP id u7-20020a056e02110700b00357592a8c4amr7582169ilk.12.1699844295628; Sun, 12 Nov 2023 18:58:15 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Mon, 13 Nov 2023 02:58:04 +0000 Message-ID: To: Bryan Bishop , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000006a1bcc0609ffd763" X-Mailman-Approved-At: Mon, 13 Nov 2023 10:22:54 +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: Mon, 13 Nov 2023 02:58:19 -0000 --0000000000006a1bcc0609ffd763 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the write up and thanks to the bitcoin-dev mailing list moderation team for their work along the years. If we can pick up a communication platform where platform moderators / infra maintainers have low-risk of being targeted by subpoena + gag order or "injonction administrative" (the equivalent in some civil law systems) due to lack of moderators discretionary decisions, I think this is a good outcome. I don't know of such a communication platform or set of protocols as of today. Nostr is promising though realistically weak until half a decade of work is poured in. Personally, I'll be more present on the Delving Bitcoin forum, though it sounds more a temporary solution than a long-term ideal. Being hosted by kernels or other old open-sources project mailing list infra sounds like a good idea. Best, Antoine Le mar. 7 nov. 2023 =C3=A0 15:37, Bryan Bishop via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : > Hello, > > We would like to request community feedback and proposals on the future o= f > 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 temporaril= y > avoided that, but recently LF has informed a moderator that they will cea= se > 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. Th= e > 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. 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 issue= s > 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 infrastructur= e > for Linux and Open Source development so they were a good fit. This howev= er > became an added maintenance burden for the small non-profit with limited > resources. Several members of the Bitcoin dev community contributed fundi= ng > 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 o= ngoing > 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. Fortunatel= y > for us while lists.linuxfoundation.org mailman will go down, they have > agreed the read-only pipermail archives will remain online. So all old UR= Ls > will continue to remain valid. However, the moderators strongly advise th= at > 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 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. > > 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 archivin= g > 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 usin= g > 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 the= y > use the reply-to headers to populate their mail client and reply to threa= ds > 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 header= s. > > 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 th= en > 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) act= ed > on an email. There is no way to mark an email as being investigated by on= e > 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. The= re > 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 productivit= y. > 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 publi= c > 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 emai= l > 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 g= et > 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 the= re > 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 administrativ= e > 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 use= r > 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 pus= h > (email) to pull (logging into a forum to read). RSS feeds can help a litt= le > 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 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. 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 sometim= es > 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 ema= il > 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 doe= s > not require any personal information to do so. This also allows you to ad= d > 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 handl= e > 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 fo= r > 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 othe= r > 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 communicatio= n > platforms, a divided community is more vulnerable, etc. BIP1 and BIP2 wou= ld > need to be revised for other venues. > > The main categories of what to move to are: web forums, mailing lists, an= d > hybrids of those two options. Most everything is either self-hosted or yo= u > 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 you= r > 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. > > -- > - Bryan > https://twitter.com/kanzure > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000006a1bcc0609ffd763 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the write up and thanks to the bitcoin-dev= mailing list moderation team for their work along=C2=A0the years.

If we can pick up=C2=A0a communication platform where plat= form moderators / infra maintainers have low-risk of being targeted by subp= oena=C2=A0+ gag order or "injonction administrative" (the equival= ent in some civil law systems) due to lack of moderators discretionary deci= sions, I think this is a good outcome.

I don't= know of such a communication platform or set of protocols as of today. Nos= tr is promising though realistically weak until half a decade of work is po= ured in.

Personally, I'll be more present on t= he Delving Bitcoin forum, though it sounds more a temporary solution than a= long-term ideal. Being hosted by kernels or other old open-sources project= mailing list infra sounds like a good idea.

Best,=
Antoine

Le=C2=A0mar. 7 nov. 2023 =C3=A0=C2=A015:37, Bryan B= ishop via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit=C2=A0:
Hello,

We would like to re= quest community=C2=A0feedback and proposals on the future of the mailing li= st.

Our current mailing list host, Linux Foundation, has indic= ated for years that they have wanted to stop hosting mailing lists, which w= ould mean the bitcoin-dev mailing list would need to move somewhere else. W= e temporarily avoided that, but recently LF has informed a moderator that t= hey will cease hosting any mailing lists later this year.

In = this email, we will go over some of the history, options, and invite discus= sion ahead of the cutoff. We have some ideas but want to solicit feedback a= nd proposals.

Background
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Th= e bitcoin-dev mailing list was originally hosted on Sourceforge.net. The bi= tcoin development mailing list has been a source of proposals, analysis, an= d developer discussion for many years in the bitcoin community, with many t= housands of participants. Later, the mailing list was migrated to the Linux= Foundation, and after that OSUOSL began to help.

Linux Foundation f= irst asked us to move the mailing list in 2017. They internally attempted t= o migrate all LF mailing lists from mailman2 to mailman3, but ultimately ga= ve up. There were reports of scalability issues with mailman3 for large ema= il communities. Ours definitely qualifies as.. large.

2019 migration= plan: LF was to turn off mailman and all lists would migrate to the paid s= ervice provider groups.io. Back then we were given accounts to try the groups.io interface and administration features. App= arently we were not the only dev community who resisted change. To our surp= rise 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 mail= man2 for the past ~4 years.

OSUOSL has for decades been well known f= or 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 Sour= ce development infrastructure goals. But throwing money at the problem isn= =E2=80=99t going to fix the ongoing maintenance burden created by antiquate= d limitations of mailman2.

Permalinks
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

Linux Foundation has either offered or agreed to maintain archiv= e permalinks so that content of historic importance is not lost. Fortunatel= y 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 cont= inue to remain valid. However, the moderators strongly advise that the comm= unity supplements with public-inbox instances to have canonical archive url= s 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/READM= E.html

=E2=80=9CPublic Inbox=E2=80=9D 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 th= e web.

Public Inbox is a tool that you can run yourself. You can tra= nsform your mbox file and it makes it browsable and viewable online. It com= mits 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-pu= blish the archives.

These git commits can also be stamped using open= timestamps, 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 th= e 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 t= hen people can post elsewhere. The archive gets disconnected from the maili= ng list host in terms of posting. We could have a few canonical URLs for th= e 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 h= ave identified a number of problems with mailman2 especially as it pertains= to content moderation. There are presently a handful of different moderato= rs, but mailman2 only has a single password for logging into the email mana= gement interface. There are no moderator audit logs to see which user (ther= e is no concept of different users) acted on an email. There is no way to m= ark an email as being investigated by one or more of the moderators. Someti= mes, 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 und= erlying server, it has been difficult to fight spam. There is some support = for filters in mailman2 but it's not great.

100% active moderati= on 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 pro= blems with this. Also, moderators can be blamed when they are merely slow w= hile they are not actually censoring.

Rejection emails can optionall= y be sent to bitcoin-dev-moderation@lists.ozlabs.org but this is an o= ption that a moderator has to remember to type in each time.

Not to = mention numerous bugs and vulnerabilities that have accumulated over the ye= ars for relatively unmaintained software. (Not disclosed here)

Requi= rements 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 lis= t 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 the= re is limited if any support for email user participation.

Third, th= ere should be better support for moderator tools and management of the mail= ing 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 numer= ous challenges to deliverability. Anti-spam filtering is essential to preve= nt forwarding spam. The moment you forward even a single spam message you r= un 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 gui= lty even if they have no prior spam history, such as if their network or su= bnetwork had spam issues in the past.

Even if you put unlimited time= into managing your own email server, other people may not accept your emai= l. 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 autom= atically 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-styl= e proof-of-work stamps to prevent spam are an appealing solution but not wi= dely used in this community. Or anywhere.

Infinite rejection or forw= arding loops happen. They often need to be detected through vigilance and r= equire manual sysadmin intervention to solve.

Bitcoin's dev list= s being hosted alongside other Open Source projects was previously protecti= ve. If that mailing list server became blacklisted there were a lot of othe= r people who would notice and complain. If we run a Bitcoin-specific mail s= erver we are on our own. 100% of the administrative burden falls upon our o= wn people. There is also nothing we can do if some unknown admin decides th= ey don't like us.

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

Web fo= rums are an interesting option, but often don't have good email user in= tegration. At most you can usually hope for email notifications and an abil= ity to reply by email. It changes the model of the community from push (ema= il) 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.pyt= hon.org/ =E2=80=93 see https://lwn.net/Articles/901744/ ; or https://ethresear.ch/), which seem ea= sier to maintain and moderate, and can have lots of advanced features beyon= d plaintext, maybe-threading and maybe-HTML-markup.

Who would host t= he forum? Would there be agreement around which forum software to use or wh= ich forum host? What about bitcointalk.org or delvingbitcoin.org? There are many options available. Maybe wh= at we actually want isn=E2=80=99t so much a discussion forum, as an 'ar= xiv of our own' where anons can post BIP drafts and the like?

Gi= ven the problems with mailman2, and the decline of email communities in gen= eral, it seems that moving to mailman3 would not be a viable long-term opti= on. This leaves us with Google Groups or groups.io as two remaining options.

groups.io is an interesting option: the= y are a paid service that implements email communities along with online we= b forum support. However, their public changelog indicates it has been a fe= w 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 f= it for hosting sometimes contentious bitcoin development discussions...
=
Google Groups is another interesting option, and comes with different t= radeoffs. It's the lowest effort to maintain option, and has both an em= ail interface and web forum interface. Users can choose which mode they wan= t 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 al= so 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 cu= t us off, will they shut down non-google users? The same problem exists wit= h other third-party hosts.

The moderation capabilities for Google Gr= oups and groups.io seem = to be comparable. It seems more likely that Google Groups will be able to h= andle email delivery issues far better than a small resource-constrained op= eration 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 o= ther hand, groups.io is = a paid service and you get what you pay for... hopefully?

Finally, a= nother option is to do literally nothing. It's less work overall. Users= can switch to forums or other websites, or private one-on-one communicatio= n. It would remove a point of semi-centralization from the bitcoin ecosyste= m. It would hasten ossification, but on the other hand it would hasten ossi= fication and this could be a negative too. Moderators would be less of a ta= rget.

Unfortunately, by doing nothing, there would be no more widely= used group email communication system between bitcoin developers. Develope= rs become less coordinated, mayhem and chaos as people go to different comm= unication 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 ho= w 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 m= igration to Google Groups, but we're open to ideas at this point. We ap= ologize for any inconvenience this disruption has caused.


Bitcoi= n-dev mailing list moderation team

Bryan Bishop
Ruben Somsen
W= arren Togami
various others.

--
- Bryan
https://twitter.com/kanzure
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000006a1bcc0609ffd763--