Forty-six thousand four hundred and thirty-four.
That's just the LISTSERV catalog. One directory.
One directory of public email lists, still running, still open to anyone with an address. Daniel's been chewing on this since the listserv episode. His words: there's something empowering about a discourse that happens fully in public. He spends his week in GitHub issues, and he's good at it, but he keeps noticing the register is different. An issue comment is two cents on something small and atomic. A listserv thread is often an argument about a project's architecture, and it goes on for three weeks, and everyone can see all of it, forever.
And he wants to stretch the word.
Deliberately. Any exchange of information, in threads, fully open, indexed by search engines. He thinks that last part is the load-bearing one. That indexing is what keeps people civil, because you can't hide behind a disposable username when your post is the fourth result for a search someone will run in five years.
He's got a hypothesis and a request in the same message.
He does. Are there lists a person can actually join, including ones with nothing to do with technology? And then the harder one: should we open a listener forum, and what would we build it on? He's honest that he wouldn't do it without moderation. He just likes the idea of a public town hall.
Then let's give him both. The mechanism first, because that's where the surprise is.
The surprise being that a technology from before most of our listeners were born is technically superior to the thing that replaced it.
For certain jobs, yes. Start with what a mailing list actually is, stripped down. You subscribe with an email address. Messages arrive in your inbox. Replies go back to the list and get threaded. Every message is archived, and the archive is public and plain text.
It is the whole thing, Corn. Rich Kulawiec wrote this up for the IETF general list last year, twenty advantages, and the one that stops me is the archive format. Mbox. You can read an mbox file today with software that didn't exist when it was written, and you'll be able to read it in thirty years. Try opening a web forum from 2004.
You get a database error and a plugin that no longer exists.
You get nothing. And here's the part that reframes the whole conversation. Drew DeVault at SourceHut made the censorship argument, and it's not really about censorship. A mailing list distributes a complete copy of the archive to every subscriber. So the archive doesn't live anywhere in particular. It lives in forty thousand inboxes.
Which means if the server dies, or the maintainer loses interest, or somebody decides the list shouldn't exist anymore...
Somebody else stands up a server and imports the mbox file and the list continues under a new name with the same history. There's no migration project. There's no export tool that broke. The archive was always already distributed. DeVault's line is that carrying on is effortless.
That's a resilience property, not a civility property. Those are two different things and I want to keep them apart.
Keep them apart, then.
Because Daniel's intuition is about civility. Public indexing makes people behave. But you're telling me the older, stronger argument for the format is that it can't be killed.
Both are true and they're independent. The format survives because it's distributed. The tone improves because it's indexed. Different mechanisms, same artifact.
All right. Kulawiec also had a line about the client.
No special software. This is the one people miss. You use the mail client you already have and already know. There's no site to learn, no notification system to configure, no app to install on a phone that will stop being supported in two years. Twenty mailing lists is about as easy as one, in his phrasing. Twenty web forums is onerous, because each one is its own little universe with its own rules and its own forgotten password.
I've watched you sign up for twenty of anything.
I've done it this month.
I know. I found the emails.
Point taken. But there's a structural thing under it. Push versus pull. A mailing list pushes to you. You don't have to remember to check it. That sounds trivial until you're trying to follow eleven conversations across four platforms, and the only reason you keep up is that three of them come to your inbox whether you think about them or not.
Then the threading point, because that's where the GitHub comparison actually bites.
Kulawiec: they handle threading well, and that's essential for anyone trying to follow a discussion. An email client shows you a tree. This reply is to that reply, which is to this original message. You can collapse a branch and skip four hundred messages of a sub-argument you don't care about, and the sub-argument is still there when you want it.
GitHub issues are a single column.
A single column with a comment box at the bottom. Replies to replies get flattened. If a thread forks, and it always forks, one branch just becomes people quoting each other with an arrow and a username, and the structure is gone. You reconstruct it by reading carefully. There's no tree to collapse.
And Daniel's point isn't just about structure. It's about altitude.
Go on.
An issue comment is usually about a specific thing. This function has an off-by-one. This dependency is unmaintained. That pull request breaks the Windows build. All true, all useful, all small. A listserv thread about a project is often about the project. Should the plugin API be stable across major versions. Should we accept patches that add a dependency. What is this piece of software for.
And there's a mechanical reason the listserv does that better. On a list, the burden is on the submitter to be worth reading. Everyone's inbox is the venue. You have to justify the interruption. On GitHub, the burden is on the maintainer to keep unresolved issues low, which is why terse one-line comments and drive-by opinions are cheap. The economics of attention point in opposite directions.
So the format selects for a different kind of contribution.
Not perfectly. Plenty of mailing lists have produced ten thousand messages of people being wrong at each other. But the default posture is different. You're writing a letter to a room of people who chose to be in that room.
Now the decline story, because it's the obvious objection.
Chris Siebenmann, a sysadmin who writes well, in 2023: I've mostly stopped reading technical mailing lists. And he's not alone. The energy moved to GitHub, to Discord, to Slack. That's real.
And yet.
And yet lua-l has been running continuously for over twenty-five years. About a hundred and forty-five thousand messages since 1997. The Lua project's own page says everyone is welcome to join. That is not a relic. That's a community that never left.
The IETF itself revived the why-mailing-lists essay last year, which is an institution in its sixties publishing a defense of email.
Because when the IETF needed a place to argue about its own process, it went back to the list. Same for PostgreSQL, whose public archives run back to 1997. Full Disclosure is still the neutral public venue for vulnerability arguments. The format is dying the way radio died.
Which is to say it isn't, and the obituaries are about a specific demographic of reader rather than the medium.
Siebenmann is describing his own attention, honestly, and generalizing it. He's not wrong about himself.
Right. So who's actually joinable? Give me the open ones.
lua-l is the cleanest example. Anyone can join, you just have to subscribe before you post, which is a small anti-spam gate. The IETF general list is the most general list the IETF runs, fully public, fully archived. The PostgreSQL lists are public and independently syndicated, so the archive exists in several places that don't coordinate. Full Disclosure is public and vendor-neutral by design, which is a political stance as much as a technical one.
And the non-technical side, which is the part Daniel actually cares about.
That's where it gets good. H-Net is a scholarly consortium in the humanities, sponsored by the National Endowment for the Humanities and Michigan State. H-MMEDIA is open to scholars, graduate students, teachers, media specialists, librarians, and software developers. There's a user description of it I keep thinking about: not a firehose of comments and spam, but a well-regulated stream of good content.
A well-regulated stream. That's a moderation model described as hydrology.
SHAKSPER is in its thirty-sixth year, edited and moderated, an international email list for Shakespeare scholars, archives open to anybody. Thirty-six years of people arguing about textual variants in a format that predates the web.
And WRYTING-L at West Virginia, theory and writing, open to all, run with a minimum of management. I like that phrase. Minimum of management.
nettime-l has been open since spring 1995. You subscribe with an email address. It's cultural and political, not technical at all. There's a poetics list at Penn, a fantastic-in-the-arts list, a list called WETARTS that covers music, opera, gourmet cooking, and poetry, and other topics by consensus.
Other topics by consensus. That's how you end up with a mailing list about opera that has opinions about your risotto.
The JiscMail service in the UK hosts a pile of arts and humanities lists. UK-Ireland Digital Humanities is open for anyone to join. And the CataList catalog from L-Soft is a directory of forty-six thousand public LISTSERV lists. Whatever you're into, there is a list, and it has been running since before you knew the topic existed.
So the loose definition holds up, with one wrinkle.
Say the wrinkle.
Everything you just listed is email. When I go looking for a modern, non-technical, fully open, search-indexed web forum, I don't find one. The humanities people never left email. The web forum world is either technical or it's a subreddit, which is open but where the indexing is partial and the identity model is a username you can abandon in four seconds.
That was my finding too, and I went looking hard. The non-technical open examples are all listservs. The modern forum examples are all technical or semi-technical. There's very little in between. It's a real gap in the landscape.
So the loose definition Daniel wants is served by exactly two things today. Classic email lists, or a Discourse-style web forum. Nothing in the middle.
Which is a strange place for the ecosystem to have landed.
Now the civility question, because this is the part I don't trust yet.
Good instinct.
Daniel's claim is that public indexing produces civil discourse and anonymity degrades it. That's a clean story. Clean stories about human behavior usually have a study on each side.
They do here. Arthur Santana at the University of Houston, publishing in Journalism Practice in 2014. He looked at newspaper comment sections. Fifty-three point three percent of anonymous comments contained vulgar, racist, profane, or hateful language. Twenty-eight point seven percent of non-anonymous comments did.
That's not a small gap.
It gets wider. Non-anonymous commenters were nearly three times as likely to post civil comments. Forty-four percent versus fifteen. His conclusion was blunt: when anonymity was removed, civility prevailed. And in the same period, forty-eight point nine percent of the hundred and thirty-seven largest US newspapers disallowed anonymity in their comments.
That's the paper that killed anonymous commenting in newspapers, basically.
It's the paper everyone cited when they did it. And it's the paper that gets quoted whenever this argument comes up. Now the other side.
Please.
Moore, Fredheim, Wyss and Beste, in Political Studies, analyzing forty-five million Huffington Post comments between January 2013 and May 2015. Three hundred and thirty-six thousand users, two point seven million user-month observations.
That's not a survey. That's everybody.
It's everybody who commented on Huffington Post for two and a half years. And they found the opposite of the simple story. In December 2013, HuffPo moved to durable pseudonyms. In June 2014, it moved again, to real names through Facebook. Cognitive complexity in the comments rose under pseudonymity. Then it fell after the real-name change.
So real names made it dumber.
Measurably less cognitively complex. And the authors' conclusion was that there's potential value in durable pseudonymity. Their phrasing was that the findings challenge the terms of the apparently simple trade-off between anonymous and real-name environments.
Wait. Say the durability part again, because that's the hinge.
Durable. Not disposable. A pseudonym you keep. A handle that has five years of history behind it, that people recognize, that you can't throw away without losing everything you built under it.
That's not anonymity and it's not a real name. That's a reputation.
It's a reputation, and it's portable, and it survives the platform, which real names don't.
So Daniel's intuition is half right and the half he's missing is the interesting half. He thinks search indexing is the mechanism. What the research actually points at is persistence. A stable identity with a history attached.
Indexing helps because indexing is what makes the history visible. But indexing a throwaway account doesn't buy you anything. You need the account to have continuity. The public record only disciplines you if the record is attached to you.
So the town square works not because everyone knows your name but because everyone knows your record.
And there's practitioner skepticism on top of it. In the thread around the IETF essay, one commenter pointed out that mandatory real-name policies have never been shown to improve civility. Another said flatly that people under their real names behave just the same as the anonymous crowd.
Which matches everything I've seen. There are named accounts on every platform behaving like animals.
The real-name policy doesn't change the person. It changes the cost of being recognized, and if the person was never going to be recognized again anyway, the cost is zero.
So we've got three positions. Real names are better. Pseudonyms are better. It doesn't matter. And the honest answer is that the variable everyone's been arguing about isn't the one doing the work.
That's where I land. The variable is durability.
Hm.
You don't like it.
I don't like that it's true and useless. Durable pseudonymity is easy to describe and hard to enforce. You can require an email address. You can't require someone to care about their reputation.
You can make the account expensive to abandon. That's what the discipline is. Continuity, history, no easy reset.
Which is what a mailing list does by accident. You subscribed in 2011 under your actual name and you've been posting under it ever since, and everyone on the list knows your prose.
They know your prose. That's the exact phrase I'd use.
So now the actual question. Do we open one of these for the show?
I think the answer is yes with a specific shape, and the shape matters more than the yes.
Because the naive version is a Discord.
The naive version is a Discord or a Slack, and that's the one thing I'd rule out. There's a comment from the same thread that's stuck with me. Discord and Slack and Facebook groups are not indexed by search engines, and the person put it as: it's asking for knowledge to be lost. Another one said every single day the volume of current technical knowledge gets smaller as chat moves to Discord.
Because the conversation happened, and it was good, and then it evaporated.
It evaporated. Somebody answered your question well in a Discord in 2021 and you will never find it. That's the opposite of what Daniel's after. He wants the indexed thing. So the forum has to be crawlable, or it's not the project he described.
So what's the stack?
The pragmatic answer is Discourse. And I want to be honest that it's not a compromise pick, it's the one that actually satisfies the requirements. Open registration, real threading, sitemaps so the archive is crawlable by search engines, email-in posting so you can reply from your inbox the way a listserv works, and moderation tooling that's been hammered on for a decade.
It's GPL, isn't it.
GPL-2.0, about forty-three thousand stars on GitHub. Jeff Atwood and Robin Ward built it, and it's been the default for long-form, search-friendly asynchronous discussion at scale ever since. The realistic cost is about four gigabytes of RAM, and at least two people willing to moderate. That second requirement is the real one.
Two moderators for a podcast forum.
At minimum. It's not the software that's the load. It's the two humans.
What else is on the table?
Flarum if you want the leanest version. One gigabyte of RAM, one moderator, much simpler. NodeBB if you want real-time, event-driven, JavaScript-extensible, which is nice if you're building integrations but it's more machinery than the job needs. phpBB and MyBB are the long-lived classics, they run on cheap shared hosting, and they're fine, they just look and feel like 2009.
And if we wanted the honest-to-goodness listserv.
Mailman 3. And I have to report that the consensus among the people who've administered it is that it's horrible. Three separate services, configuration that fights you at every step. There's a Mailman 2 Python 3 port people fall back on. Sympa is another option. It's all real software that works, it's just that running a listserv in 2026 is a sysadmin project, not a weekend project.
You'd want the listserv feel without the listserv administration.
Which is exactly why Discourse wins. Email-in posting gets you the interaction model. The web archive gets you the indexing. The moderation queue gets you the thing Daniel said he wouldn't launch without.
Because he was clear about that. He'd be hesitant to create it with no moderation, and he's right. The public town hall idea only works if somebody sweeps the floor.
Moderation is what makes it a town hall. Without it you don't get a town hall, you get the comments section Santana studied.
So there's a real design question under the software choice. What's the moderation model. Because there's a version where two of us sit on a queue approving posts, and that doesn't scale, and it dies in a month.
The model that works is the one the old lists used without calling it that. Light touch by default, heavy on a few rules, and post-hoc rather than pre-approval. Shakespeare scholars have run an edited list for thirty-six years without a full-time editor. H-Net manages it with volunteer editors across dozens of lists. The minimum-of-management model from WRYTING-L is the actual precedent.
Light touch, but present.
Present enough that a person can tell someone else is reading. That's most of the effect.
And durable identity. If we do this, the account history should be real. You shouldn't be able to burn a handle and start over clean.
That's the one place I'd push back on the defaults, because Discourse is set up to let people register fast.
Which is right for growth and wrong for the property we just said we wanted.
Correct. If the thing we want is the durability effect, the forum has to be built so that abandonment costs something. Not much. Just enough that a handle carries weight.
And the archive has to be exportable, or we've learned nothing.
The whole argument for the format was that the archive survives the operator. If we build a forum where the data is ours and nobody else's, we've built the walled garden Herman keeps complaining about.
You just referred to yourself in the third person.
I heard it as it left my mouth.
The archive should be dumped to plain text on a schedule. Subscribers can take a copy. That's the mbox property translated forward. Right. And whoever runs it should be able to hand the entire business to someone else in an afternoon.
We've been using it the whole time.
Listserv is a trademark. LISTSERV, all caps, L-Soft owns it. What you've been describing is a mailing list. The -serv is the product.
I'm not correcting you to be difficult. It's just that when people say listserv they mean the category, and the category isn't L-Soft's. You've been saying it right for an hour, I just wanted it on the record.
Noted. And fair.
And I'll tell you where your theory goes wrong.
Go ahead.
The civility isn't the indexing. I ran one of these. It was a niche thing. I won't bore you with the details, but I had about four hundred subscribers at its peak and I've still got the complete archive on a drive in the hall. I can search it faster than any web forum on earth because I wrote the scripts myself and they do exactly what I tell them.
And the civility came from what, if not the public record?
It came from the fact that everyone knew how everyone else wrote. You could identify a poster from their comma usage. I'm not exaggerating. There was a man on that list who put a comma before every conjunction and I knew him before I read his name. You can't get away with being a jerk when the room recognizes your punctuation.
So it's not identity, it's authorship.
It's authorship. The record is public either way. What disciplines you is that the record is recognizably yours.
That's a different mechanism than the pseudonym research. That's not durability of account, that's durability of voice.
It's the same thing with different paperwork.
Has it ever actually worked. The discipline.
Once. I had a flame war that ran for nine days. Two men, one of them wrong, both of them certain. So I printed the whole thread out, all of it, about forty pages, and mailed it to the offender's mother.
You mailed a stranger a printout of her son's argument.
She was the reigning regional champion in the discipline. Lawnmower racing. The son backed down inside a week.
I'm sorry. Lawnmower racing.
It's a real sport. There's a class for nearly-stock engines and the speeds are higher than you'd think. The mother was very good. She'd been champion in the region for years and she didn't appreciate being embarrassed by post.
So you sent her the thread.
She read it. She phoned her son. He apologized to the list. Then he left the list for about a year, and then he came back and was fine.
And the mother.
She subscribed the following spring. She was one of the most prolific posters on that list for a long time. She had opinions about gearing and she wasn't shy about them.
She joined the list.
She did. She still sends a card every Christmas. Every year. Same handwriting.
I have several questions and I'm not going to ask any of them.
Good.
The part I'm taking from that is that the moderation was one guy with a printer and a plausible threat. That's not a scalable model.
Not with a printer. But the principle scales. Somebody has to be willing to actually do the thing. Most moderation fails because nobody wants to be the person who does the thing.
And you were willing to do the thing. Do we even want to know how much postage that was.
Forty-one cents an ounce in those days. It was a thick envelope.
Hm.
You'd wait a couple of weeks for a reply to anything back then. It made people think before they typed. Nobody says anything they'd have to walk back two weeks later.
That's latency as a moderation tool.
The delay did more work than the rules ever did.
So there's the thing from the cutting room floor, and I've been holding it all episode. When Siebenmann wrote the post about giving up on technical mailing lists, the reason he gave wasn't tone and it wasn't moderation. It was volume. AI bug hunters have changed the traffic. Linus Torvalds said this past May that AI-powered bug reports have made the Linux security mailing list almost entirely unmanageable. The list didn't die of incivility. It died of being flooded by machines that are very good at finding things and have no sense of what's worth saying.
Which is a completely different failure mode than the one Daniel's worried about.
Which is the thought I want to leave listeners with, actually. The civility argument and the survival argument are separate, and we've been treating them as one. The old lists solved civility with a small room, slow postage, and people who recognized each other. What they never solved was scale, and the thing that finally broke the biggest of them wasn't a troll. It was a machine with infinite patience and nothing to lose.
And the fix for that isn't better moderation. It's a different kind of gate.
Which we do not have. Anyway. Thank you to Hilbert Flumingtop, our producer, who keeps the lot running and who has been sitting there for an hour waiting to correct our use of a trademark.
If you want more of this, try episode fifty-eight sixteen, Why Linux Still Runs on a one thousand nine hundred eighty-six Mailing List; episode thirty-five, The Privacy Gap; and episode twenty-four thirty-five, The Hidden Difficulty of Data Modeling. This has been My Weird Prompts.
If you want to hear more, it's my weird prompts dot com. And if you've got a topic you want us to take apart, send us your own prompt on Telegram at t dot me slash MWP listener bot. Someone should tell Daniel we've half-decided on Discourse.
We'll be back soon.
