On Wed, 13 Aug 2025 20:16:27 -0700
Kyle Terrien <kyle at terren.us> wrote:
> On Mon, Aug 11, 2025 at 09:10:41PM -0400, Steve Litt wrote:
> Interesting idea to make MindMeld manage its own bug tracking.
> Dogfooding provides motivation to keep the project working well.
Wait a minute, I wasn't clear. MindMeld will have no backtracker built
in. Instead, each problem that pops up will be discussed and
possibilitied by the group as an informal discussion. That discussion
could have been on IRC or an email mailing list or on (drumroll please)
Microsoft Teams, but since we'll already have MindMeld, the informal
discussion can be held there.
>
> > ## 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.)
LOL, sucks to have an iPhone :-).
> I suppose if the spec is simple, an iPhone developer can write his own
> implementation from scratch, and GPLv3 doesn’t matter.
Kyle, if *I* can write it, you know dang well the spec and design are
going to be simple. Now if you can't put ust a regular application. that
you get from a programmer, on your iPhone, then, like I said, LOL,
sucks to have an iPhone.
By the way, did the preceding sentence break the world's record for
number of commas :-)
>
> > ## 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.)
Good. You agree this was a good choice.
> 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.
>
> > 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.
I'd never heard of TOML, so thanks for the heads-up. I looked it up,
and it looks wonderful, so I might use it. But probably not. Its strict
grammar makes it harder for the user to edit, and the linkage to Python
and Go could produce (TOML) syntax errors where the user's intent was
obvious. And I *sure* hope I don't need something so broadly expressive
to express configuration of what should be very simple applications.
I'll delay the TOML decision for later.
>
> Or if you want data structures without a complex grammar, you can use
> a lisp-like config format.
Oh HECK no, only 10% of the population knows lisp. My name isn't
Stallman.
>
> > 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.
Backups (not necessarily mirrors) are baked into the design, and are
one rsync away. My current plan, in order to keep scrapers from
bringing it to its knees, include the following:
* Set iptables rsync port 873 to accept max 4 connections per IP
* Set iptables rsync port to drop if more than 2 connections/minute
from a specific IP address.
* Have an rsync server password, known by all humans, to serve as a
little bit of security by obscurity, and discourage the less invasive
scrapers, without harming humans who rsync the whole tree.
>
> 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.
* Anybody and everybody can use rsync to update their local copy.
* This rsync command can be done at intervals with cron (or systemd
timers if you drive on that side of the road). If the intervals are 2
hours, your copy will never be more than 2 hours behind.
- Actual instant syncing introduces a lot of complexity for very
little gain, and won't be attempted.
* 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.
* 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.
* As far as setting up their own MindMelds, if you mean something like
setting up their own mailing list for their own group of people, that
will be incredibly simple. 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.
* As far as forking the MindMeld project, the MindMeld distribution
will include a Project Nanifesto that defines what is MindMeld and
what isn't. This will discourage what Barry Fishman so aptly
described as "they spend so much effort on meeting the perceived
needs of users that they don't have, they seem to forget the needs of
users they already have."
>
> It should be very easy and simple to turn a local MindMeld into a
> MindMeld server.
It will be trivial. Download the server tarball, untar, edit a few
lines of mindmeld.conf, make sure the rsync server is installed, add a
couple lines to rsync.conf, modify iptables to let port 873 through and
optionally use iptables to rate limit, and bang, you're done.
>
> 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.
This is the kind of thing I wanted to get away from. I don't care so
much about horrid names, but jumping through git's hoops just to do
this simple task seems suboptimal to me.
>
> > 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 ```.
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.
An observation: It's threads like this one that demonstrate the power of
MindMeld and/or correctly functioning email mailing lists. If Mailman,
Major Domo and ezmlm are dropping the ball, whether it's their fault or
not, then MindMeld becomes very important.
SteveT
Steve Litt
Spring 2023 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques