MIME-Version: 1.0
References: <CABaSBaz9OTSVa1KNk0GOrH3T-kRF_7OPVu0AtpuaFGVB=zhdwQ@mail.gmail.com>
In-Reply-To: <CABaSBaz9OTSVa1KNk0GOrH3T-kRF_7OPVu0AtpuaFGVB=zhdwQ@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Mon, 13 Nov 2023 02:58:04 +0000
Message-ID: <CALZpt+F6Hovy2XKNuMgb5KJvEKCeQRkvWXDGTaAvfYsoQr+BbQ@mail.gmail.com>
To: Bryan Bishop <kanzure@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000006a1bcc0609ffd763"
Subject: Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
Precedence: list

--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

<div dir=3D"ltr"><div>Thanks for the write up and thanks to the bitcoin-dev=
 mailing list moderation team for their work along=C2=A0the years.</div><di=
v><br></div><div>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 &quot;injonction administrative&quot; (the equival=
ent in some civil law systems) due to lack of moderators discretionary deci=
sions, I think this is a good outcome.</div><div><br></div><div>I don&#39;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.</div><div><br></div><div>Personally, I&#39;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.</div><div><br></div><div>Best,=
</div><div>Antoine</div></div><br><div class=3D"gmail_quote"><div dir=3D"lt=
r" class=3D"gmail_attr">Le=C2=A0mar. 7 nov. 2023 =C3=A0=C2=A015:37, Bryan B=
ishop via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr">Hello,<br><br>We would like to re=
quest community=C2=A0feedback and proposals on the future of the mailing li=
st.<div><br><div>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.</div><div><br>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.<br><br>Background<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br><br>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.<br><br>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.<br><br>2019 migration=
 plan: LF was to turn off mailman and all lists would migrate to the paid s=
ervice provider <a href=3D"http://groups.io" target=3D"_blank">groups.io</a=
>. Back then we were given accounts to try the <a href=3D"http://groups.io"=
 target=3D"_blank">groups.io</a> 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.<br><br>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.<br><br>Permalinks<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<br><br>Linux Foundation has either offered or agreed to maintain archiv=
e permalinks so that content of historic importance is not lost. Fortunatel=
y for us while <a href=3D"http://lists.linuxfoundation.org" target=3D"_blan=
k">lists.linuxfoundation.org</a> 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.<br><br>Public-=
Inbox<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br><br><a href=3D"https://pub=
lic-inbox.org/README.html" target=3D"_blank">https://public-inbox.org/READM=
E.html</a><br><br>=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.<br><br>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&#39;s kind of like a decentralized =
mail archiving tool. Anyone can publish the mail archive to any web server =
they wish.<br><br>We should try to have one or more canonical archives that=
 are served using public-inbox. But it doesn&#39;t matter if these are lost=
 because anyone else can archive the mailing list in the same way and re-pu=
blish the archives.<br><br>These git commits can also be stamped using open=
timestamps, inserting their hashes into the bitcoin blockchain.<br><br>LKML=
 mailing list readers often use public-inbox&#39;s web interface, and they =
use the reply-to 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.=
<br><br>public-inbox makes it so that it doesn&#39;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.<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 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.<br><br>Anti spam has been =
an issue for the moderators. It&#39;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&#39;s not great.<br><br>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&#39;s lots of pro=
blems with this. Also, moderators can be blamed when they are merely slow w=
hile they are not actually censoring.<br><br>Rejection emails can optionall=
y be sent to <a href=3D"mailto:bitcoin-dev-moderation@lists.ozlabs.org" tar=
get=3D"_blank">bitcoin-dev-moderation@lists.ozlabs.org</a> but this is an o=
ption that a moderator has to remember to type in each time.<br><br>Not to =
mention numerous bugs and vulnerabilities that have accumulated over the ye=
ars for relatively unmaintained software. (Not disclosed here)<br><br>Requi=
rements 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 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.<br><br>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.<br><br>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.=
<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 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.<br><br>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.<br><br>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&#39;s hard to remove. The spam problem is so bad that most IPs are autom=
atically on a guilty-until-proven-innocent blacklist.<br><br>Often there is=
 nothing you can do to get server IP addresses removed from spam blacklists=
 or from &quot;bad reputation&quot; lists.<br><br>Ironically, hashcash-styl=
e proof-of-work stamps to prevent spam are an appealing solution but not wi=
dely used in this community. Or anywhere.<br><br>Infinite rejection or forw=
arding loops happen. They often need to be detected through vigilance and r=
equire manual sysadmin intervention to solve.<br><br>Bitcoin&#39;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&#39;t like us.<br><br>Options<br>=3D=3D=3D=3D=3D=3D=3D<br><br>Web fo=
rums are an interesting option, but often don&#39;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=
.<br><br>Many other projects have moved from mailing lists to forums (eg <a=
 href=3D"https://discuss.python.org/" target=3D"_blank">https://discuss.pyt=
hon.org/</a> =E2=80=93 see <a href=3D"https://lwn.net/Articles/901744/" tar=
get=3D"_blank">https://lwn.net/Articles/901744/</a> ; or <a href=3D"https:/=
/ethresear.ch/" target=3D"_blank">https://ethresear.ch/</a>), which seem ea=
sier to maintain and moderate, and can have lots of advanced features beyon=
d plaintext, maybe-threading and maybe-HTML-markup.<br><br>Who would host t=
he forum? Would there be agreement around which forum software to use or wh=
ich forum host? What about <a href=3D"http://bitcointalk.org" target=3D"_bl=
ank">bitcointalk.org</a> or <a href=3D"http://delvingbitcoin.org" target=3D=
"_blank">delvingbitcoin.org</a>? There are many options available. Maybe wh=
at we actually want isn=E2=80=99t so much a discussion forum, as an &#39;ar=
xiv of our own&#39; where anons can post BIP drafts and the like?<br><br>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 <a href=3D"http://groups.io" targe=
t=3D"_blank">groups.io</a> as two remaining options.<br><br><a href=3D"http=
://groups.io" target=3D"_blank">groups.io</a> 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...<br>=
<br>Google Groups is another interesting option, and comes with different t=
radeoffs. It&#39;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.<br><br>For the Google Groups web interface, you can use=
 it with a non-gmail account, but you must create a Google Account which is=
 free to 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. <br><br>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.<br><br>The moderation capabilities for Google Gr=
oups and <a href=3D"http://groups.io" target=3D"_blank">groups.io</a> 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 <a href=3D"http://groups.io" target=3D"_blank">groups.io</a>. =
((During feedback for this draft, luke-jr indicates that Google Workspaces =
has been known to use blacklisted IPs for business email!))<br><br>On the o=
ther hand, <a href=3D"http://groups.io" target=3D"_blank">groups.io</a> is =
a paid service and you get what you pay for... hopefully?<br><br>Finally, a=
nother option is to do literally nothing. It&#39;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.<br><br>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.<br><br>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&#39;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.<br><br>Going forward<br>=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D<br><br>We&#39;d like to invite feedback and proposals from the=
 community, and see what options are available. One potential option is a m=
igration to Google Groups, but we&#39;re open to ideas at this point. We ap=
ologize for any inconvenience this disruption has caused.<br><br><br>Bitcoi=
n-dev mailing list moderation team<br><br>Bryan Bishop<br>Ruben Somsen<br>W=
arren Togami<br>various others.<br><div><br></div><span class=3D"gmail_sign=
ature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><div=
 dir=3D"ltr">- Bryan<br><a href=3D"https://twitter.com/kanzure" target=3D"_=
blank">https://twitter.com/kanzure</a></div></div></div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000006a1bcc0609ffd763--