Reaction counts you can trust

A reaction count should not be a private number you simply have to believe. Web Reactions is built around a public trust model: reactions go into a tamper-evident log, checkpoints are published outside the backend, and an open-source verifier can recompute totals from the same public evidence everyone else sees.

Why trust matters for reaction counts

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.

Web Reactions 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. Fake likes and bought followers are an industry, platforms delete fraudulent accounts by the millions, and advertisers lose billions every year to traffic that was never real — 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.

The Web Reactions trust model

  1. You react One tap adds your emoji to a page.
  2. Log entry Your reaction is appended to a public, tamper-evident log.
  3. Signed checkpoint The whole log is regularly summarised into one signed record.
  4. Public anchors Checkpoints are published to GitHub, sealed into Bitcoin, and witnessed by independent logs and archives.
  5. Anyone verifies An open-source tool replays the log and recomputes every count.

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

Web Reactions regularly summarises the whole log into a signed checkpoint and publishes it to a separate public repository, web-reactions-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 on The transparency log.

An open-source verifier

The web-reactions-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.

What verification gives you

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.

Honest about its limits

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 is on The open-source verifier.

A stronger reason to trust public aggregates

Web Reactions 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 transparency log. What the verifier checks, what that proves, and what it can't prove is on The open-source verifier.

Use reaction counts that can be checked

Install Web Reactions to read and leave aggregate emoji reactions on supported pages, with a public verification model behind the numbers.