Re: [mlmmj] [RFC] Muting and unmuting threads

On Fri, Feb 02, 2024 at 08:24:29AM +0100, Dragan Simic wrote:
> Hello,
> 
> It's well known that people often complain about subscribing
> to high-traffic mailing lists, which results in receiving a lot
> of unwanted messages, etc.  A recent example of such complaints
> came from the git mailing list. [1]
> 
> People often want to receive messages that belong to specific
> threads only, e.g. to those resulting from patches they send to
> the mailing list.  Thus, I was thinking about extending mlmmj
> to support such features, e.g. by implementing new features and
> commands that configure a subscription to receive only replies
> to their own messages sent to the mailing list.
> 
> Has something like this ever already appeared as a suggestion
> or a though?  Any feedback would be much appreciated.
> 
> [1] https://lore.kernel.org/git/[email protected]/T/#m24a25bfc7b9dbe3a7136f5fc2d8a472e0f5f20ce
> 
> 

Hello,

On principle I am not against, as a user I would be a big consumer of such a
feature ;)

The problem is on the implementation side, I haven't given it a long thought
yet, but at first glance, it means we keep track of who sent what so kind of a
database of the threads and who has replied anything on it, which means an
forever growing database, which is something that does not exist by design
in mlmmj, the closest being the archive, but it is not contextual.

The key strength in my opinion of mlmmj is its simplicity, this has a risk to
bring in complexity so it needs to be carefully thought.

If we were to design such a feature in a mlmmj friendly way it would mean:
- a new kind of suscibtion: nomail + exception basically
- each time a mail is sent by someone with the subscrption activated, we need to
  keep track of the thread (a list of message-id ?)
- how long should we keep track of this thread? can we purge somehow this list ?
  (configurable pace for mlmmj-maintd?)

Open for ideas for how to implement this in a stupid and simple way.

Best regards,
Bapt