[GoLUG] Mailing list, long term.

[Kyle Terrien]

On Mon, Aug 11, 2025 at 09:10:41PM -0400, Steve Litt wrote:
> 
> # ALTERNATIVES

You forgot one thing.

## MICROSOFT TEAMS

If you like videoconferencing applications that pick the wrong audio
device when you join a meeting (despite setting your “system
default”), then Teams is for you.  If you like getting a firehose of
notifications on things you don’t care about, then Teams is for you.
If you like locked down conversation threads where you can’t attach
screenshots because “security”, then Teams is for you.

> # WHY NOT STICK WITH EMAIL?
...
> 
> In short, if you remove all the email baggage, client-server software
> implementing a mind meld becomes incredibly simple.
> 
> # MINDMELD DESIGN CONSIDERATIONS
> 
> MindMeld will achieve mind meld without email and all its baggage,
> including email RFCs. MindMeld will be completely orthogonal to email.
> It will be a simple client/server architecture with very few
> dependencies, easily installed by a person with normal intelligence.
> Installation without a distro package will be possible and in fact
> encouraged. 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.

Would some design decisions from USENET help?  They had a store and
forward architecture with threaded messages.

Interesting idea to make MindMeld manage its own bug tracking.
Dogfooding provides motivation to keep the project working well.

> ## LICENSE
> 
> This will be an ultra simple client/server installable by anyone with
> half a brain. I do *not* want corporation X making some sort of walled
> garden community for it like Github did with git (and then Github
> changed the rules). Although I normally favor the Expat license or
> GPLV2, in this situation I want to prevent abuse by private equity
> investors and venture capitalists, so I'll go either GPLV3 or maybe go
> all the way and make it GNU Afero.

Based.

However, if you want iPhone clients, I think GPLv3 code is a problem
on the App Store, because of the “no Tivoization” clause.  (Someone
please correct me if my memory is hazy on this matter.)

I suppose if the spec is simple, an iPhone developer can write his own
implementation from scratch, and GPLv3 doesn’t matter.

> ## SERVER
> 
> The top priority of the server is simplicity and very few dependencies.
> Because I'm not an especially good programmer, I anticipate writing it
> in Go, because from the few hours I've studied Go, it's a reasonably
> easy language and it has what you need to make a fairly effective,
> safe, safely threaded server. Rust is a little too difficult for this
> task, although it might get written in Rust, for ultimate safety, later.

Go is the spiritual successor of Plan 9 C.  That’s why it is good.
There are plenty of standard libraries for writing your own
application protocol on top of TCP, so you don’t need to worry about
arcane socket syscalls from 1980s BSD.  In fact, dial() comes from
Plan 9!  (Plan 9 was basically a 9fs multiplexer.)

Rust fans need to reread the Frederick Brooks essay “No Silver
Bullet”.  I’m sure Rust is good at what it does with its extra memory
protections, but the big sweeping promises are rather suspicious.
There is no panacea.

> The server will handle three or four data pieces:
> 
> - The data store, a tree of all messages for this server.
> 
> - A server config file in MS .ini format. That format sucks, but for a
>   simple application, it's the best of many bad config alternatives. It
>   will include a message size max and various file locations.

If you want to piggy-back off of other things, check out TOML.  TOML
retains a lot of INI-like grammar, but it can still define complete
data structures.

Or if you want data structures without a complex grammar, you can use
a lisp-like config format.

> I plan the datastore's directory structure to look something like this:
> 
> `servername/subgroup/yyyy/mm/dd/sendername`
> 
> Each message consists of one file. The file naming convention will be
> something like the following:
> 
> `sendername_servername_subgroup_yyyy_mm_dd_hh_mm_ss_mm`
> 
> The first mm is month, the second is minute, the third is millisecond.
> The time is time of arrival at the server, no time zones or UTC
> accounted for. Twice a year it screws up. I'll accept that for version
> 0.1, just so the thing gets built at all.

Big idea: if you get nothing else out of this message, please consider
this:

*Mirroring of the archive should be encouraged*, to the point where
the default option should be to “clone” a MindMeld similar to how git
clones the entire history of a repository.  If the entire history is
infeasible to clone, then at least clone a year of it or some
reasonable amount.

The advantage is that a MindMeld automatically receives tens of
backups, and any backup can be used to restore or seed a derivative
MindMeld.  If the MindMeld goes down, someone else can restore it
somewhere else.  If the MindMeld schisms because of irreconcilable
differences, then each party can setup their own MindMelds.

It should be very easy and simple to turn a local MindMeld into a
MindMeld server.

Also, speaking of git, git’s usage of a hash pool as the primary data
storage might be useful.  I.e. each message has a hash, and it can
refer to other messages by hash.  The problem is that hash values
would make the directory and file names horrid.

> The structure of a message file will look something like the following:

You can use the markdown format and make the server collapse
paragraphs into single lines.  Code blocks are either indented or
delimited with ```.

Another possibility is the Gemini document format, which expressly
forbids manual wrapping iirc.

-- 
[*] Kyle Terrien
    Terrenus => from the Earth, to the Cloud
    https://terren.us/

Dilexisti justitiam, et odisti iniquitatem.  -- Psalmus 44:8