I added a real-time chat to my blog, people used it to attack me

The author added a floating widget that shows the current number of readers and lets anyone type a short message that is broadcast to all connected browsers. The site runs as a single-page application that renders HTML on the server and keeps a persistent WebSocket connection for each visitor, using that same channel for both the counter and the chat. This architecture makes the live-user count available essentially for free, and extending it to a chat requires only a small amount of additional code.

Once live, the open text box attracted a barrage of hostile content, ranging from profanity and hate speech to impersonations that tried to lure readers to external links. Attackers also posted long strings of characters to push legitimate messages off-screen, especially on mobile devices, and experimented with embedding script tags, which were neutralised because the server escaped all HTML before sending it out. The rapid, broadcast-only nature of the messages meant there was no window for manual review before they reached the audience.

The same server-side escaping that prevented script execution also meant the chat could not be used to deliver malicious code, but it did not stop the social engineering aspects of the attack. Because each message was transient, traditional moderation queues were ineffective; any delay would let the abusive content appear to users. Consequently, the system relied on an automated filter and strict character limits to reduce the attack surface, but these measures trade off user expressiveness for safety.

The author responded by tightening the word filter, cutting the maximum message length, and enforcing a minimum interval between posts, thereby shrinking the amount of ammunition available to attackers. Beyond technical controls, the author emphasised the importance of not reacting to provocations, as engagement fuels the troll's incentive. For engineers, this illustrates that real-time user-generated content demands both robust automated safeguards and operational discipline to avoid amplifying abuse.

The broader lesson is that any public, real-time input channel should be assumed hostile until proven otherwise, and that instant moderation is a fundamentally different problem from moderating stored comments. Building such features incurs hidden costs: development of reliable filters, monitoring of abuse patterns, and the potential need to disable the feature if it becomes a liability. Engineers must weigh these ongoing operational burdens against the perceived user-experience benefits of live interaction.