-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not permit the client to send empty messages #195
Conversation
To be fair, these should probably be rejected by the server too.
Is there a reason the client shouldn't be allowed to send empty messages? |
It's very abusable, as enter can be clicked repeatedly. I think this also reflects desktop client behavior. Another thing is that it's easy to send empty messages by accident, for example right after sending a normal one. |
Desktop client allows empty messages. It's on the server to detect and reduce spam, per convention - how bad of a problem is this? |
It appears that KFO-Server currently permits empty messages. It's also a matter of principle. All chat software I know about will not send empty messages. This includes:
I can't come up with a single chat program that permits empty messages. Why should AO, being in essence a chatroom, permit them? I'd also say that there are some usability issues with permitting them, as sometimes you have to spam enter a bit to get your message through (symptoms of deeper issues, but whatever), and may unintentionally send one or more empty messages. |
I guess it doesn't hurt anything. Someone will probably complain, but that's not unusual |
Sadly some roleplay mechanics rely on empty messages |
It seems to be that there are a handful of different use cases here, and that "pure chatroom" might just be one of them. Other use cases include:
While I'm curious as to why, specifically, RP requires completely blank messages, it seems that the different use cases could differ so radically to justify a different ruleset or configuration per area. Some of this is in place already, but it might make sense to expand upon it. Regardless, if it's as you say this probably can't be merged as-is. |
No description provided.