Look into whether client-to-server packet limiting is necessary

[Trigary]

Minecraft surely has a built-in packet limiter, is a custom one on top of that also necessary? The client can only send 3 types of packets currently: login, gui close and gui change. The first two types can be swiftly dismissed, but the gui change packets can trigger callbacks from other plugins, which might cause issues.

If Minecraft's limiter is deemed not enough, should the packet limit be a configurable global limit or should it be configurable for each gui instance?

[Trigary]

It would seem that Minecraft does not have a built-in packet limiter, but there are plugins for it. eg. Spottedleaf's Packet Limiter. That plugin also catches plugin messaging packets.

I currently believe that a packet limiter built into this Iodine plugin is not necessary: without callbacks, the worst that can happen is a lot of regex checks in the text field gui element. By default no regex checks are applied, so plugins just have to make sure not to make the same mistake as CloudFlare. Callbacks are probably not used to do anything CPU/memory intensive, or if they do, they hopefully require some sort of permission or currency to use; or they do something that can't be spammed, eg. switching to another gui. In the rare cases where packet limiting is necessary, I believe it's fine to leave that up the plugin itself.

I appreciate any input in this matter and my own opinion might change as well, therefore I am going to leave this issue open.