[GoLUG] Mailing list, long term.

Steve Litt slitt at 444domains.com
Sun Aug 17 13:55:41 EDT 2025


On Sun, 17 Aug 2025 07:35:24 -0700
Syeed Ali <syeedali at syeedali.com> wrote:

> On Mon, 11 Aug 2025 21:10:41 -0400
> Steve Litt <slitt at troubleshooters.com> wrote:
> 
> > Within 2 years I'm going to make a new, better mailing list
> > technology that does what mailing lists should have done all along.
> >  
> 
> I have a lot of reading to do, but what immediately comes to mind is:
> 
> Why?
> 
> Other people have had the same idea, for decades.  Other projects have
> been worked on, by many people and for many years.  Other people have
> run headlong into problems you haven't yet imagined.
> 
> You skipped past the exploration of existing solutions, which should
> at least built a list of bullet points detailing why each project is
> unsuitable.  The very end of that should be one of:
> 
> - Pick one to supply patches
> - Pick one to fork and "improve" (cater to your needs)
> - Build an alternative from scratch
> 
> It feels like you've skipped way ahead.

At this point, allow me to introduce the Litt Principle. After you've
found a bunch of "solutions" that don't meet your needs, the time
arrives where best use of your time is to roll your own.
> 
> After reading a bit more, I do see you're addressing some obvious
> things, I'll comment there.
> 
> ----
> 
> And at the risk of duplicating what others might have already talked
> about downthread...

[snip]

> 
> > In Open Source communications, a mailing list's sole
> > purpose is to foster cooperative thinking, among many people, to
> > grab opportunities and iron out problems. This works very well,
> > because the intelligence of the group far outshines the sum of the
> > intelligences of its individuals. The preceding sentence completely
> > sums up why I'll be creating this new technology.  
> 
> I don't know if that's described well.
> 
> I'd argue that the cooperation of a mailing list was long obsoleted by
> a combination of bug/issue trackers.  The random conversations are
> cool and all, and also available on any number of forum-like tools or
> just IRC-like tools.

But/issue trackers are junk. They're where bugs go to die. Wontfix, low
priority, or just that nobody looks at it. Back when Noel and I ran the
VimOutliner project, we solved problems, usually in a day, on the
mailing list, assisted by everyone else. Bug trackers are a real insult
to the user.

And bug trackers are bad for design. Somebody suggests an improvement
in an issue, and nobody looks at it, and if somebody does, there's no
discussion about the ramifications to the larger community.

I love IRC. You'd have to pry IRC out of my cold, dead hands. But IRC
isn't the same thing. It's a twitteresque 140 character type thing, not
a place where discussions like the one we're having now can take place.

> 
> Email is a nice clean minimal thing that got hijacked by things like
> sending files (attachments of any sort, including web pages) and the
> layers of corporate "anti spam" infrastructure that made it hell to
> support.

Yes. Email mailing lists are good enough if you can find people to
admin them. As such, they can continue until they get too hard to
admin, and I see that day coming. But even email mailing lists have
disadvantages over what I'm suggesting.

 
> 
> > In Open Source communications, the purpose is *not* any of the
> > following:
> > 
> > - CYA.  
> 
> That's what archiving does though right?

No, archiving is archiving. CYA involves top posting with absolutely no
deletions or changes to anything occurring earlier in the thread. It's
great for business, but it sucks for mind melding.

> 
> > - Full conversation archival.  
> 
> Conversations might need to be referenced in the future.
> 
> 
> > - Compatibility with general purpose email.  
> 
> I guess.  It's just what was available/common at the time.

Exactly. It was easy back in the 1990's, and fit right in with
everything else. There was so little spam that in 1996 I used to
celebrate when getting an email, even if it was spam. Those days are
gone, so making mind melding dependent on email is no longer a great
thing. 
> 
> > - Compatibility with RFCs. RFCs are not infallible.  
> 
> RFCs are just a way to wrangle all the different interested parties
> into agreements for project compatibility.

And the one about replying to poster is just plain anti-mind-meld.

> 
> 
> > - Privacy  
> 
> Maybe when the internet was small and everyone used a university email
> address, but now we have people who want to contribute to open source
> projects under real world threatening conditions.

1) Yes, some people are like that. Others recognize that you just don't
   put anything you don't want the FBI and Facebook to know about.

2) Eventually it will have TLS, so real passwords will be possible.


> > Yes really. Worrying about privacy on a mailing list is silly,
> > because most mailing lists have archives anyway. And once the
> > "mailing list" no longer depends on email, you don't need to worry
> > about your email address being seen. As far as your name on the
> > mailing list (jdlspeedy, basketcase, etc), what can they do with
> > it? They can't push any spam to you without pushing it to the
> > MindMeld server, and they can't do that without a password, and
> > they can be blacklisted at the server level.  
> 
> Just sounds like a forum or any other contemporary comms platform to
> me.

Xactly.

 
> > ## FORUMS
> > 
> > Yeah sure, I want to log into each forum every day and go searching
> > for new stuff.  
> 
> Isn't that how humans operate?  Are you asking about an AI-curated
> home page algorithm?  There are places where upvoting help float
> popular topics.

No. You can see any MindMeld you want without logging in, and for
sending you can use a fetchmail-style device to log into every MindMeld
you're interested in joining.


> 
> 
> > ## GOOGLE GROUPS
> > 
> > You have to play by their rules, which are constructed for their
> > profit, not for your benefit. Rules that change constantly. And if
> > you need to move the group elsewhere, your archives are toast.  
> 
> Applicable to anything not self-hosted, and even self-hosted,
> depending...
> 
> If I'm not mistaken, there are some swarm-hosted platforms which would
> resolve these concerns.

The Litt Principle again. How long do I spend beating every corner of
the Internet looking for and researching every last micro-contender
before byteing the bullet and making the right thing?

[snip Linkedin, Facebook, Discourse, Discord, etc]

> > ## ALTERNATIVES: A SUMMARY
> > 
> > If you wonder why, after all these decades, email based mind melds
> > still not only exist but thrive, it's because the alternatives are
> > so ineffective in creating mind melds.  
> 
> I don't think you've examined enough actual software projects.

:-) Your definition of "enough" differs from mine :-)

 
> > # MINDMELD DESIGN CONSIDERATIONS
> > 
> > There will be no "bug tracker", because that's where bugs
> > go to die. Instead, bugs will be discussed on MindMeld itself, with
> > IRC as a backup should MindMeld go down.  
> 
> So instead, bugs will go to MindMeld to die?  

Not at all. Everyone jumps in, helps the user if it's a useage problem,
a fix can be discussed and probably quickly implemented if it's a bug,
and a pros and cons discussion can be done if it's a feature
enhancement request. This is how we worked things no the VimOutliner
mailing list.

> Because you'd have to
> reproduce the functionality of existing ticketing systems to make
> something functionality, and you'd also reproduce the same problems
> with the same sorts of bugs and humans.

I would NEVER subject people to an automated bug tracker or ticketing
system. Impersonal, a hassle when the reporter cannot tell the whole
story, and it adds yet another ticket system user interface the
reporter must learn.

> > - What email mailing lists were supposed to be before they failed
> >   miserably.  
> 
> Maybe I didn't read carefully enough, but I'm confused about the
> project.  Is there also a need for me to use someone else's new
> software to send/receive data? Like, a replacement for my email client
> just for this new concept?

You'd need an additional client. The MindMeld client. In no way does it
replace email, which has its own purposes.

SteveT

Steve Litt 
Spring 2023 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques



More information about the GoLUG mailing list