Thank you so much for explaining this...this has changed how I was thinking about the architecture (and please ignore the mail I sent very recently cause its still me pondering about building this new sqlalchemy database and the new custom handlers (that you told me not to get to ahead with :)) Like I am sure I was overcomplicating the entire model by adding a handler within the pipeline, rather than seeing mailman as a whole.
> If you mean this mailman-developers list, I disagree. Most of the time there's not much activity... your area of interest should be *Mailman in general*. I get it and you are right, a better use case would be some kind of user support lists where users maybe wish to follow some particular troubleshooting thread than core developer lists (as every thing is lowkey interconnected here) > This is wrong way round. You should decide what work is required to > implement the feature in your opinion, and provide a plan to > accomplish it with the time you think is required. Only then if the > time doesn't match GSoC's schedule you should bring that up and > negotiate it. This is my fault, I was working from the gsoc hour targets (very shallow of me) and it def skewed my approach...i will map out all the requirements based on what you have suggested and decide the duration > While I have not thought deeply about this aspect, it seems to me that the sublist concept is a very "shallow" derivative of the list concept. Just a list, where a sublist is recognized in the database by a non-NULL parent id. So, if I am understanding correctly, you mean i should disregard building a new db schema to track the message_id and instead think of dynamic sublists as a mailinglist object in itself with a (parent) id that points to the main list (and the subscription relationship (address id linked to mailinglist) is standard mailman convention). Although, if a sublist is supposed to be dynamic then should this new child mailing list object be produced as soon as someone adds a -follow (assuming addition to email cli) command on a thread...as opposed to an admin having to create it manually? > This has to look a lot like a MailingList so Postorius and HyperKitty can exploit the common features in their respective UIs... So the relation between a sublist and its subscribers pretty much has to be (address, list, subscription configuration). Okay, so to preserve the existing ux patterns, the subscription should be directly linked to the address object within the context of the child list object > I think your model here may be a social network platform's algorithm, > and email just isn't that. Mailing lists are social networks, but the > model is broadcast list traffic to subscribers. And it's single- > channel: the only way to communicate with other subscribers is to send > an email. There are no retweets or quote tweets or likes (OK, there's > some voting in HyperKitty, but I've never seen it mentioned on the > users' list), and the culture strongly discourages that kind of > behavior. Naturally. I was applying the social media model to mailing lists (i just got carried away)...do you think (as stated on the website for proposal ideas) that lookign at the original anitaborg/systers implementation of dynamic sublists built on mm2 (and i do understand that mm2 and mm3 have very different architectural patterns) would help me understand the user experience and email commands to trigger sublists...or should I just think about the command flow (and ux) from scratch for mm3? > I think the answer to that is "it's just handled like a list". understood, considering the sublist is itself a mailing list, it has its own pipeline...so no need to build a custom handler to inject in the main pipeline to do set intersections at all. The standard handler that deals with returning the address ids will pull the addresses subscribed to that child list (if my earlier assumption about child list objects was right) Thank you again for the advice and support On Tue, Mar 17, 2026 at 10:28 PM Stephen J. Turnbull <[email protected]> wrote: > Archie Singh via Mailman-Developers writes: > > > For the *Dynamic Sublists (Conversations) project idea*, it would > > be great to convert mailman into an opt in model from a broadcast > > model (like currently there is some inbox flooding for those > > working on a project idea who are getting conversations of other > > projects, like there should be something for them to opt out of > > some threads based on their area of interest) > > If you mean this mailman-developers list, I disagree. Most of the > time there's not much activity. During GSoC it gets loud, but as a > new developer your area of interest should be *Mailman in general*. > If you don't have at least some interest in "all things Mailman", you > may be applying to the wrong project. (Everybody's different, that's > a generic you, not you in particular.) Among other things, Mailman > really is a single purpose tool, so all the parts interact, and there > are common themes (such as the interface/model relation, the chains > and pipelines, the app lifecycle, etc). The only really distinct > application is HyperKitty, but at least this time there's been limited > interest there, so not creating a lot of noise. > > > I have not currently finalised some aspects of the architecture > > (and even the time required, > > This is wrong way round. You should decide what work is required to > implement the feature in your opinion, and provide a plan to > accomplish it with the time you think is required. Only then if the > time doesn't match GSoC's schedule you should bring that up and > negotiate it. > > > - does the “additional functionality” (for the 350 hour work > > progress) you are referring to involve integrating the web ui via > > hyperkitty and modelling the rest api endpoints while the earlier > > 175 hour implementation only involve core backend? And what > > should I be feasibly aiming for? > > The original Dynamic Sublists feature was entirely controlled by > email, so that is the required part, and involves only core, except > that Postorius should get a list owner option to enable the feature. > Depending on how this is implemented internally, it may have > implications for Postorius and HyperKitty (proliferation of lists in > the list of lists pages, for example). For the base task, if those > seem to be issues that users or admins won't like, documenting them is > good enough. > > The extended functionality, I haven't thought deeply about it, but > some collection of > - collapsing the sublists into the main list in list of lists pages > - configurable filters of sublists (eg, if they're inactive for a > month don't display in list of lists) > - user join or leave sublists in Postorius > - not sure what features you might want in HyperKitty > > I doubt that the extended functionality just mentioned would get you > all the way to 350 hours, that would have to negotiated based on the > proposal. > > > - regarding database modelling, in my proposal i have suggested (a > > new sqlalchemy model) to use a root message-id for each of the > > threads, to track a user’s subscription to that > > thread/conversation, > > I think you are way ahead of yourself. First you need to understand > the mailflows, and think about the user experience (UX). For example, > Mailman 3 core and Postorius don't have threads. Not lightweight > threads linked by In-Reply-To and not sublists (or alternatively > topics). Just messages ... and those are emphemeral, they last a few > hundred microseconds in the queues (except out, where they can sit for > minutes on a big list). > > While I have not thought deeply about this aspect, it seems to me that > the sublist concept is a very "shallow" derivative of the list > concept. Just a list, where a sublist is recognized in the database > by a non-NULL parent id. (This is why I say elsewhere that I see > Dynamic Sublists as creating a tree structure on lists.) > > I would assume that it inherits most of its configuration from the > parent list, except its identities and > > > do you suggest that i link the conversation thread > > It's not a "conversation", nor is it a thread. It's a sublist whose > posts can participate all of the structures that an administrator- > created list does. > > > directly to the user object or the (email) address object (as one > > user can hold multiple addresses although they might be using > > different addresses to start different conversations as a form of > > pseudonym (i thus believe linking threads to addresses is a more > > practical choice)). But I would still want your input on this… > > This has to look a lot like a MailingList so Postorius and HyperKitty > can exploit the common features in their respective UIs, and users get > a sense of familiarity with the new feature. I suggested (VERY > tentatively) above that a sublist could BE a MailingList (with a new > field that all MailingLists would have, or as a very slightly extended > subclass). So the relation between a sublist and its subscribers > pretty much has to be (address, list, subscription configuration). > > > - as the email passes through different handlers, there are many checks > > assuming spam check moderation, recipients (where the email addresses of > > every single person subscribed to the list gets their email addresses > > extracted) etc. although for this project regarding conversations, if > > someone replies to a thread the email should not be going out to all the > > people but only the people who are following this conversation. > > I think your model here may be a social network platform's algorithm, > and email just isn't that. Mailing lists are social networks, but the > model is broadcast list traffic to subscribers. And it's single- > channel: the only way to communicate with other subscribers is to send > an email. There are no retweets or quote tweets or likes (OK, there's > some voting in HyperKitty, but I've never seen it mentioned on the > users' list), and the culture strongly discourages that kind of > behavior. > > > So, there should be a custom handler (to overwrite the recipients > > dictionary) that is injected in the middle of the pipeline; now the > > problem I am thinking of is, if the custom handler is added too > > early it might bypass some safety or spam checks, and if it’s too > > late then the mail would already be sent out…so a consequent > > question arises, is there a preferred stage in the delivery > > pipeline where I should be placing this custom handler? I think it > > should be placed before the handler to_outgoing (which basically > > just takes the email, checks the recipients of the mails dict and > > sends the emails out), this being after all the safety checks have > > passed. > > I think the answer to that is "it's just handled like a list". > > If you're thinking that the membership should be a subset of the > parent list's (not sure I think that's a great idea, but as long as > it's an admin option that defaults "off" you could try it), that would > be implemented at sublist subscription time (and possibly > unsubscription time from the parent list). > > -- > GNU Mailman consultant (installation, migration, customization) > Sirius Open Source https://www.siriusopensource.com/ > Software systems consulting in Europe, North America, and Japan _______________________________________________ Mailman-Developers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
