Telegram word filters that do not silence your regulars

A member posts a technical error. Another quotes an unwanted sales pitch to warn the group. A third uses a perfectly ordinary word that happens to contain a banned fragment. All three can look like successful matches to a word filter and bad decisions to the people in the chat.

The useful starting point is a small set of messages you want removed, alongside messages you need to preserve. Choose the matching method against both sets before attaching a penalty. In Defendy, the matching method applies to the whole group; the consequences belong to individual lists. That distinction matters whenever you import entries or change modes.

For profanity, compare this approach with the profanity-filter guide: an everyday language policy needs different test examples from a list of specific promotional phrases.

When testing quotations, distinguish the current message's text from the original being replied to. The rich-message and poll guide explains the extracted surfaces and the ones that need separate checks.

Write the policy before writing the list#

Consider a hypothetical multilingual software community. Members may discuss paid tools and ask for purchasing advice, but unsolicited discount-code promotions are against the rules. Blocking buy, sale and code would suppress part of the community's normal work.

A narrower starting point might be a recurring pitch containing both “buy followers” and “DM me”. These phrases are examples for this article, not a recommended universal spam dictionary. A programming question about code should remain untouched. A warning that quotes the entire pitch needs a human judgment or an agreed way to report it privately.

Before adding an entry, answer three questions:

• Which published rule does this text violate?
• What innocent use of the same words would we allow?
• What should happen when the filter cannot distinguish the two?

If the last answer is “a moderator needs to read it”, a broad automatic ban is a poor fit. You may choose a narrower rule, accept that some cases need manual handling, or give members a reporting route that avoids reposting the complete unwanted text. Put the policy and appeal contact in your group rules.

Understand the three matching methods#

Exact: useful for a particular word#

An ordinary single-word entry matches a whole normalized word. With cat as the teaching example, “the cat is here” matches, while “cats” and “education” do not.

Exact matching is not automatic stemming. A singular form does not silently expand into every plural, tense or inflection. This matters even more when your group uses several languages. Add the relevant forms explicitly or choose a carefully tested alternative.

Multiword entries need extra care. In the current exact mode, a saved phrase is searched as a normalized sequence rather than receiving strict word boundaries around the whole phrase. If phrase boundaries matter, use a quoted phrase in Custom mode, such as "buy followers".

Partial: useful for distinctive fragments#

Partial matching looks for the entry anywhere in the normalized message. An entry such as advert can catch several related words. It also catches any unrelated text containing the same fragment.

For example, cat occurs inside “education”. The letters are present even though no one is discussing cats. Defendy's partial normalization also removes spaces and separators, so fragments can meet across word boundaries. Include harmless multiword messages in your checks, not just a dictionary of individual words.

Use Partial when the fragment is distinctive enough for your actual conversation. Short entries and everyday verbs usually deserve a more careful approach.

Custom: useful when a match needs conditions#

A Custom entry can require more than one piece of text:

"buy followers" && "dm me"

Both phrases must occur somewhere in the same message. They do not have to be adjacent. A message containing only “DM me the error log” does not satisfy that rule.

Custom supports a limited set of operators:

• A && B requires both parts;
• !A excludes messages containing that part; combine it with a positive condition;
• "exact phrase" adds word boundaries around the phrase;
• * stands for zero or more characters;
• + stands for one or more characters;
• ? stands for one character.

This is a mask-and-condition syntax, not an unrestricted regular-expression editor. A regex copied from another bot may become an ineffective literal entry here. Use the stop-word reference for supported syntax.

Negative conditions apply to the entire message. The teaching rule cat* && !cattle* will also spare a message that contains both a cat and cattle. Similarly, adding !not spam to a promotional rule creates an easy escape phrase. Use exclusions for specific, understood false positives; they are not proof that a message is legitimate.

Build a test set with uncomfortable examples#

For the hypothetical promotional rule above, a useful first test sheet looks like this. These are expected matching outcomes, not results from a live Telegram test.

The last row is the important one. A technically correct match can still be an unfair moderation outcome. Decide whether deleting that quotation is acceptable under your reporting policy. If it is not, refine the policy or keep the case out of automatic enforcement. Piling on negative keywords is unlikely to turn text matching into an understanding of intent.

Extend the sheet with accents, names, product terms, mixed scripts, punctuation, repeated spaces and relevant word forms. Include examples in every language your members use. Keep an “observed result” column when you run the test, and record unexplained outcomes instead of treating them as passes.

Similar-looking letters are a separate choice#

Defendy ignores letter case. Its additional letter-substitution setting is off by default and applies across the group's stop-word lists. Enabling it changes how certain Latin letters and letter-like emoji are normalized. It may catch an attempted evasion while also changing how legitimate multilingual text matches.

The maintainers of Rose describe the same broad engineering challenge in their advanced blocklist documentation: normalization does not cover every visually similar character. That is a useful caution, not evidence that the two bots normalize text identically. Do not import Rose syntax or assume its accent handling is Defendy's behavior.

When you toggle substitution, rerun your positive and negative examples. Include the spellings members actually use rather than promising coverage of every Unicode trick.

Organize lists by consequences, not by matching mode#

Defendy provides a default list and up to ten additional named lists. The default list cannot be deleted. Additional lists can be renamed or removed, and entry limits still apply when you import a file.

The group shares its matching method and letter-substitution setting. Each list has its own message-deletion setting, action, duration and warning weight. You cannot make one list Exact and another Partial within the same group.

A hypothetical setup could keep known promotional templates in an “Unsolicited promotions” list with deletion and no member penalty. A separate, carefully reviewed list could issue warnings for a clearly defined repeated rule violation. The distinction should reflect a defensible community policy, not just the administrator's preference for a harsher label.

Avoid duplicate triggers in lists with conflicting penalties. Do not assume the most severe matching list will win or that penalties from every matching list will accumulate. If overlap is unavoidable, test the combined message explicitly before using the configuration.

Configure and test in the Mini App#

Start in a private test group using disposable example messages. Do not experiment with bans on a real member or with content you need to keep.

1. Open @defendy_bot, choose Settings and select the test group. Check its name before editing.
2. Open Stop words and enable the filter. Choose the matching method explicitly; Partial is the initial method, not necessarily the right one for your policy.
3. Open the default list or create a named list for the entries you are testing.
4. Set the member action to None. If you are checking deletion, enable Delete message separately so the test has a visible outcome without imposing a member penalty.
5. Choose Add and confirm the destination list. Enter a few entries manually or import TXT. The importer supports line and comma separators; one rule per line is easier to review when phrases or conditions are involved.
6. Save the add-entry form. Switches and selectors save as you change them; reopen the page to verify the saved values before relying on them.
7. Send the full test set from an ordinary member account without administrator privileges or special exemptions. Check every expected match and every message that should stay.

Importing a file does not bypass the list or plan limits. If a save fails, inspect the error and the actual saved entries before trying again. Seeing a filename in the form does not establish that the words were added.

A group-wide mode change is effectively a change to every existing list. Rerun the old test set as well as the new examples before moving the setting into the real community.

Keep detection tests separate from punishment tests#

None means no member punishment from that list. It does not mean “leave the message alone” when deletion is enabled. Conversely, switching deletion off does not disable a warning, mute or ban that remains selected.

A warning is also not a harmless observation mode. Its weight can take an existing counter over a configured threshold. Review the warning system and the test member's current count before trying warning actions.

Choose a temporary duration explicitly after selecting mute or ban. The stop-word list form has a known display caveat: a missing or zero saved duration can appear as “1 hour”. That label alone is not confirmation of the stored value. Zero can mean an indefinite action, and a temporary mute must last at least 60 seconds. Verify the setting and the actual outcome in the test group; do not assume this interface issue has been fixed.

Once the matching behavior is acceptable, test the intended consequence separately. Then publish the policy, give moderators the examples, and make sure someone owns the appeal route.

Recover from a false positive without losing the lesson#

First prevent another identical mistake. Remove or narrow the offending entry. If the cause is unclear and legitimate conversation is being disrupted, temporarily disable the stop-word filter while you investigate. Turning off only message deletion will not stop a configured member penalty.

Identify the message text, matching entry, list, group-wide mode, substitution setting and consequence. A moderation log can help if logging was enabled and the relevant event category was selected. An absent log record does not prove this filter did nothing; consider other filters and bots too.

Correct the member's warning, mute or ban separately using the appropriate moderation controls. Fixing the list does not undo an existing sanction or restore the original deleted message. Ask the member to repost useful content after you have corrected the rule.

Add the incident to the permanent negative test set. That turns an appeal into a check you can rerun before the next import, mode change or stricter action. A well-maintained list earns its place by making predictable decisions, not by containing the largest number of words.

Sources and scope#

Defendy's settings, list limits and matching implementation were checked on 5 October 2026. Field-level details are in the stop-word guide. The published maintainer reference is Rose: Advanced Blocklist Features, checked on the same date. The scenarios and test messages here are hypothetical; they do not establish the behavior of your deployed group without verification.