[GoLUG] Mailing list, long term.

[Kyle Terrien]

On Thu, Aug 14, 2025 at 04:59:39PM -0400, Steve Litt wrote:
> 
> On Wed, 13 Aug 2025 20:16:27 -0700
> Kyle Terrien <kyle at terren.us> wrote:
> 
> > 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.
> 
> I think Rust is wonderful, and I could have done it with Rust, but it
> would have been more difficult. Being the least intelligent person I
> know (other than the droobs who buy lottery tickets at the convenience
> store), if easy works, I go easy.

I should have clarified.  It’s not that I don’t like Rust.  (I have
barely scratched the surface of the introductory tutorial.)  Any kind
of promises and sanity checks at compilation time are a good thing.
It’s the way Rust is typically proselytized that bugs me.  Memory
safety fixes one class of problems, but you can guarantee it only
uncovers another class of problems.  (That’s Brooks’s rule.)  Side
note, the fact that you can disable the memory safety in specific
blocks of code demonstrates that there are some problems where memory
safety doesn’t get enough return on investment in programmer time.

> * Anybody can set up their own MindMeld serving out their own
>   directory, but having them be peers instead of one official copy and
>   a bunch of backups introduces problems, race conditions, and
>   opportunities for badguys to contaminate the list. Also, multiple
>   servers of identical data trees creates "confusion in the
>   marketplace", so to speak.

I have to think about that for a bit.  It sounds like the problems are

* Each message would need to be immutable when posted.  I.e., if
  someone tries to modify an existing message, it should raise a red
  flag in the next synchronization.  I think rsync can be configured
  to do that.

* Each message when posted is permanent, so no --delete in the rsync
  options.  While a malicious mirror could delete a message, any
  client can keep it cached, and possibly repost it.

* There needs to be a way for a message to reference an existing
  message in a Reply-To sense.  Once you have that, a client can
  create a threaded view of the messages.  (I’m not sure if mailing
  list thread was the type of user interface you had in mind.)

> * But yes, if person A is running GoLUG's MindMeld and then gets hit by
>   a truck and goes to the great GoLUG chapter in the sky to hack,
>   with Homer Whitaker, Noel Henson and Gary Miller, person B can take
>   over with his copy of the data.

That was the primary case I had in mind.

> If you mean them also forking a group's
>   data and serving it, this would be a very bad idea unless the person
>   currently in charge of serving MindMeld long term failed to keep
>   his/her MindMeld operational.

That’s the political use case, hopefully a scenario that doesn’t
happen often.  However, if an admin goes full tyrant, it’s always nice
to have a safety mechanism so that someone can sneak the data out of
the castle.

> I can't count on users using markdown, and having the client or server
> munge the message by turning it into markdown is a bridge too far.
> > 
> > Another possibility is the Gemini document format, which expressly
> > forbids manual wrapping iirc.
> 
> Like you said, I can't forbid manual wrapping because of source code
> and short-item lists.

The Gemini document format has a simple grammar that includes source
code blocks.  (Also uses the ``` delimiters.)

Here is the spec:

https://geminiprotocol.net/docs/gemtext.gmi

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

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