GSoC - First contributions and diving into the codebase

I am Debabrata Mondal, a 19 year old student. I learnt about Jitsi a few days ago from GSoC and I have been using it ever since, trying to understand how it works. I’m very interested in contributing to it.

I went through the handbook and have successfully set up Jitsi Meet on my local machine. I have been going through the issues to see if there’s anything that might help me ease into the codebase and I found this issue:
Message rate-limiter for chat

Is this something that is in the project roadmap and if yes, maybe I can start working on this? I would love to discuss further about this!

I’m not a Jitsi dev so feel free to dismiss my advice.
I don’t think it’s a good idea, because this should be implemented in Prosody, and it’s an independent projet. Jitsi-meet uses it, it extends with modules, but it’s used outside of Jitsi-meet. So if it was a GSOC, it should be a Prosody GSOC.
This functionality could even be of use outside of Jitsi-meet: there is already a Prosodymodule doing something near of this issue, here)
Yes a UI could be added to configure it, but frankly it seems a vast overkill here while configuring a few parameters can be done in Prosody config files. It’s usually the way it is done for Jitsi-meet Prosody extensions.

Thank you for your reply! Just to clarify, I wanted to work on this issue to try and understand the jitsi-meet codebase which would help me with the GSoC project idea (spatial audio) I’m eager to work on.

The mod_muc_limits module somewhat overlaps with this issue but something I noticed is that the limits act on the room as a whole and not on individual participants. What I was thinking was implementing something like YouTube’s Slow Mode during live events where each user can comment once in a set time interval (eg: Only one comment per user allowed in a minute). Moderators on a Jitsi meeting can click on “Enable Slow Mode” and chat messages can then be limited in the client-side application.

Does this seem to make more sense or is it best left with Prosody for handling such things?

Yes I think that the use case is marginal (Youtube is a marginal case, there is only one Youtube and the bulk of Jitsi-meet setups - even including itself - is very small compared to Youtube) - and there is only Github ONE issue for this feature and nobody has come up to comment and say: yes, I want it too !. Ditto in the forum.
The cost of managing an inherently centralized feature in the client seems too high. I am not sure a PR would be considered even if it’s perfect because of the maintenance cost (a lot of PR are ignored or forgotten) .
OTOH Prosody is managing the chat and has a modular architecture. Anyone could bake the feature in a Prosody module without prior approval by the project, test it at a particular deployment, distribute it as open source for inclusion in future versions of Jitsi-meet without having to worry about rebuilding it, and eventually include it in Jitsi meet if it’s popular enough.

I see… Thank you for your inputs. That makes sense.