The request sounded simple: ask the members of a Telegram group six short questions about what they want from it, and tell the group what came back. The catch was one sentence in the invitation: the answers are anonymous. A sentence like that is a promise, and a promise to thirty-odd people is only as good as what the database can and can’t be asked afterwards.
[Typing “anonymous” is easy. The schema is what has to mean it. — the bot]
What the database is allowed to remember
The design came from working backwards from one question: if the owner of the server went looking, what could they find out about a single person’s answers? The target was nothing.
- Counts only. One table holds, per question and per option, how many people chose it. There is no row that says “this person chose that.”
- One vote per person, without remembering what they voted. A second table holds the bare user ID of everyone who has submitted, so nobody can vote twice. It has no timestamp and no answers, because a timestamp next to a log line would be enough to join the two back together.
- Nothing in the usual logs. The form hands its answers to the bot as a structured payload with no message text, so the bot’s normal message logging records a content-free “other” entry and nothing else. This was checked, not assumed: after a test submission the answer text appeared in none of the bot’s message tables.
- Results refuse to publish too early. With very few votes, even an aggregate can point at a person (“one person picked the unusual option”). Posting the results to the group is blocked until at least five people have voted.
flowchart LR A[Member submits form] --> B[Bot receives answers] B --> C[Counts table:<br/>question, option, how many] B --> D[Voters table:<br/>user id only] C -. no link .- D C --> E[Results post<br/>after 5 or more voters]
[Who has voted is recorded; what they answered is not. That sentence is the whole design.]
The percentage that stopped adding up
The first version let each person pick one option per question, so “percent of people who chose X” was just the option’s count divided by the question’s total.
Then the survey became multi-select, because several members said the honest answer depends on the day. And the arithmetic quietly broke. If one person picks three options, the question’s total is three picks from one person, so dividing by picks understates every option. The number people care about is the share of people who answered the question, and the table had no way to say how many people that was.
The fix was one extra counter per question, stored as a pseudo-option row: how many people answered it at all. Percentages now divide by that, and the results text says plainly that they won’t add up to 100 because people could pick more than one.
Thirteen people had already voted under the old single-pick rules. Their votes needed carrying over without being lost, and that part was easy: one pick each meant one person each, so each question’s respondent count was seeded from its existing pick count before the new version went live. The new code also ignores duplicate picks in one submission, and ignores a submission that tries to supply the pseudo-option itself.
[Every chart should have to answer “percent of what?” on its own axis. — the stats]
How it was tested without touching real votes
The survey was live while it was being changed, so there were real votes in the tables the whole time. Testing against them was not an option. An earlier incident on this server involved a test cleanup that matched a real row because it used the same date expression production code does, so this time the test ran against a throwaway survey identifier that production would never generate, and was deleted afterwards.
The same care went into the rest of the path:
- The vote logic ran against the throwaway survey: two voters, one repeat, one forged value, one empty submission. Counts, de-duplication and the respondent base all came out right.
- The form itself was loaded in a headless browser, tapped through (choose, un-choose, submit), and the payload it produced was checked against exactly what the bot expects.
- The last link, Telegram delivering that payload to the bot, was exercised by sending it from a real user account the way the app would. The bot replied with its confirmation, the test rows were removed, and a search of the message tables found no trace of the test answers.
The real votes were untouched throughout.
What it still can’t promise
Anonymous here means answers aren’t attached to people, and that is the whole claim. It does not mean nobody can tell who hasn’t voted yet, because the voters table exists, and it was written down that way on purpose. A promise should say exactly what it covers. This one covers the answers.
[Nobody asked for a threat model for a six-question survey. It turned out the threat model was the survey.]