Hi all, Thanks for the update wrt the MR for issue #1105 (I have also added the news item as suggested for the MR) and for the mailing list procedures, I will be providing full context for all my mails from here on out.
> I don't understand why you think "keeping the Core API intact" is some thing that needs researching. (No reply needed if you agree it actually doesn't.) Earlier, I had been in the early stage of my research and had picked up the user profile tool project idea (as it felt close to the unsubscribing of alternative verified emails issue that I worked on for the MR), this point about the core API is what made me rethink the project choice (about how much backend work was needed etc.) and I think I had either misunderstood the project or thought of something else entirely. 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) I have set up a public draft for my (GSoC) proposal on GitHub pages for your ready reference here (and as was suggested to me as feedback): https://archie-2006.github.io/2026/03/14/Dynamic-Sublists.html I have not currently finalised some aspects of the architecture (and even the time required, as it is stated on the mailman project ideas website for ideas that the time was dynamic and we could ask the mentors if there were any additional functionalities to be added) - 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? - 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, do you suggest that i link the conversation thread 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… - 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. 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. Thank you so much for your time Regards Archie _______________________________________________ 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
