Reaction counts you can trust

Counts shape what people believe

Public numbers influence attention. A large count can make a post look important, a product look trusted, a repository look popular, or a warning look serious. If those numbers can be silently edited, deleted, padded, or split between audiences, the signal becomes a promise from the platform rather than something users can check.

Emojery treats counts as public claims. If a page says 120 people chose a reaction, the system should leave a trail that lets someone independently test whether that total follows from the log.

The distrust is earned. Bought engagement is an industry, and advertisers lose billions to invalid traffic every year, yet almost none of those public numbers can be checked by the people reading them. That's the gap a verifiable count closes.

Trust should not require special access

Verification should not depend on a private admin panel, a backend export, or a privileged support request. The public verifier is meant to run with the same public inputs available to everyone: the reaction log, signed checkpoints, and the public anchor repository.

A public append-only log

Reaction changes are represented as log entries instead of being treated as invisible edits to a private counter. The log is designed so old history cannot be changed silently: if a past entry is altered or removed, the chain of evidence no longer matches. How the log is built, entry by entry, is on The transparency log.

Checkpoints outside the backend

Emojery regularly summarizes the whole log into a signed checkpoint and publishes it to a separate public repository, emojery-log, with each checkpoint eventually sealed into Bitcoin and mirrored to independent third-party logs and archives we don't operate. That separation makes the latest public history easy to compare with what our servers serve, and impossible for us to quietly rewrite. What a checkpoint contains is spelled out entry by entry.

An open-source verifier

The emojery-verifier project replays the public log, recomputes counts, and checks them against published checkpoints. It is separate from the website and the extension so the checking logic can be inspected on its own. What it checks, and how to run it in one command, is on The open-source verifier.

Protection against silent history changes

Verification does not mean every count is perfect forever. It means changes leave evidence. A count can be recomputed, a checkpoint can be compared, and a mismatch can be detected instead of hidden behind a private dashboard.

Where the proof stops

Verification proves the record, not every claim inside it. When a vote is reversed (account deletion, moderation), the reversal is public and permanent, but math alone cannot prove the stated reason is truthful. What it can do is make quiet abuse hard: reversals cover an account's whole history, your extension keeps a local copy of your own votes, and anyone can watch the public revocation feed. The full breakdown of what it proves sets out the limits in detail.

Could we add votes ourselves?

We run the server, so we can write anything into the database, sign anything with our own keys, and run real browsers with the real extension. Anything that happens between our server and a user's device, we can stage ourselves. Receipts, one-time codes, bot checks, witnesses and anchors protect the history once it is written; none of them stops a vote at the door.

No system can promise the operator will never add a vote: even a government ID can be bought from a real person. The limit is this: adding a vote costs the operator the same as an outsider, leaves the same public traces, and anyone can check that without trusting the operator. That is the limit Emojery is built to.

A vote written straight into the database needs a signing key; the key needs a public permit; the permit needs an account a provider such as Microsoft or Apple vouched for; that vouching is a signature only the provider can produce. Extra permits for accounts we control show up when anyone recounts: more keys than permits, or permits without a vouched account. What remains is opening real provider accounts, one per vote, and enrolling each like everyone else. That costs what it costs anyone, and each account leaves its own public entry in the log.

A stronger reason to trust public aggregates

Emojery intentionally shows aggregate counts rather than public lists of people. That privacy choice works better when the aggregate itself can be checked. The verifier is the bridge: it lets the project avoid exposing identities while still making the count auditable.

Want the full detail?

This page explains the model at a product level. How the record works (the log, the checkpoints, and the public anchors) is on the log page, and what the checking tool covers is on the verifier page. If a term here landed flat, Emojery explained without the jargon restates all of it in everyday words, and the glossary defines each one on its own.