I've brought up the same point in a number of threads that have brought up mailing lists over the years. In the specific case of mailing lists like the ones used for Linux kernel and git development, I believe many participants host their own SMTP instances and use them to send and receive messages and have had those set ups for a long time.
If they were to switch to NNTP, they would either have to:
1. Create a new group on usenet (and have to somehow filter out all the spam posted to it or everyone will have to keep their NNTP client kill file up to date)
or
2. They each would have to host their own NNTP server and each one would have to add enough peering servers (incoming and outgoing) to ensure that articles are propogated to them and articles they post are propagated to others
or
3. The maintainer would have to set up a authoritative NNTP server and allow read access, but then have to add accounts for those who need write access (in order to allow them to submit patches).
Continuing to use SMTP allows them to essentially choose option 2, but not have to set up peering servers since DNS MX records handle propagating the emails they send.
That said, having a NNTP mirror of a mailing list like gmane[1] and public-inbox[2] provides the best of both worlds. You get the benefits of NNTP for reading the mailing list, but get the benefits of propagation via SMTP.
Given gmane's funding crises over the years, it feels hard to recommend relying on such a service long term. (Though I've certainly relied on it over the years for a number of different reasons.)
What we almost need is an NNTP 2.0 that makes it easier for smaller federated groups. (Maybe this is a good use for ActivityPub and/or Matrix?)
(Public-Inbox is new to me and at first skim seems to cover some interesting bases here. I'm not thrilled at the AGPL licensing though.)
> What we almost need is an NNTP 2.0 that makes it easier for smaller federated groups.
We've had that with XMPP and Publish-Subscribe for years: if the project has a server with this XEP enabled, any authorized user (registered anywhere) can post any type of content.
PubSub alone isn't a great replacement for NNTP. (It's maybe a replacement for SMTP.) The reasons for an NNTP 2.0 (as mentioned above) are more about storage/forwarding, if you want access to the back history as opposed to just live updates. You can build such things on top of a PubSub protocol, as ActivityPub is at heart still a PubSub protocol, but has a lot more storage/forwarding concerns added on top, as an example.
Fair points. I wasn't aware of any of these tools, but then like the majority of the world I haven't actively used XMPP in years (which is obviously among its largest cons today).
My intent wasn't to diminish your initial comment, just that a protocol is a technical answer to a problem that is more probably a societal one. It takes time and effort to commit to another communication protocol, especially when it's not the core of what you're doing as a project. Maybe what is needed is not just a protocol but proper tools to make it easy to use (and the bar with the simplicity of email is very high)
public-inbox seems to be the best of both worlds indeed. Interestingly it fits your option 1: posting is open and the admin is in charge of handling spam.
But public-inbox goes way further with other means of pulling, and the easy and trusted replication gives it the same status as the code: the repo is the source of truth, not the email endpoint. I could see projects using that and, say, gitolite as the two main bricks for running a project. Now all we need is a simple CI/CD system that is designed to run on its own rather than in a specific ecosystem
If they were to switch to NNTP, they would either have to:
1. Create a new group on usenet (and have to somehow filter out all the spam posted to it or everyone will have to keep their NNTP client kill file up to date)
or
2. They each would have to host their own NNTP server and each one would have to add enough peering servers (incoming and outgoing) to ensure that articles are propogated to them and articles they post are propagated to others
or
3. The maintainer would have to set up a authoritative NNTP server and allow read access, but then have to add accounts for those who need write access (in order to allow them to submit patches).
Continuing to use SMTP allows them to essentially choose option 2, but not have to set up peering servers since DNS MX records handle propagating the emails they send.
That said, having a NNTP mirror of a mailing list like gmane[1] and public-inbox[2] provides the best of both worlds. You get the benefits of NNTP for reading the mailing list, but get the benefits of propagation via SMTP.
[1] https://gmane.io/
[2] https://public-inbox.org/README.html