* Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
2023-11-07 15:37 Bryan Bishop
@ 2023-11-07 16:12 ` Andrew Chow
2023-11-08 9:05 ` email
2023-11-07 17:03 ` Ademan
` (8 subsequent siblings)
9 siblings, 1 reply; 26+ messages in thread
From: Andrew Chow @ 2023-11-07 16:12 UTC (permalink / raw)
To: bitcoin-dev
Thanks for writing this up.
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.
Although there are concerns that Google would shut down Google Groups or
specifically target a bitcoin-dev group, I think both are unlikely to
happen. Both Chromium and Android use Google Groups for their mailing
lists, so unless those go somewhere else, I doubt Google would
unceremoniously kill Google Groups. As for shutting down a bitcoin-dev
group specifically, given that there appears to be several thousand
groups whose sole purpose is to distribute spam, I don't think Google is
in the habit of shutting down groups.
Regardless of what we do, there's always the risk that someone will shut
down or stop maintaining the servers for any discussion medium. Even
self hosting requires someone to keep the servers up and do maintenance,
and that person (or people) could get bored of it, run out of money, get
hit by a bus, etc. We're experiencing that right now with the Linux
Foundation, and I don't think fear of that should prevent us from moving
to a different third party host.
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>
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
2023-11-07 16:12 ` Andrew Chow
@ 2023-11-08 9:05 ` email
0 siblings, 0 replies; 26+ messages in thread
From: email @ 2023-11-08 9:05 UTC (permalink / raw)
To: Andrew Chow, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 15212 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 18888 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
2023-11-07 15:37 Bryan Bishop
2023-11-07 16:12 ` Andrew Chow
@ 2023-11-07 17:03 ` Ademan
2023-11-07 18:14 ` Andrew Chow
2023-11-07 23:07 ` Peter Todd
2023-11-07 17:48 ` Andreas Schildbach
` (7 subsequent siblings)
9 siblings, 2 replies; 26+ messages in thread
From: Ademan @ 2023-11-07 17:03 UTC (permalink / raw)
To: Bryan Bishop, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 16352 bytes --]
Hi Bryan,
I don't really want my first (and last?) devlist message to be a fairly
off-the-cuff post on this topic, but here we go anyway.
At the risk of sounding like a nostr evangelist (I promise I'm not), I want
to suggest nostr as a potential replacement to the mailing list. A decent
chunk of software would need to be written, but none of the alternatives
seem particularly attractive to me. I particularly dislike the idea of
locking into a single siloed forum service like the bitcointalk forums. I
realize I may be in the minority of course.
Nostr enables the ML team to outsource all of its biggest burdens, if it
chooses:
- mail server blocking is N/A to nostr
- Hosting costs are completely outsourced unless the ML team chooses to
host a relay.
- Archives and web portal access can be similarly outsourced because any
nostr archive is self-authenticating.
- The ML team can also choose to completely outsource moderation, as nostr
is (more or less) permissionless by nature.
I understand if there is a "blessed" communication system, the ML team
would probably prefer to keep it high quality. To that end there are
proposals for proof-of-work, and web of trust based blocklists for nostr
which are optional for end users. There are other options such as the
"moderated communities" proposal which would provide tighter control.
On the user side, the optional moderation is very attractive, allowing
controversial threads to exist and continue, without requiring everyone to
see them.
The following do not currently exist (to my knowledge) and would need to be
implemented to meet the ML's requirements:
- an email gateway to satisfy the bulk of existing ML subscribers
This reintroduces issues with mail server blocking of course.
- a long-form oriented nostr client (current plain text clients could be
used in the meantime)
That admittedly is quite a lot of work, but the second item can be
deferred, and the first is not particularly technically challenging, the
complications are all on the administration side.
I expect some reflexive NACKs based on the immaturity of the ecosystem but
if we have months to prepare, I believe the core requirements can be
solidly satisfied in time, the rest can be developed over time, and I
believe the advantages are worth careful consideration.
Cheers,
Dan
On Tue, Nov 7, 2023 at 9:38 AM Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> 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. Back then we were given
> accounts to try the groups.io interface and administration features.
> Apparently we were not the only dev community who resisted change. To our
> surprise LF gave us several years of reprieve by instead handing the
> subdomain and server-side data to the non-profit OSUOSL lab who instead
> operated mailman2 for the past ~4 years.
>
> OSUOSL has for decades been well known for providing server infrastructure
> for Linux and Open Source development so they were a good fit. This however
> became an added maintenance burden for the small non-profit with limited
> resources. Several members of the Bitcoin dev community contributed funding
> to the lab in support of their Open Source development infrastructure
> goals. But throwing money at the problem isn’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 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
>
> “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 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/ – 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’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 as two remaining
> options.
>
> groups.io is an interesting option: they are a paid service that
> implements email communities along with online web forum support. However,
> their public changelog indicates it has been a few years since their last
> public change. They might be a smaller company and it is unclear how long
> they will be around or if this would be the right fit for hosting sometimes
> contentious bitcoin development discussions...
>
> Google Groups is another interesting option, and comes with different
> tradeoffs. It's the lowest effort to maintain option, and has both an email
> interface and web forum interface. Users can choose which mode they want to
> interact with.
>
> For the Google Groups web interface, you can use it with a non-gmail
> account, but you must create a Google Account which is free to do. it does
> not require any personal information to do so. This also allows you to add
> 2FA. Non-gmail non-google users are able to subscribe and post email from
> their non-gmail non-google email accounts. Tor seems to work for the web
> interface.
>
> Will Google shut it down, will they cut us off, will they shut down
> non-google users? The same problem exists with other third-party hosts.
>
> The moderation capabilities for Google Groups and groups.io seem to be
> comparable. It seems more likely that Google Groups will be able to handle
> email delivery issues far better than a small resource-constrained
> operation like groups.io. ((During feedback for this draft, luke-jr
> indicates that Google Workspaces has been known to use blacklisted IPs for
> business email!))
>
> On the other hand, groups.io is a paid service and you get what you pay
> for... hopefully?
>
> Finally, another option is to do literally nothing. It's less work
> overall. Users can switch to forums or other websites, or private
> one-on-one communication. It would remove a point of semi-centralization
> from the bitcoin ecosystem. It would hasten ossification, but on the other
> hand it would hasten ossification and this could be a negative too.
> Moderators would be less of a target.
>
> Unfortunately, by doing nothing, there would be no more widely used group
> email communication system between bitcoin developers. Developers become
> less coordinated, mayhem and chaos as people go to different communication
> platforms, a divided community is more vulnerable, etc. BIP1 and BIP2 would
> need to be revised for other venues.
>
> The main categories of what to move to are: web forums, mailing lists, and
> hybrids of those two options. Most everything is either self-hosted or you
> pay someone else to host it. It's kind of the same problem though. It
> largely depends on how good is the software and unfortunately running your
> own MTA that forwards mail is not a good option.
>
> Going forward
> ===========
>
> 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
>
[-- Attachment #2: Type: text/html, Size: 17895 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
2023-11-07 17:03 ` Ademan
@ 2023-11-07 18:14 ` Andrew Chow
2023-11-07 19:41 ` Christopher Allen
` (2 more replies)
2023-11-07 23:07 ` Peter Todd
1 sibling, 3 replies; 26+ messages in thread
From: Andrew Chow @ 2023-11-07 18:14 UTC (permalink / raw)
To: bitcoin-dev
Hi Dan,
I don't think nostr would be a suitable replacement for the mailing
list, although this opinion is biased by the fact that I do not use
nostr and find it to be uninteresting.
From my limited understanding of how nostr works, it's not clear to me
how a distributed system that uses message broadcast would work in the
same way as a mailing list. How would people "subscribe"? How would
archives be searched or otherwise be available to people who are not on
nostr? How do you distinguish and filter between legitimate dev posts
intended for discussion and random crap and shitposting as shows up on
social media?
I also don't think that long form text on nostr (or any similar
platform) can sufficiently replace email. None of these things seem to
contain a way to have a separate subject line as email does. Subjects
are immensely important for me as it provides a quick and easy way to
filter out things I don't care about reading. I don't want to have read
something in before I can decide that I don't care about reading it.
In general, I strongly prefer email, or a platform that has email as a
first class user interface, over platforms such as nostr, matrix, or web
forums. Email is universal - everyone has one and everyone knows how it
works. It dramatically lowers the barrier of entry. Having to make an
account somewhere or download some specific client in order to
participate will simply result in only the most dedicated participating.
Development in open source must be an open process and the barriers to
entry should be low.
Lastly, IIRC the plan is to shut down the list by the end of this year.
Any solution that requires custom software and bridges to be created are
not going to be viable in this time frame.
Andrew
On 11/07/2023 12:03 PM, Ademan via bitcoin-dev wrote:
> Hi Bryan,
>
> I don't really want my first (and last?) devlist message to be a fairly
> off-the-cuff post on this topic, but here we go anyway.
>
> At the risk of sounding like a nostr evangelist (I promise I'm not), I
> want to suggest nostr as a potential replacement to the mailing list. A
> decent chunk of software would need to be written, but none of the
> alternatives seem particularly attractive to me. I particularly dislike
> the idea of locking into a single siloed forum service like the
> bitcointalk forums. I realize I may be in the minority of course.
>
>
> Nostr enables the ML team to outsource all of its biggest burdens, if it
> chooses:
>
> - mail server blocking is N/A to nostr
>
> - Hosting costs are completely outsourced unless the ML team chooses to
> host a relay.
>
> - Archives and web portal access can be similarly outsourced because any
> nostr archive is self-authenticating.
>
> - The ML team can also choose to completely outsource moderation, as
> nostr is (more or less) permissionless by nature.
> I understand if there is a "blessed" communication system, the ML
> team would probably prefer to keep it high quality. To that end there
> are proposals for proof-of-work, and web of trust based blocklists for
> nostr which are optional for end users. There are other options such as
> the "moderated communities" proposal which would provide tighter control.
>
>
> On the user side, the optional moderation is very attractive, allowing
> controversial threads to exist and continue, without requiring everyone
> to see them.
>
>
> The following do not currently exist (to my knowledge) and would need to
> be implemented to meet the ML's requirements:
>
> - an email gateway to satisfy the bulk of existing ML subscribers
> This reintroduces issues with mail server blocking of course.
> - a long-form oriented nostr client (current plain text clients could be
> used in the meantime)
>
> That admittedly is quite a lot of work, but the second item can be
> deferred, and the first is not particularly technically challenging, the
> complications are all on the administration side.
>
> I expect some reflexive NACKs based on the immaturity of the ecosystem
> but if we have months to prepare, I believe the core requirements can be
> solidly satisfied in time, the rest can be developed over time, and I
> believe the advantages are worth careful consideration.
>
> Cheers,
> Dan
>
> On Tue, Nov 7, 2023 at 9:38 AM Bryan Bishop via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org
> <mailto:bitcoin-dev@lists•linuxfoundation.org>> 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
> <mailto:bitcoin-dev@lists•linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
2023-11-07 18:14 ` Andrew Chow
@ 2023-11-07 19:41 ` Christopher Allen
2023-11-07 22:24 ` Ryan Breen
2023-11-07 22:59 ` Peter Todd
2023-11-07 20:15 ` Ademan
2023-11-09 4:03 ` William Casarin
2 siblings, 2 replies; 26+ messages in thread
From: Christopher Allen @ 2023-11-07 19:41 UTC (permalink / raw)
To: Andrew Chow, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 669 bytes --]
As Bitcoin-Core already uses GitHub, another possibility is to use the new
GitHub discussions feature. We increasingly have been using this at
Blockchain Commons as everyone is using already using GitHub. We have also
created some GitHub actions to backup discussions so that GitHub will not
be a central point of failure -should be possible to create a static page
archive using GitHub pages (but have not had budget for that).
For instance, here is the GitHub discussion area for wallet developers
working together on Bitcoin wallet interoperability specifications:
https://github.com/BlockchainCommons/Gordian-Developer-Community
— Christopher Allen
[-- Attachment #2: Type: text/html, Size: 863 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
2023-11-07 19:41 ` Christopher Allen
@ 2023-11-07 22:24 ` Ryan Breen
2023-11-07 22:59 ` Peter Todd
1 sibling, 0 replies; 26+ messages in thread
From: Ryan Breen @ 2023-11-07 22:24 UTC (permalink / raw)
To: Christopher Allen, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1735 bytes --]
I think GitHub Discussions is a great idea. If we are considering proprietary options like Google Groups, then we should definitely consider Discussions.
1. Guaranteed that nearly everyone participating here already has a GH account.
2. Offers many moderation options.
3. Good formatting abilities(tables!).
4. Can @ people.
5. Ability to categorize, close, lock discussions, etc.
6. Many great potential opportunities for automation via Actions.
7. Comes with added benefits such as a wiki, issues, etc.
My one catch is that I do not know what kind of interactions you can have with Discussions via email. This seems to be an important feature for many. What level of email notifications can you receive? Can you respond via email?
> On Nov 7, 2023, at 3:16 PM, Christopher Allen via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>
> As Bitcoin-Core already uses GitHub, another possibility is to use the new GitHub discussions feature. We increasingly have been using this at Blockchain Commons as everyone is using already using GitHub. We have also created some GitHub actions to backup discussions so that GitHub will not be a central point of failure -should be possible to create a static page archive using GitHub pages (but have not had budget for that).
>
> For instance, here is the GitHub discussion area for wallet developers working together on Bitcoin wallet interoperability specifications:
> https://github.com/BlockchainCommons/Gordian-Developer-Community
>
> — Christopher Allen
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 2453 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
2023-11-07 19:41 ` Christopher Allen
2023-11-07 22:24 ` Ryan Breen
@ 2023-11-07 22:59 ` Peter Todd
1 sibling, 0 replies; 26+ messages in thread
From: Peter Todd @ 2023-11-07 22:59 UTC (permalink / raw)
To: Christopher Allen, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]
On Tue, Nov 07, 2023 at 11:41:59AM -0800, Christopher Allen via bitcoin-dev wrote:
> As Bitcoin-Core already uses GitHub, another possibility is to use the new
> GitHub discussions feature. We increasingly have been using this at
> Blockchain Commons as everyone is using already using GitHub. We have also
> created some GitHub actions to backup discussions so that GitHub will not
> be a central point of failure -should be possible to create a static page
> archive using GitHub pages (but have not had budget for that).
>
> For instance, here is the GitHub discussion area for wallet developers
> working together on Bitcoin wallet interoperability specifications:
> https://github.com/BlockchainCommons/Gordian-Developer-Community
Strong NACK.
bitcoin-dev should be independent of Bitcoin Core.
Also, a very useful thing that a mailing list does that GitHub does not is
cryptographic signatures, both obvious like PGP, and less obvious like DKIM. We
should not be moving even more discussion to mediums where authors aren't
properly signing their messages.
The user experience of GitHub and similar web forums is poor too. It's much
nicer to be able to reply to messages offline, asyncronously, regardless of
whether or not you happen to have a good internet connection at the time.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
2023-11-07 18:14 ` Andrew Chow
2023-11-07 19:41 ` Christopher Allen
@ 2023-11-07 20:15 ` Ademan
2023-11-09 4:03 ` William Casarin
2 siblings, 0 replies; 26+ messages in thread
From: Ademan @ 2023-11-07 20:15 UTC (permalink / raw)
To: Andrew Chow, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 24171 bytes --]
Hi Andrew,
Thanks for the thoughtful response. I don't know that you'll find my
responses satisfactory (particularly around moderation), but there are at
least solutions to the objections. Except of course the timeline, which I
got wrong ;-) and means this would be half-baked at best by the time it's
needed.
On Tue, Nov 7, 2023 at 1:06 PM Andrew Chow via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Hi Dan,
>
> I don't think nostr would be a suitable replacement for the mailing
> list, although this opinion is biased by the fact that I do not use
> nostr and find it to be uninteresting.
>
I felt that way for a long time. I still have a number of reservations
about it technically, but I'm increasingly impressed, though not for
reasons relevant to the discussion.
> From my limited understanding of how nostr works, it's not clear to me
> how a distributed system that uses message broadcast would work in the
> same way as a mailing list. How would people "subscribe"?
This is already accomplished by existing apps in various ways. There are
multiple options, from using labels, or topic tags (
https://github.com/nostr-protocol/nips/tree/master#standardized-tags ) (my
preference) or the moderated community approach (see below on moderation)
> How would
> archives be searched or otherwise be available to people who are not on
> nostr?
Dumb web portals with a familiar interface, existing nostr apps are
available as web clients in the interim.
> How do you distinguish and filter between legitimate dev posts
> intended for discussion and random crap and shitposting as shows up on
> social media?
>
I lean strongly towards the topic tag or label approach to constructing the
list, which means anyone can post "to the list". Moderation would be
applied client side like all nostr clients already do. This is where PoW (
https://github.com/nostr-protocol/nips/blob/master/13.md ) , and/or
web-of-trust and labeling (
https://github.com/nostr-protocol/nips/blob/master/32.md ) come in.
Moderation comes "for free" in the moderated communities model (
https://github.com/nostr-protocol/nips/blob/master/72.md ) Note that this
approach creates exactly the same moderation burden as the list team
already shoulders, and is overall less desirable imho, but it provides the
same level of control the current list does.
> I also don't think that long form text on nostr (or any similar
> platform) can sufficiently replace email. None of these things seem to
> contain a way to have a separate subject line as email does.
"Subject tag" ( https://github.com/nostr-protocol/nips/blob/master/14.md )
> Subjects
> are immensely important for me as it provides a quick and easy way to
> filter out things I don't care about reading. I don't want to have read
> something in before I can decide that I don't care about reading it.
>
> In general, I strongly prefer email, or a platform that has email as a
> first class user interface, over platforms such as nostr, matrix, or web
> forums. Email is universal - everyone has one and everyone knows how it
> works. It dramatically lowers the barrier of entry.
I think you'd be surprised just how low the barrier to entry in nostr is.
You can navigate to the website of any number of nostr apps and click
"generate key", but your point about the universality of email is well
taken. I think an email bridge would be an essential part of this system.
An email bridge would only be less than first-class because email is not as
rich as nostr* , from the email-user's perspective it could be no worse
than using an existing list server. FWIW I also strongly prefer email over
any web forum.
* Unless you want to go wild with non-standard headers
> Having to make an
> account somewhere or download some specific client in order to
> participate will simply result in only the most dedicated participating.
>
I actually think the barrier to entry is exceedingly low, which is part of
why we have concern about the spam problem.
> Development in open source must be an open process and the barriers to
> entry should be low.
>
> Lastly, IIRC the plan is to shut down the list by the end of this year.
> Any solution that requires custom software and bridges to be created are
> not going to be viable in this time frame.
>
I have to admit I misread the OP as shutdown at the end of 2024, not 2023,
but you're right, barely 2 months is a very tight schedule. Truly
addressing the needs of the list in that time frame is unlikely to be
possible. FWIW a workable "close enough" is basically possible today, but
that is probably unsatisfying.
Certainly if I take the lead, 2024-01-01 is an impossible timeline
(especially given my other obligations), but if there is even moderate
interest (part of why I bothered to share my ramblings), I could start
working on an MVP of the bridge, and a web client for evaluation down the
road.
Cheers,
Dan
>
> Andrew
>
> On 11/07/2023 12:03 PM, Ademan via bitcoin-dev wrote:
> > Hi Bryan,
> >
> > I don't really want my first (and last?) devlist message to be a fairly
> > off-the-cuff post on this topic, but here we go anyway.
> >
> > At the risk of sounding like a nostr evangelist (I promise I'm not), I
> > want to suggest nostr as a potential replacement to the mailing list. A
> > decent chunk of software would need to be written, but none of the
> > alternatives seem particularly attractive to me. I particularly dislike
> > the idea of locking into a single siloed forum service like the
> > bitcointalk forums. I realize I may be in the minority of course.
> >
> >
> > Nostr enables the ML team to outsource all of its biggest burdens, if it
> > chooses:
> >
> > - mail server blocking is N/A to nostr
> >
> > - Hosting costs are completely outsourced unless the ML team chooses to
> > host a relay.
> >
> > - Archives and web portal access can be similarly outsourced because any
> > nostr archive is self-authenticating.
> >
> > - The ML team can also choose to completely outsource moderation, as
> > nostr is (more or less) permissionless by nature.
> > I understand if there is a "blessed" communication system, the ML
> > team would probably prefer to keep it high quality. To that end there
> > are proposals for proof-of-work, and web of trust based blocklists for
> > nostr which are optional for end users. There are other options such as
> > the "moderated communities" proposal which would provide tighter control.
> >
> >
> > On the user side, the optional moderation is very attractive, allowing
> > controversial threads to exist and continue, without requiring everyone
> > to see them.
> >
> >
> > The following do not currently exist (to my knowledge) and would need to
> > be implemented to meet the ML's requirements:
> >
> > - an email gateway to satisfy the bulk of existing ML subscribers
> > This reintroduces issues with mail server blocking of course.
> > - a long-form oriented nostr client (current plain text clients could be
> > used in the meantime)
> >
> > That admittedly is quite a lot of work, but the second item can be
> > deferred, and the first is not particularly technically challenging, the
> > complications are all on the administration side.
> >
> > I expect some reflexive NACKs based on the immaturity of the ecosystem
> > but if we have months to prepare, I believe the core requirements can be
> > solidly satisfied in time, the rest can be developed over time, and I
> > believe the advantages are worth careful consideration.
> >
> > Cheers,
> > Dan
> >
> > On Tue, Nov 7, 2023 at 9:38 AM Bryan Bishop via bitcoin-dev
> > <bitcoin-dev@lists•linuxfoundation.org
> > <mailto:bitcoin-dev@lists•linuxfoundation.org>> 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
> > <mailto:bitcoin-dev@lists•linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> >
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 32484 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
2023-11-07 18:14 ` Andrew Chow
2023-11-07 19:41 ` Christopher Allen
2023-11-07 20:15 ` Ademan
@ 2023-11-09 4:03 ` William Casarin
2 siblings, 0 replies; 26+ messages in thread
From: William Casarin @ 2023-11-09 4:03 UTC (permalink / raw)
To: Andrew Chow, Bitcoin Protocol Discussion
On Tue, Nov 07, 2023 at 06:14:23PM +0000, Andrew Chow via bitcoin-dev wrote:
>Hi Dan,
>
>I don't think nostr would be a suitable replacement for the mailing
>list, although this opinion is biased by the fact that I do not use
>nostr and find it to be uninteresting.
email-like functionality over nostr isn't really explored yet, but it is
something I'm interesting in. So I agree nostr isn't a suitable email
replacement *yet*.
From my limited understanding of how nostr works, it's not clear to me
>how a distributed system that uses message broadcast would work in the
>same way as a mailing list.
My idea was to have a mailing list relay, the only thing missing is To:
and Cc: tags on notes so that the relay can reject notes not destined
for the mailing list
>How would people "subscribe"? How would archives be searched or
>otherwise be available to people who are not on nostr?
You would subscribe by connecting to the relay and pulling down the
notes. your client could cache notes and only pull new ones.
>How do you distinguish and filter between legitimate dev posts
>intended for discussion and random crap and shitposting as shows up on
>social media?
You would need to have metadata on the note that specifies that the note
is destined for that specific mailing list relay (To, Cc, etc). Then the
client sending the message can send it to that specific relay during
note composition. Again, this is different than then current model that
exists with social networking clients designed for blasting your note to
as many people as possible.
>I also don't think that long form text on nostr (or any similar
>platform) can sufficiently replace email. None of these things seem to
>contain a way to have a separate subject line as email does. Subjects
>are immensely important for me as it provides a quick and easy way to
>filter out things I don't care about reading. I don't want to have read
>something in before I can decide that I don't care about reading it.
Subject lines already exist in nostr and are a part of some email-like
clients like https://github.com/unclebob/more-speech . it's just a tag
like every other piece of metadata.
>In general, I strongly prefer email, or a platform that has email as a
>first class user interface, over platforms such as nostr, matrix, or web
>forums. Email is universal - everyone has one and everyone knows how it
>works. It dramatically lowers the barrier of entry. Having to make an
>account somewhere or download some specific client in order to
>participate will simply result in only the most dedicated participating.
>Development in open source must be an open process and the barriers to
>entry should be low.
I definitely prefer email at the moment as well, but it is also a pain
in the ass to run email infra. As someone who runs both email servers
and nostr relays I can say nostr is much more pleasant.
So yeah, it's a bit too early for a nostr replacement, but it's
definitely possible, and you get proper cryptographic identities and
schnorr signed notes which is a bonus. For dealing with spam you could
have a sat entrance fee via lightning. I will start looking into this!
Cheers,
Will
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
2023-11-07 17:03 ` Ademan
2023-11-07 18:14 ` Andrew Chow
@ 2023-11-07 23:07 ` Peter Todd
1 sibling, 0 replies; 26+ messages in thread
From: Peter Todd @ 2023-11-07 23:07 UTC (permalink / raw)
To: Ademan, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1578 bytes --]
On Tue, Nov 07, 2023 at 11:03:30AM -0600, Ademan via bitcoin-dev wrote:
> Hi Bryan,
>
> I don't really want my first (and last?) devlist message to be a fairly
> off-the-cuff post on this topic, but here we go anyway.
>
> At the risk of sounding like a nostr evangelist (I promise I'm not), I want
> to suggest nostr as a potential replacement to the mailing list. A decent
> chunk of software would need to be written, but none of the alternatives
> seem particularly attractive to me. I particularly dislike the idea of
> locking into a single siloed forum service like the bitcointalk forums. I
> realize I may be in the minority of course.
Strong NACK on nostr. It's a badly designed, centralized, protocol that needs a
significant redesign to be usable. While off topic for this mailing list, some
of its many issues include:
* Reliance on single-key, cryptography that often results in people having
their keys compromised. This is a serious problem in the context of
bitcoin-dev, where faked messages published could easily have market-moving
results.
* Inability to mirror relays: since nostr deliberately ignores the lessons of
blockchains, there is no way to be sure that you have a complete set of
messages from a given person, for a given topic, etc.
* Highly centralized design: since mirroring relays isn't reliable, in reality
nostr operates in a highly centralized fashion, dependent on a tiny number of
relays that can't be easily replaced if taken down.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
2023-11-07 15:37 Bryan Bishop
2023-11-07 16:12 ` Andrew Chow
2023-11-07 17:03 ` Ademan
@ 2023-11-07 17:48 ` Andreas Schildbach
2023-11-07 20:07 ` David A. Harding
` (6 subsequent siblings)
9 siblings, 0 replies; 26+ messages in thread
From: Andreas Schildbach @ 2023-11-07 17:48 UTC (permalink / raw)
To: bitcoin-dev
On 07/11/2023 16.37, Bryan Bishop via bitcoin-dev wrote:
> We would like to request community feedback and proposals on the future
> of the mailing list.
>
> [...]
Have you considered switching to Matrix? It's federated, much like
e-mail. It's censorship resistant, in the sense that any participating
homeserver keeps a copy of a room. And everyone can run their own
homeserver in the Matrix network.
Rooms can be E2E encrypted. For an email list replacement this is
probably not relevant, however any person-2-person communication would
benefit from being encrypted.
Synapse is the currently best developed home server that implements the
Matrix specification. It's much easier to run than an email server +
mailing list combo.
Much like E-Mail and IRC, there is a huge ecosystem of Matrix clients to
choose from.
I'm aware the UI of most Matrix clients is more suitable for a chat
system than lengthy email discussions. However, thanks to "threads",
there is no reason it could be used like that.
https://matrix.org/
https://github.com/matrix-org/synapse
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
2023-11-07 15:37 Bryan Bishop
` (2 preceding siblings ...)
2023-11-07 17:48 ` Andreas Schildbach
@ 2023-11-07 20:07 ` David A. Harding
2023-11-07 21:03 ` Keagan McClelland
2023-11-07 20:57 ` Tao Effect
` (5 subsequent siblings)
9 siblings, 1 reply; 26+ messages in thread
From: David A. Harding @ 2023-11-07 20:07 UTC (permalink / raw)
To: Bryan Bishop, Bitcoin Protocol Discussion
On 2023-11-07 05:37, Bryan Bishop via bitcoin-dev wrote:
> What about [...] delvingbitcoin.org?
I'm only willing to consider discussion groups that provide good
archives, so I think it's worth noting that James O'Beirne has written
code[1] and is currently maintaining a git repo[2] with a backup of
Delving Bitcoin discussion. See his post[3] for additional details.
In addition to providing an archive, I currently find it to be nice way
to quickly skim all posts made to the forum since I last checked (plus I
see edits)[4]:
$ cd delving-bitcoin-archive/
$ git pull
$ git log -p archive/rendered-topics/
I think some technical discussions were already migrating to Delving
Bitcoin before the shutdown notice and I expect more discussions to move
there in the future even if the current mailing list is relocated to a
new platform. Knowing that discussions are archived in a way that I can
easily replicate was key to me feeling comfortable putting significant
time into reading and writing posts on Delving Bitcoin, so I wanted to
share that information here.
-Dave
[1] https://github.com/jamesob/discourse-archive
[2] https://github.com/jamesob/delving-bitcoin-archive
[3] https://delvingbitcoin.org/t/public-archive-for-delving-bitcoin/87/6
[4] Plus every commit makes me laugh. James O'Beirne's commit robot is
called "jamesobot"
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
2023-11-07 20:07 ` David A. Harding
@ 2023-11-07 21:03 ` Keagan McClelland
0 siblings, 0 replies; 26+ messages in thread
From: Keagan McClelland @ 2023-11-07 21:03 UTC (permalink / raw)
To: David A. Harding, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2970 bytes --]
I also think that good archives are extremely important. Far more important
than being a medium of discussion is capturing all of that discussion for
posterity. An unbelievable amount of knowledge capital has been built up in
the mailing list over the years and given that Bitcoin is a system that
needs to survive complete turnover in its contributor base, it's of extreme
importance that we have a system that can capture the archive.
While Nostr might be good towards the end of being very resilient it isn't
mature enough to have good UX's built up around it wherein people with a
variety of backgrounds can engage it. Personally, I think the email UX
leaves a lot to be desired but at least it's accessible to a lot of people.
I don't think I can say the same for Nostr yet.
I won't opine much further on the solution but I think the properties we
need to solve for are:
1. Archive is effectively permanent
2. Accessible to a wide audience
3. Data format is not proprietary and isn't tied to the success or failure
of a particular organization
In principle I think that Nostr can offer a lot in the long term towards
this goal, but it isn't really an immediate solution to this problem.
Keags
On Tue, Nov 7, 2023 at 12:07 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On 2023-11-07 05:37, Bryan Bishop via bitcoin-dev wrote:
> > What about [...] delvingbitcoin.org?
>
> I'm only willing to consider discussion groups that provide good
> archives, so I think it's worth noting that James O'Beirne has written
> code[1] and is currently maintaining a git repo[2] with a backup of
> Delving Bitcoin discussion. See his post[3] for additional details.
>
> In addition to providing an archive, I currently find it to be nice way
> to quickly skim all posts made to the forum since I last checked (plus I
> see edits)[4]:
>
> $ cd delving-bitcoin-archive/
> $ git pull
> $ git log -p archive/rendered-topics/
>
> I think some technical discussions were already migrating to Delving
> Bitcoin before the shutdown notice and I expect more discussions to move
> there in the future even if the current mailing list is relocated to a
> new platform. Knowing that discussions are archived in a way that I can
> easily replicate was key to me feeling comfortable putting significant
> time into reading and writing posts on Delving Bitcoin, so I wanted to
> share that information here.
>
> -Dave
>
> [1] https://github.com/jamesob/discourse-archive
> [2] https://github.com/jamesob/delving-bitcoin-archive
> [3] https://delvingbitcoin.org/t/public-archive-for-delving-bitcoin/87/6
> [4] Plus every commit makes me laugh. James O'Beirne's commit robot is
> called "jamesobot"
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 4109 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
2023-11-07 15:37 Bryan Bishop
` (3 preceding siblings ...)
2023-11-07 20:07 ` David A. Harding
@ 2023-11-07 20:57 ` Tao Effect
2023-11-07 22:10 ` ponymontana
` (4 subsequent siblings)
9 siblings, 0 replies; 26+ messages in thread
From: Tao Effect @ 2023-11-07 20:57 UTC (permalink / raw)
To: Bryan Bishop, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1453 bytes --]
Hi, I also have faced this same problem, and here’s my solution to it:
Use the latest version of https://www.simplemachines.org/ .
This is the same forum software that powered Bitcointalk, Silk Road, etc.
It has many advantages over every other platform out there:
1. It has great anti-spam prevention tools.
2. It gives you the tools you’ve requested with respect to moderation (individual moderation accounts with customizable permissions).
3. It is simple to use.
4. It is pretty and well designed, and allows you to organize threads and forums really well (unlike Discourse).
5. It doesn’t make unnecessary use of JavaScript (unlike Discourse), and therefore works well with all search engines (present and future).
6. You can self-host it, and migrate it to another server if needed, allowing the community to maintain full control over the data (unlike Microsoft/Github).
7. It supports great search functionality.
8. It is open source, and has many community plugins.
9. It runs anywhere PHP runs.
10. It is fast.
11. It has a well established history of powering Bitcoin communities. It has been with us from Day 1.
After using phpBB for years, researching other forums software, I switched to SMF, and stuck with it. I’m happy I did so. I recommend it.
Kind regards,
Greg Slepak
> On Nov 7, 2023, at 7:37 AM, Bryan Bishop via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> [moving]
[-- Attachment #2: Type: text/html, Size: 2074 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
2023-11-07 15:37 Bryan Bishop
` (4 preceding siblings ...)
2023-11-07 20:57 ` Tao Effect
@ 2023-11-07 22:10 ` ponymontana
2023-11-07 23:08 ` Peter Todd
` (3 subsequent siblings)
9 siblings, 0 replies; 26+ messages in thread
From: ponymontana @ 2023-11-07 22:10 UTC (permalink / raw)
To: Bryan Bishop, Bitcoin Protocol Discussion
[-- Attachment #1.1: Type: text/plain, Size: 15606 bytes --]
Hi,
This impellent deadline could be took with enthusiasm from people that are anxious to experiment with new protocols and platforms that can replicate mailing lists and offer, in theory, better solutions.
I think this enthusiasm is totally positive and I encourage them to work on that ideas.
But I also think that this mailing list fills a very particoular need of communication in the bitcoin space.
The stream of ideas hosted here is strictly dependant on the form it assumes when formalized in the peculiar format of mails-threads.
Migrating these technical discussions to a forum or a pseudo-group-chat wouldn't replace this mailing list, even if the moderators behind and most of the participants would be the same.
It would eventually be a new and unstable solution, with no-guarantee to preserve the same goals reached here.
Today exist a lot of places where people can exchange ideas about bitcoin;
if new platforms will emerge as better suited to hosts BIP drafts and technical discussions, people will move organically through them.
In my opinion, "finding a new platform" is only marginally correlated to our main topic here.
If our problem is helping decide the "future of bitcoin-dev mailing list", the only two solutions to me appear to tautologically be:
1) Give continuity to bitcoin-dev mailing list with a ready drop-in replacement.
2) Don't give continuity the bitcoin-dev mailing list.
In the case 1) a solution could be find a new host for the mailing list and work around the problems exposed.
In the case 2) is possible to do nothing OR to propose a new solution as a sort of "spiritual continuation" of bitcoin-dev mailing list, and eventually see if people will converge on it.
Understanding all the difficulty behind the management of the bitcoin-dev mailing list, I think it has worked very well for many years, and I hope it will work for the years to come.
I also want to say thanks to all the people behind this mailing list for all your work and effort.
---PM
Il 7 novembre 2023 16:37:22 CET, Bryan Bishop via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> ha scritto:
>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. Back then we were given accounts to
>try the groups.io interface and administration features. Apparently we were
>not the only dev community who resisted change. To our surprise LF gave us
>several years of reprieve by instead handing the subdomain and server-side
>data to the non-profit OSUOSL lab who instead operated mailman2 for the
>past ~4 years.
>
>OSUOSL has for decades been well known for providing server infrastructure
>for Linux and Open Source development so they were a good fit. This however
>became an added maintenance burden for the small non-profit with limited
>resources. Several members of the Bitcoin dev community contributed funding
>to the lab in support of their Open Source development infrastructure
>goals. But throwing money at the problem isn’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 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
>
>“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 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/ – 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’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 as two remaining
>options.
>
>groups.io is an interesting option: they are a paid service that implements
>email communities along with online web forum support. However, their
>public changelog indicates it has been a few years since their last public
>change. They might be a smaller company and it is unclear how long they
>will be around or if this would be the right fit for hosting sometimes
>contentious bitcoin development discussions...
>
>Google Groups is another interesting option, and comes with different
>tradeoffs. It's the lowest effort to maintain option, and has both an email
>interface and web forum interface. Users can choose which mode they want to
>interact with.
>
>For the Google Groups web interface, you can use it with a non-gmail
>account, but you must create a Google Account which is free to do. it does
>not require any personal information to do so. This also allows you to add
>2FA. Non-gmail non-google users are able to subscribe and post email from
>their non-gmail non-google email accounts. Tor seems to work for the web
>interface.
>
>Will Google shut it down, will they cut us off, will they shut down
>non-google users? The same problem exists with other third-party hosts.
>
>The moderation capabilities for Google Groups and groups.io seem to be
>comparable. It seems more likely that Google Groups will be able to handle
>email delivery issues far better than a small resource-constrained
>operation like groups.io. ((During feedback for this draft, luke-jr
>indicates that Google Workspaces has been known to use blacklisted IPs for
>business email!))
>
>On the other hand, groups.io is a paid service and you get what you pay
>for... hopefully?
>
>Finally, another option is to do literally nothing. It's less work overall.
>Users can switch to forums or other websites, or private one-on-one
>communication. It would remove a point of semi-centralization from the
>bitcoin ecosystem. It would hasten ossification, but on the other hand it
>would hasten ossification and this could be a negative too. Moderators
>would be less of a target.
>
>Unfortunately, by doing nothing, there would be no more widely used group
>email communication system between bitcoin developers. Developers become
>less coordinated, mayhem and chaos as people go to different communication
>platforms, a divided community is more vulnerable, etc. BIP1 and BIP2 would
>need to be revised for other venues.
>
>The main categories of what to move to are: web forums, mailing lists, and
>hybrids of those two options. Most everything is either self-hosted or you
>pay someone else to host it. It's kind of the same problem though. It
>largely depends on how good is the software and unfortunately running your
>own MTA that forwards mail is not a good option.
>
>Going forward
>===========
>
>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
[-- Attachment #1.2: Type: text/html, Size: 16359 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 854 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
2023-11-07 15:37 Bryan Bishop
` (5 preceding siblings ...)
2023-11-07 22:10 ` ponymontana
@ 2023-11-07 23:08 ` Peter Todd
2023-11-08 14:29 ` Emil Pfeffer
2023-11-08 3:56 ` Anthony Towns
` (2 subsequent siblings)
9 siblings, 1 reply; 26+ messages in thread
From: Peter Todd @ 2023-11-07 23:08 UTC (permalink / raw)
To: Bryan Bishop, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 698 bytes --]
On Tue, Nov 07, 2023 at 09:37:22AM -0600, Bryan Bishop via bitcoin-dev wrote:
> 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.
Since this is a technical mailing list it would be fine to require people to
pay a non-refundable anti-spam fee, eg via lightning, to gain the ability to
send messages. While this would require some custom software, it's probably
even possible to implement this if a third party is used for hosting, provided
they have some kind of API.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
2023-11-07 23:08 ` Peter Todd
@ 2023-11-08 14:29 ` Emil Pfeffer
0 siblings, 0 replies; 26+ messages in thread
From: Emil Pfeffer @ 2023-11-08 14:29 UTC (permalink / raw)
To: Peter Todd, Bitcoin Protocol Discussion
On Tue, Nov 07, 2023 at 11:08:58PM +0000, Peter Todd via bitcoin-dev wrote:
> On Tue, Nov 07, 2023 at 09:37:22AM -0600, Bryan Bishop via bitcoin-dev wrote:
> > 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.
>
> Since this is a technical mailing list it would be fine to require people to
> pay a non-refundable anti-spam fee, eg via lightning, to gain the ability to
> send messages. While this would require some custom software, it's probably
> even possible to implement this if a third party is used for hosting, provided
> they have some kind of API.
>
Could be done but it's overkill.
Running your own mail server is not that scary as the initial post makes it out
to be. Sending out spam is problematic only when you allow imap/pop3 access
which is not the case when running a mailling list.
My suggestion is to get the Bitcoin CEO hook us up on https://lists.freebsd.org
Failling that I volunteer to get the same setup going for a community run
project.
--
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
2023-11-07 15:37 Bryan Bishop
` (6 preceding siblings ...)
2023-11-07 23:08 ` Peter Todd
@ 2023-11-08 3:56 ` Anthony Towns
2023-11-13 2:58 ` Antoine Riard
2023-11-13 15:05 ` Overthefalls
9 siblings, 0 replies; 26+ messages in thread
From: Anthony Towns @ 2023-11-08 3:56 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
On Tue, Nov 07, 2023 at 09:37:22AM -0600, Bryan Bishop via bitcoin-dev wrote:
> Web forums are an interesting option, but often don't have good email user
> integration.
> What about bitcointalk.org or delvingbitcoin.org?
delvingbitcoin.org is something I setup; it's a self-hosted discourse
instance. (You don't have to self-host discourse, but not doing so limits
the number of admins/moderators, the plugins you can use, and the APIs you
can access)
For what it's worth, I think (discourse) forums have significant
advantages over email for technical discussion:
* much better markup: you can write LaTeX for doing maths, you
can have graphviz or mermaid diagrams generated directly from text,
you can do formatting without having to worry about HTML email.
because that's done direct from markup, you can also quote such
things in replies, or easily create a modified equation/diagram
if desired, things that are much harder if equations/diagrams are
image/pdf attachments.
* consistent threading/quoting: you don't have to rely on email clients
to get threading/quoting correct in order to link replies with the
original message
* having topics/replies, rather than everything being an individual
email, tends to make it easier to avoid being distracted by followups
to a topic you're not interested in.
* you can do reactions (heart / thumbs up / etc) instead of "me too"
posts, minimising the impact of low-content responses on readers,
without doing away with those responses entirely.
* after the fact moderation: with mailing lists, moderation can only
be a choice between "send this post to every subscriber" or not,
and the choice obviously has to be made before anyone sees the posts;
forums allow off-topic/unconstructive posts to be removed or edited.
Compared to mailing-lists-as-a-service, a self-hosted forum has a few
other possible benefits:
* it's easier to setup areas for additional topics, without worrying
you're going to be forced into an arbitrarily higher pricing tier
* you can setup spaces for private working groups. (and those groups can
make their internal discussions public after the fact, if desired)
* you can use plugin interfaces/APIs to link up with external resources
There are a few disadvantages too:
* discourse isn't lightweight -- you need a whole bunch of infrastructure
to go from the markdown posts to the actual rendered posts/comments;
so backups of just the markdown text isn't really "complete"
* discourse is quite actively developed -- so it could be possible
that posts that use particular features/plugins (eg to generate
diagrams) will go stale eventually as the software changes, and stop
being rendered correctly
* discourse gathers a moderate amount of non-public/potentially private
data (eg email addresses, passwords, IP addresses, login times) that
may make backups and admin access sensitive (which is why there's a
git archive generated by a bot for delvingbitcoin, rather than raw
database dumps)
There are quite a few open source projects using discourse instances, eg:
Python: https://discuss.python.org/
Ruby on Rails: https://discuss.rubyonrails.org/
LLVM: https://discourse.llvm.org/
Jupyter: https://discourse.jupyter.org/
Fedora: https://discussion.fedoraproject.org/
Ubuntu: https://discourse.ubuntu.com/
Haskell: https://discourse.haskell.org/
There's also various crypto projects using it:
Eth research: https://ethresear.ch/
Chia: https://developers.chia.net/
There's a couple of LWN articles on Python's adoption of discourse
that I found interesting, fwiw:
https://lwn.net/Articles/901744/ [2022-07-20]
https://lwn.net/Articles/674271/ [2016-02-03]
I don't think this needs to be an "either-or" question -- better to
have technical discussions about bitcoin in many places and in many
formats, rather than just one -- but I thought I'd take the opportunity
to write out why I thought discourse was worth spending some time on in
this context.
Cheers,
aj
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
2023-11-07 15:37 Bryan Bishop
` (7 preceding siblings ...)
2023-11-08 3:56 ` Anthony Towns
@ 2023-11-13 2:58 ` Antoine Riard
2023-11-13 15:05 ` Overthefalls
9 siblings, 0 replies; 26+ messages in thread
From: Antoine Riard @ 2023-11-13 2:58 UTC (permalink / raw)
To: Bryan Bishop, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 14819 bytes --]
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 à 15:37, Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> a écrit :
> 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. Back then we were given
> accounts to try the groups.io interface and administration features.
> Apparently we were not the only dev community who resisted change. To our
> surprise LF gave us several years of reprieve by instead handing the
> subdomain and server-side data to the non-profit OSUOSL lab who instead
> operated mailman2 for the past ~4 years.
>
> OSUOSL has for decades been well known for providing server infrastructure
> for Linux and Open Source development so they were a good fit. This however
> became an added maintenance burden for the small non-profit with limited
> resources. Several members of the Bitcoin dev community contributed funding
> to the lab in support of their Open Source development infrastructure
> goals. But throwing money at the problem isn’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 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
>
> “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 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/ – 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’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 as two remaining
> options.
>
> groups.io is an interesting option: they are a paid service that
> implements email communities along with online web forum support. However,
> their public changelog indicates it has been a few years since their last
> public change. They might be a smaller company and it is unclear how long
> they will be around or if this would be the right fit for hosting sometimes
> contentious bitcoin development discussions...
>
> Google Groups is another interesting option, and comes with different
> tradeoffs. It's the lowest effort to maintain option, and has both an email
> interface and web forum interface. Users can choose which mode they want to
> interact with.
>
> For the Google Groups web interface, you can use it with a non-gmail
> account, but you must create a Google Account which is free to do. it does
> not require any personal information to do so. This also allows you to add
> 2FA. Non-gmail non-google users are able to subscribe and post email from
> their non-gmail non-google email accounts. Tor seems to work for the web
> interface.
>
> Will Google shut it down, will they cut us off, will they shut down
> non-google users? The same problem exists with other third-party hosts.
>
> The moderation capabilities for Google Groups and groups.io seem to be
> comparable. It seems more likely that Google Groups will be able to handle
> email delivery issues far better than a small resource-constrained
> operation like groups.io. ((During feedback for this draft, luke-jr
> indicates that Google Workspaces has been known to use blacklisted IPs for
> business email!))
>
> On the other hand, groups.io is a paid service and you get what you pay
> for... hopefully?
>
> Finally, another option is to do literally nothing. It's less work
> overall. Users can switch to forums or other websites, or private
> one-on-one communication. It would remove a point of semi-centralization
> from the bitcoin ecosystem. It would hasten ossification, but on the other
> hand it would hasten ossification and this could be a negative too.
> Moderators would be less of a target.
>
> Unfortunately, by doing nothing, there would be no more widely used group
> email communication system between bitcoin developers. Developers become
> less coordinated, mayhem and chaos as people go to different communication
> platforms, a divided community is more vulnerable, etc. BIP1 and BIP2 would
> need to be revised for other venues.
>
> The main categories of what to move to are: web forums, mailing lists, and
> hybrids of those two options. Most everything is either self-hosted or you
> pay someone else to host it. It's kind of the same problem though. It
> largely depends on how good is the software and unfortunately running your
> own MTA that forwards mail is not a good option.
>
> Going forward
> ===========
>
> 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
>
[-- Attachment #2: Type: text/html, Size: 16205 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
2023-11-07 15:37 Bryan Bishop
` (8 preceding siblings ...)
2023-11-13 2:58 ` Antoine Riard
@ 2023-11-13 15:05 ` Overthefalls
2023-11-13 18:51 ` alicexbt
9 siblings, 1 reply; 26+ messages in thread
From: Overthefalls @ 2023-11-13 15:05 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]
On Tue, 2023-11-07 at 09:37 -0600, Bryan Bishop via bitcoin-dev wrote:
Google Groups is another interesting option,
I don't think I'm the only person on this list that is strongly opposed
to using google for anything. They are too big and they have their hand
in everything, and their eyes (and analytics) on everything.
I remember when there were virtually no gmail email addresses that
posted to this list. Suddenly in 2020 or 2021, we had an influx of
gmail subscribers and posters. That didn't escape me then and it is not
lost on me now.
Email is great for public discussion for many reasons. The fact that
everyone gets a copy of the data, there is no single central authority
that can edit emails once they have been sent out. Anyone can archive
email messages, they can generally store or publish the data anywhere
they like. That is not the case with web forum content.
I like the lightning anti-spam fee idea. That would encourage me to
finally adopt lightning, and it would, I'm sure, produce some
interesting results for the list.
I don't think email should be out of the question. Does anyone besides
kanzure@gmail•com think that sticking with email is out of the
question?
Let's do what's necessary to stick with email.
[-- Attachment #2: Type: text/html, Size: 1699 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
2023-11-13 15:05 ` Overthefalls
@ 2023-11-13 18:51 ` alicexbt
2023-11-14 15:32 ` Overthefalls
0 siblings, 1 reply; 26+ messages in thread
From: alicexbt @ 2023-11-13 18:51 UTC (permalink / raw)
To: Overthefalls; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2352 bytes --]
Hi Overthefalls,
+1
Using google for bitcoin mailing list is not good. It feels embarrassing that some developers that built and maintained the only decentralized network used to settle uncensored payments and some of them even working on nostr, can't build their own mailing list which is better than present mailing list. I have some ideas but it seems the influential developers have already decided and wont accept anything.
Nostr can be used to build a mailing list which also allows anyone to send emails apart from publishing events from different clients. We just need a new NIP so that nostr relays understand its a different event. There can be multiple front end with different levels of moderation to hide some emails and ultimately one will be used the most. It can use multiple relays and relays share some information in NIP 11 which can include an email address.
/dev/fd0
floppy disk guy
Sent with [Proton Mail](https://proton.me/) secure email.
On Monday, November 13th, 2023 at 8:35 PM, Overthefalls via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Tue, 2023-11-07 at 09:37 -0600, Bryan Bishop via bitcoin-dev wrote:
>
>> Google Groups is another interesting option,
>
> I don't think I'm the only person on this list that is strongly opposed to using google for anything. They are too big and they have their hand in everything, and their eyes (and analytics) on everything.
>
> I remember when there were virtually no gmail email addresses that posted to this list. Suddenly in 2020 or 2021, we had an influx of gmail subscribers and posters. That didn't escape me then and it is not lost on me now.
>
> Email is great for public discussion for many reasons. The fact that everyone gets a copy of the data, there is no single central authority that can edit emails once they have been sent out. Anyone can archive email messages, they can generally store or publish the data anywhere they like. That is not the case with web forum content.
>
> I like the lightning anti-spam fee idea. That would encourage me to finally adopt lightning, and it would, I'm sure, produce some interesting results for the list.
>
> I don't think email should be out of the question. Does anyone besides kanzure@gmail•com think that sticking with email is out of the question?
>
> Let's do what's necessary to stick with email.
[-- Attachment #2: Type: text/html, Size: 4379 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Future of the bitcoin-dev mailing list
2023-11-13 18:51 ` alicexbt
@ 2023-11-14 15:32 ` Overthefalls
0 siblings, 0 replies; 26+ messages in thread
From: Overthefalls @ 2023-11-14 15:32 UTC (permalink / raw)
To: alicexbt; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 3029 bytes --]
Hi floppy disk guy, thanks for prompting me to look closer at Nostr,
it's very interesting.
I hope that whatever solution is chosen doesn't involve handing power
over to a centralized entity that wants collect as much information on
every living person as possible, and lock everyone and everything into
using it's services forever.
On Mon, 2023-11-13 at 18:51 +0000, alicexbt wrote:
> Hi Overthefalls,
>
>
> +1
>
>
> Using google for bitcoin mailing list is not good. It feels
> embarrassing that some developers that built and maintained the only
> decentralized network used to settle uncensored payments and some of
> them even working on nostr, can't build their own mailing list which
> is better than present mailing list. I have some ideas but it seems
> the influential developers have already decided and wont accept
> anything.
>
> Nostr can be used to build a mailing list which also allows anyone to
> send emails apart from publishing events from different clients. We
> just need a new NIP so that nostr relays understand its a different
> event. There can be multiple front end with different levels of
> moderation to hide some emails and ultimately one will be used the
> most. It can use multiple relays and relays share some information in
> NIP 11 which can include an email address.
>
>
> /dev/fd0
> floppy disk guy
>
>
>
>
>
>
>
>
> Sent with Proton Mail secure email.
>
>
>
>
>
> On Monday, November 13th, 2023 at 8:35 PM, Overthefalls via
> bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>
>
> > On Tue, 2023-11-07 at 09:37 -0600, Bryan Bishop via
> > bitcoin-dev wrote:
> > > Google Groups is another interesting option,
> >
> > I don't think I'm the only person on this list that is strongly
> > opposed to using google for anything. They are too big and they
> > have their hand in everything, and their eyes (and analytics) on
> > everything.
> > I remember when there were virtually no gmail email addresses that
> > posted to this list. Suddenly in 2020 or 2021, we had an influx of
> > gmail subscribers and posters. That didn't escape me then and it is
> > not lost on me now.
> > Email is great for public discussion for many reasons. The fact
> > that everyone gets a copy of the data, there is no single central
> > authority that can edit emails once they have been sent out. Anyone
> > can archive email messages, they can generally store or publish the
> > data anywhere they like. That is not the case with web forum
> > content.
> > I like the lightning anti-spam fee idea. That would encourage me to
> > finally adopt lightning, and it would, I'm sure, produce some
> > interesting results for the list.
> > I don't think email should be out of the question. Does anyone
> > besides kanzure@gmail•com think that sticking with email is out of
> > the question?
> > Let's do what's necessary to stick with email.
> >
> >
> >
> >
> >
> >
>
>
[-- Attachment #2: Type: text/html, Size: 5105 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread