A global, cross-site review substrate where every rating is weighted by **the observer's** trust graph, not by an average that treats every reviewer as identical. Reviewer identity is portable; reputation is per-vertical; sites and revie…
A global, cross-site review substrate where every rating is
weighted by the observer’s trust graph, not by an
average that treats every reviewer as identical. Reviewer
identity is portable; reputation is per-vertical; sites and
reviewers stake real-world skin in the game through
DNS-anchored validation.
This dossier is the strategic and market-facing case for
trust-weighted reviews. The QRP-0001 wire protocol, the
reference rating algorithm, the multi-actor simulation, and
the running demo all live in
examples/reviews-and-comments/.
1. The problem
Every review system on the open web in 2026 uses a model that
the underlying market structure makes impossible to fix:
One rating per entity. “4.3 stars, globally, for everyone”
is the only output shape the platform sells.
All reviewers weighted equally. A bot-net farm’s review
counts the same as a credentialed food critic’s.
Helpfulness votes don’t propagate. Upvoting a helpful
review does nothing for that reviewer’s next review on a
different site.
No topical specialization. A brilliant software reviewer
has no baseline credibility on restaurants.
Reputation resets at every site. Your Amazon history
doesn’t carry to Walmart, Yelp doesn’t help on Google Maps,
TripAdvisor vanishes at Hotels.com.
The platform owns the only copy. Reviews can be removed,
re-ranked, or quietly de-weighted to please advertisers, and
the reviewer has no enforcement.
These are not bugs. They are the direct consequence of
“one average score fits all,” baked into every review UI since
the 1990s, layered on a market structure where the platform’s
incentive to police fraud is weaker than the seller’s incentive
to commit it.
Sizing the harm
The US FTC’s 2024 review-fraud rule estimates fake reviews
influence roughly $152B in annual US purchasing. Per-violation
penalties run up to $51,744.
Amazon disclosed in court filings that ~30% of its review
reservoir is suspect at any given moment; Amazon sued >10,000
fake-review-broker groups in 2022-2023 alone.
Independent audits of Google Maps reviews on competitive
verticals (lawyers, dentists, tourist-zone restaurants)
show 15-40% paid or coerced reviews.
“Brushing” (sending empty boxes to fake addresses to forge
verified-purchase labels) is a multi-billion-dollar global
industry per FTC and Reuters reporting.
Yelp has been sued repeatedly by small businesses alleging
filter-driven extortion of advertising spend.
The fraud is a tax that consumers, honest sellers, and
platform employees all pay, but only the platforms are in a
position to fix it, and their gradient of profit points
toward the broken state.
2. The seven attack patterns
Stable, well-documented, all priced into the current market:
Click-farm sybils. Aged accounts at $0.50-$3 each on
the gray market, residential proxies for IP rotation,
industrial-scale review-as-a-service.
Brushing. Seller ships empty packages to fake addresses
so the receiving “buyer” can post a “verified purchase”
five-star review. Verified-purchase is the primary
credibility signal on Amazon; gaming it is the highest-ROI
attack.
Review-trade networks. Closed groups (Facebook, Telegram,
Discord) where sellers swap five-star reviews on each
other’s products. Real human reviewers, real low-cost
purchases, very hard to detect.
Incentivized review schemes. Insert-card schemes
(“review us on Amazon for a $20 gift card”) inducing
reviews outside the platform’s audit pipeline.
Brigading. Coordinated negative-review attacks driven by
politics, competition, or viral grievance. The averaging
algorithm offers no defense; one weekend can permanently
move a 4.6 to a 3.2.
Suppression. Defamation suits and DMCA strikes against
negative reviewers; documented patterns of platforms
de-ranking negatives of paying advertisers. The reviewer
has no permanent record because the platform owns the
only copy.
Generative-AI flooding. GPT-class models produce reviews
indistinguishable from human prose. The economic floor of
fake reviews is now near zero. Any defense based on “this
reads like real text” is dead.
3. What Quidnug changes mechanically
Five structural changes, not one new feature:
Per-observer weighting. No “global rating.” Two readers
loading the same product see two different numbers, both
honest from their own viewpoints. The platform cannot
publish a single average because no single average exists.
Topical trust scoping. Trust edges are scoped to domains
like reviews.public.technology.cameras. Trust on cameras
does not bleed into trust on restaurants. Reputation is
built per-vertical, the way real-world expertise is.
Decayed transitive trust. If you don’t know Alice but
you trust Bob, and Bob trusts Alice on this topic, her
review counts at a per-hop decayed weight (default 0.8 per
hop). Delegate vetting; don’t repeat it.
Helpfulness votes that propagate. A HELPFUL_VOTE is
itself a signed event, scoped to a topic, by an identity
with its own trust weight. Ten votes from observers you
transitively trust mean something; ten votes from new
accounts don’t.
Append-only signed events. No platform can edit, delete,
or quietly de-rank your review or your helpful-vote
retroactively. The platform is a viewport; events live on
the public Quidnug network.
The combined effect is not “fraud goes to zero.” It is
the economic floor for credible fraud rises sharply. Faking
a review that affects a knowledgeable observer requires a
real cryptographic identity, real trust edges from real
reviewers in the target topic, and consistent quality not to
be flagged out. That cost structure is not what the
fake-review market is built around today.
4. How the public network actually works without a central authority
Three nested layers. Each is independent.
Layer 1: protocol substrate
The public Quidnug network of seed nodes (initially a home +
VPS pair operated by Quidnug LLC, expandable through bilateral
peering per QDP-0013) gossips signed events under the
reviews.public.* domain tree. Defined by QDP-0001 through
QDP-0024. Anyone can run a node, anyone can read, only domain
validators can produce blocks for that domain.
Deterministic computation of product Title quids so the same
physical product gets the same Quidnug Title regardless of
which site registers it first.
Inheritance and decay rules for trust across the topic tree.
Layer 3: per-observer rating algorithms
Multiple are possible. The reference algorithm is in
../../examples/reviews-and-comments/algorithm.py.
Sites differentiate at this layer. Two sites loading the same
product can show subtly different ratings to the same observer
if they parameterize the algorithm differently (recency
weighting, hop decay, helpfulness coefficient). The algorithm
is the editorial voice of the site, layered on shared raw
data.
Governance without a central authority
Per QDP-0012 (Domain Governance), each domain has:
A consortium of validators (initially Quidnug LLC’s two seed
nodes; expandable through QDP-0013 federation).
A governor set (the operator plus delegated co-governors).
A governance quorum threshold for adding new top-level
topics or rotating validators.
This is the same model DNS uses: ICANN-governed roots delegate
to TLD operators who delegate to registrars. Quidnug’s review
tree has the same structure but is enforceable by signature
rather than by central registry. If another operator runs a
parallel reviews.public.* tree (federation per QDP-0013),
the two trees can cross-sign; reviewers don’t pick a network,
their quid spans all of them.
5. DNS-anchored validation as the credibility floor
This is what binds cryptographic identity to legal
accountability. It is also the commercial product Quidnug LLC
sells (see the service-api and pricing docs).
Sites that host reviews
A site validates acmestore.com through Quidnug Pro
($19/month) or Business ($99/month with KYB). The validation
Worker (per the service API spec) publishes a TRUST edge from
operators.acmestore.com.network.quidnug.com to the site’s
quid. Now:
Review embeds and PURCHASE attestations from acmestore.com
carry verifiable accountability: observers know the events
came from the legally accountable owner of acmestore.com.
Sites with Business-tier KYB carry stronger attestations:
Quidnug verified the legal entity. Their review embeds and
TRUST edges they issue to their own customers carry more
weight in observer rating computations.
Sites that don’t validate can still host reviews; observers
may discount them.
Reviewers who go pro
Alice the food critic registers alice-eats.com, validates
through Quidnug Pro, and the validation Worker publishes a
TRUST edge from the operator root to her reviewer quid under
operators.alice-eats.com.network.quidnug.com. Now:
Anyone reading Alice’s reviews can verify her quid is owned
by the legal owner of alice-eats.com.
Alice’s reviewer card in the widget shows “alice-eats.com,
Pro tier, validated YYYY-MM-DD, KYB verified, 247 reviews
in reviews.public.restaurants, helpfulness ratio 0.87.”
If Alice lies about credentials, she can be sued under her
real name. Her domain is a costly, persistent identity
bond.
Lose the domain (failed renewal, lost dispute, failed KYB
rerun), and the validation edge auto-revokes (TRUST level
drops to 0). Old quid’s accumulated rep no longer points to
a verifiable identity.
The compounding effect: dense, signed reputation graphs of
validated reviewers become navigable by observers. Subscribe
to one curator (a Wirecutter-equivalent), inherit transitive
trust in hundreds of reviewers. None of this requires the
curator to own the platform; the platform layer is the public
network.
6. New economic roles
The current market has two roles: platforms that monetize the
substrate, and unpaid reviewers. Trust-weighted reviews on a
public substrate enables roles that don’t exist now.
Professional trusted reviewer
A real job. The mechanics:
Validate a personal domain through Quidnug ($19-$99/month).
Build vertical reputation through consistent work in
reviews.public.<vertical>.
The reviewer doesn’t depend on any single platform. Their quid
signs reviews everywhere. The compound: reputation accrues
across all sites that read the same network.
Comparable analogues to estimate market size: Substack’s paid
newsletters cleared >$1B/yr in writer payouts within five
years of launch. YouTube’s creator economy is >$20B/yr in ads
and sponsorships. Reviewers as a category are at least as
large; they just don’t have the substrate today.
Trusted-reviewer aggregator
Wirecutter/Consumer Reports as a Quidnug-native business.
Curate 50 vetted reviewers, validate the curating site, issue
TRUST edges to the reviewers. Sell subscriptions to consumers
who inherit the curation. The aggregator is selling editorial
trust as a service with cryptographic provenance.
Reviewer guild or co-op
Members of members.foodcritics.coop validate the guild
domain and issue TRUST edges to dues-paying members. This is a
credentialing body. Members who lose the guild’s trust have
their edge revoked publicly. This is the bar association
pattern, applied to review work.
Brand-disclosure marketplace
A brand posts: “We will pay $X to N reviewers with rep > 0.7
in reviews.public.tech.cameras who will write an honest
review of product Y with mandatory DISCLOSURE event.”
Reviewers bid; brand picks; disclosure is on-chain. Observers
can filter or weight sponsored reviews. Both sides get
something the current market can’t deliver: real reviewers
who can’t lie about being unsponsored, and brands who get
exposure to skeptical audiences without paying for ads they
know are filtered.
Auditor / fraud hunter
Specializes in detecting review-trade networks, brushing
patterns, AI-generated review clusters. Publishes signed FLAG
events. Sites’ Trust & Safety teams subscribe; foundations
fund. The role exists today inside platforms with no
externalization path; trust-weighted reviews makes it a
market.
Expert testimony
A reviewer with 5 years of consistently helpful reviews in
reviews.public.medical-devices is now hireable as an expert
witness or consultant. Their public history is auditable;
their identity is verifiable. This use case doesn’t exist
because today’s reputations are not portable, persistent, or
verifiable enough.
7. Why this is now possible
Three preconditions just lined up:
Cryptographic identity at scale is solved. Modern
browsers ship WebCrypto; key management UX (passkeys,
browser extensions, mobile keychains) is mainstream as of
2024-2025.
DNS-anchored validation is cheap and fast. Cloudflare,
Google, Quad9, OpenDNS resolvers via DoH let any HTTP
service do a four-resolver quorum probe in <500ms. The
pattern is proven by ACME (Let’s Encrypt) at internet
scale.
Generative AI broke the old defense. Pre-2023, “this
reads like real prose” was a credibility signal. Post-2023,
it isn’t. Identity-bound reputation is the only defense
that scales, and that requires substrate the platform
doesn’t own.
8. Adoption path
Three audiences in priority order:
Phase 1, weeks 1-8 from network launch
First reviewers (10-50 known professionals across two or
three verticals: tech, food, books). Validate them at
Quidnug Pro free for the first year as seed-trust. Each one
gets a TRUST edge from the operator root and seeds their
vertical.
Aggregator partners (1-3 publications). Wirecutter
competitors, niche-vertical bloggers, podcast review shows.
Same free year. Their endorsement of reviewers seeds the
graph.
Phase 2, weeks 8-24
Indie e-commerce sites and SaaS marketplaces install the
WordPress / Shopify / web-component widgets. Validate at Pro
tier. Their PURCHASE attestations become the verified-purchase
signal that doesn’t depend on any platform.
Browser extension overlay ships, allowing observers to
see Quidnug-weighted ratings on Amazon, Yelp, Google Maps,
TripAdvisor product pages. The overlay reads from
reviews.public.* and re-ranks the existing site’s reviews
by observer trust. This is the wedge: consumers see the
difference without sites needing to integrate.
Phase 3, months 6-18
Major retailers integrate at the platform level. By this
point the network is dense enough that the marginal
retailer who refuses looks like the holdout, not the
default.
Regulatory tailwind. FTC and EU consumer-protection
rules increasingly demand verifiable review provenance;
Quidnug’s signed-event substrate is the lowest-friction
compliance path.
Phase 4, year 2+
Cross-vertical expansion into healthcare reviews
(paired with FHIR integration per integrations/fhir/),
professional services, education credentials.
International federation. Operators in EU, APAC run
parallel networks under QDP-0013 federation; reputations
cross at controlled discount.
System design for trust-weighted reviews on Quidnug, with
DNS-anchored validation as the credibility floor for both
sites and reviewers. Companion to
README.md (market case) and
implementation.md (code paths).
Each layer is independent. Layer 1 is run by Quidnug LLC and
federated peers (QDP-0013). Layer 2 is a versioned spec.
Layer 3 is where sites and aggregators differentiate. Layer 4
is anyone who reads or writes.
2. Identities
Three quid types interact in the reviews ecosystem:
Quid type
What it is
Real-world bond
Reviewer quid
A reviewer’s signing identity
Optional: validated personal domain (Pro/Business)
Site quid
A platform that hosts review embeds
Required to issue PURCHASE: validated site domain
Product Title
A reviewable thing (laptop, restaurant, book)
Deterministic from canonical identifiers (ASIN etc.)
Operator quid
A validated entity issuing TRUST edges to others
Required: validated domain plus optional KYB
Validation-operator quid
Quidnug LLC’s signing identity for validation TRUST edges
Subordinate to seed root
A reviewer can also be an operator (Alice issues TRUST edges
to other food critics). A site can also be a reviewer (the
official acmestore.com account writes reviews). All four
types use the same Quidnug quid primitive; the role is
contextual.
Trust is scoped to the leaf domain. A 0.9 trust in
reviews.public.restaurants.us.ny.nyc does not propagate
to reviews.public.technology.
Inheritance: a parent-domain trust edge inherits to
children at decay 0.8 per hop. Trust at
reviews.public.technology 0.9 → 0.72 at
reviews.public.technology.laptops by default.
Override: an explicit child-domain edge supersedes
inheritance.
Sibling extensions: sites can run private siblings
(reviews.privatestore.acmestore.com) for internal review
flows that don’t pollute the public graph.
4. Event flow: writing a review
Alice's browser Quidnug network
─────────────── ────────────────
│
│ 1. Alice loads acmestore.com/p/12345
│
▼
┌─────────┐
│ <quidnug-│
│ review> │
│ widget │
└─────┬────┘
│ 2. Widget asks browser ext./wallet for Alice's quid
The widget never talks directly to acmestore.com’s database.
The review goes to the public network, not the site.
The site can later query the network and render Alice’s
review, but it cannot edit it.
Helpfulness votes from any other site land in the same
event stream and accrue to Alice’s reviewer reputation.
5. Event flow: rendering a per-observer rating
Bob's browser Quidnug network
───────────── ────────────────
│
│ 1. Bob loads acmestore.com/p/12345
│
▼
┌─────────┐
│ <quidnug-│
│ review> │
│ widget │
└─────┬────┘
│ 2. Resolve product Title from canonical IDs
│
▼
┌──────────────────────────────────────────┐
│ GET api.quidnug.com/api/streams/ │
│ <product-title>/events?type=REVIEW │
│ &type=HELPFUL_VOTE&type=FLAG& │
│ limit=N │
└──────────────┬───────────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ Get Bob's outgoing TRUST edges in this │
│ topic (from his wallet local cache or │
│ from the network): │
│ GET api.quidnug.com/api/trust/<bob>? │
│ domain=reviews.public.tech.laptops │
└──────────────┬───────────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ Run rating algorithm (algorithm.py): │
│ - For each REVIEW, compute reviewer's │
│ effective trust from Bob's view │
│ (direct edge, or transitive at 0.8/hop)│
│ - Weight by HELPFUL_VOTE flow from │
│ trusted observers │
│ - De-weight if FLAG events from trusted │
│ moderators │
│ - Apply recency decay │
│ - Sum, normalize │
│ → Bob's effective rating: 4.1 │
└──────────────┬───────────────────────────┘
│
▼
Renders 4.1 ⭐ to Bob;
Carol on the same page sees 3.7;
an anonymous visitor sees 3.9 (no observer trust);
all three are honest from their viewpoint.
The same product Title with the same event stream produces
three different ratings for three observers. None is the
“correct” one; each is correct from its observer’s frame.
6. DNS-anchored validation flow
The validation Worker (service.quidnug.com, see service-API
spec) is what binds quids to real-world domains. Two flows:
6.1 Site validation flow
1. acmestore.com signs up at quidnug.com/pricing → Stripe
8. Worker writes Attestation bundle to R2; emails customer
with API key + console link + attestation download.
9. Cron re-probes every 1 hour (Pro). On 4-hour grace
drop: TRUST level=0.0 superseding edge published.
6.2 Reviewer validation flow
Same mechanics, different intent. Alice the food critic
validates alice-eats.com at Pro tier. She gets the same
TRUST edge. But because she also signs reviews from
alice-eats.com’s quid (hopefully the same as her reviewer
quid for clarity), the rendering widget can show:
Alice (alice-eats.com) ✓ Pro-validated, KYB verified
247 reviews in reviews.public.restaurants
helpfulness ratio 0.87 • active 4 days ago
The validation edge composes with her reviewer trust graph.
Observers who don’t directly know Alice but trust the
operator root inherit a low (0.2 default) transitive baseline
in her favor. Observers who follow her (direct edge at e.g.
0.85) override that baseline.
OIDC bridge (lowest friction). New user signs in with
Google/GitHub/Apple at auth.quidnug.com. The bridge
mints them a quid bound to their verified email and issues
a baseline TRUST edge from operators.network.quidnug.com
at 0.2. They’re now visible to anyone who trusts the
operator root.
Cross-site import. An existing Amazon/Yelp reviewer
requests an attestation from a domain operator (e.g., a
reviewer guild) that vouches for their off-Quidnug history.
The operator publishes a TRUST edge.
Social bootstrap. Friends-and-family seed: founders,
beta testers, known reviewers cross-trust each other. This
is enough for the first few dozen users before OIDC
bootstrap takes over.
The OIDC bridge is the production engine; #2 and #3 are seed
material.
9. Federation (QDP-0013)
The single-operator network (Quidnug LLC running two seeds)
is a starting point. As soon as a second serious operator
wants to participate, federation kicks in:
Operator B runs their own reviews.public.* parallel tree.
A and B publish bilateral TRUST edges in
peering.network.quidnug.com and
validators.network.quidnug.com.
Reviewer quids span both networks; reviews flow bidirectionally
at a controlled discount (0.8 per cross-network hop, tunable).
This means there is no single-point-of-failure at the
governance layer. If Quidnug LLC misbehaves, operators
defederate; reviewer reputations survive on the operators they
remain peered with.
10. Sharding (QDP-0014)
For volume scaling: when one topic accrues > N events/day, it
shards into child topics. The sharding model and discovery
protocol are in QDP-0014. Practically, this means the
substrate scales horizontally; observers and sites need only
discover which seeds carry which shards.
11. What this architecture enables
A platform-independent review market. Sites become
viewports. Reviewers become portable professionals.
Verifiable provenance for SEO and compliance. Schema.org
Review JSON-LD is generated from signed events, so search
engines (and regulators) get cryptographic provenance for
free.
Audit trails for litigation. A defamation suit can
demonstrate (with cryptographic proof) the reviewer’s
signed event, timestamp, and any subsequent edits or
retractions.
Cross-domain reputation flows. Healthcare reviews,
professional credentials, product reviews, expert testimony
all live on the same substrate. A doctor’s medical-device
review reputation composes with their FHIR credential.
12. What this architecture does not solve
Honest about residual limits:
Observer initialization. A user with no trust edges sees
no opinionated scores; they see the “anonymous baseline”
(operator-rooted weighting). This is honest but
underwhelming on day one for that user. The OIDC bridge
partially addresses this; full personalization requires the
user to interact (follow some reviewers, vote helpful).
Privacy of reviews. Reviews are public events. A
reviewer’s history is fully visible. This is a feature for
professional reviewers, a bug for anonymous reviewers. QRP
may add anonymous-ballot extensions later (QDP-0021 blind
signatures, QDP-0024 group encryption); not in v1.
Subjective taste. Trust-weighting helps with credibility,
not with “is this restaurant’s cuisine my style.” That’s
matchmaking, not authentication; it’s a separate problem.
Regulatory edge cases. Defamation, GDPR right-to-erasure,
DMCA: append-only protocols cannot delete. The mitigations
are operator-level non-gossip per QDP-0015 (content
moderation) and QDP-0017 (data subject rights). Operators
who choose to honor takedown requests render the content
unreachable through their nodes; other operators may continue
serving. Publish your moderation policy before launching.
Three visualization primitives (aurora = single rating,
constellation = drilldown of contributors, trace = audit path
showing which trust edges matter most) plus a write-review
form.
# - Default category: reviews.public.products (or set per-product)
# - Site quid: (paste from Quidnug console after validating site domain)
# - Site key: (paste from Quidnug console)
Per-product overrides via a WooCommerce custom field. The
plugin renders the reviews block automatically on product
pages, replacing or augmenting the built-in WooCommerce
reviews UI.
For a site that’s already Quidnug-validated (Pro/Business
tier through service.quidnug.com), the plugin can also
issue PURCHASE attestations on completed orders so reviews
from buyers carry verified-purchase status.
6. Pattern 5: browser-extension overlay
The observer-side wedge. Doesn’t require any site to
integrate; runs entirely in the consumer’s browser.
Detects product pages on Amazon, Yelp, Google Maps,
TripAdvisor, Booking, etc.
Extracts canonical identifiers (ASIN from URL, business
name + address from page).
Computes the Quidnug product Title.
Fetches REVIEW events from api.quidnug.com.
Renders a side panel showing the per-observer trust-weighted
rating, plus diff against the host site’s average.
Optionally lets the observer write a review (signed by their
wallet quid) without leaving the page.
This is the consumer-facing wedge: people see the difference
without sites needing to integrate.
7. Reviewer wallet (signing identity)
The wallet holds the reviewer’s quid and signs events.
Implementations:
Browser extension (clients/wallet-extension/): primary
for desktop reviewers. Manages keys, prompts for
signature on each review.
Mobile app (clients/mobile-wallet/ planned): for
in-store / restaurant review writing on phones.
Hosted wallet via OIDC bridge: lowest friction. Reviewer
signs in with Google/GitHub at auth.quidnug.com; the
bridge holds a custodial key. Trade-off: convenience vs.
custody. Pro reviewers should self-custody; casual reviewers
use the bridge.
Key recovery for self-custody: guardians (QDP-0002), 3-of-5
default with a 24-hour time-lock. Wallet prompts the user
through guardian setup at first launch.
8. Site validation: the Quidnug Pro/Business signup flow
This is what your service-api Worker provides (see service-api
spec). For a site operator like acmestore.com:
Same Worker, slightly different messaging on the front end.
For Alice the food critic:
1. Visit quidnug.com/professional-reviewer (or just /pricing).
2. Stripe Checkout, Pro tier.
3. In console, Alice adds her domain alice-eats.com.
4. Same DNS challenge → resolver quorum → TRUST edge.
5. After validation, Alice's reviewer card in widgets shows:
"alice-eats.com ✓ Pro-validated YYYY-MM-DD"
6. She can now claim ownership of her existing reviewer quid:
POST /v1/reviewer/claim with a signature from her quid
over a challenge from the Worker. The Worker publishes a
second TRUST edge from her validated alice-eats.com customer
quid → her existing reviewer quid in
reviews.public.restaurants. This binds the two together
on-chain.
7. Optional: Alice upgrades to Business ($99/mo) and goes
through KYB via Stripe Identity. Once approved, the Worker
re-signs her edge at level 0.95 and her reviewer card adds
"KYB verified."
This is the same product, sold to a different buyer.
10. OIDC bridge for low-friction reviewer onboarding
For consumers who don’t want to install a wallet extension or
buy a domain. Lives at auth.quidnug.com, separate Worker /
service. Implementation:
Standard OIDC OP supporting Google, GitHub, Apple,
Microsoft.
On first sign-in: derive a deterministic quid from the
hash of provider_subject_id + email + AUTH_BRIDGE_SALT.
Generate a custodial signing key, hold it server-side
encrypted-at-rest.
Issue a TRUST edge from operators.network.quidnug.com to
the new quid at level 0.2 (configurable) in
reviews.public.* (or a list of subdomains the user
selects on first sign-in).
Provide a JSON-RPC signing API the widgets can hit when the
user is logged in: “sign this REVIEW event for me.”
Support graduation: a custodial user can upgrade to
self-custody by providing a public key from a wallet
extension; the bridge issues a TRUST edge from the
custodial quid → the new self-custody quid at level 1.0
and stops signing on behalf of the user.
The trade-off is custody-vs-friction, made visible to users.
11. Schema.org JSON-LD interop for SEO
Search engines (Google, Bing, DuckDuckGo) reward structured
review data with rich-result cards. Quidnug’s integrations/ schema-org/ package generates valid JSON-LD from QRP events:
<!-- emitted server-side by the Astro adapter or WP plugin -->
<scripttype="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Example Brand XPS 15 9530",
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.3",
"reviewCount": 247,
"bestRating": "5",
"worstRating": "1"
},
"review": [
{
"@type": "Review",
"author": { "@type": "Person",
"name": "alice-eats.com",
"url": "https://alice-eats.com" },
"datePublished": "2026-04-12",
"reviewBody": "...",
"reviewRating": {
"@type": "Rating",
"ratingValue": "4.5",
"bestRating": "5"
}
}
]
}
</script>
The aggregateRating uses the anonymous-observer rating
(operator-rooted, no observer trust graph), so the search-
engine rich-result is consistent across observers. The
per-observer rating is rendered client-side over the top
when the observer’s wallet is detected.
The package also goes the other way: importing existing
Schema.org Review JSON-LD from sites that have it (e.g.,
Schema.org-marked WordPress sites) into Quidnug events,
preserving the original timestamps and authorship where
identifiable. This supports cross-site reputation import for
established reviewers.
The Amazon “verified purchase” badge is the highest-value
signal in current review systems and the most-attacked. QRP-
0001 specifies a PURCHASE event signed by the seller’s quid:
Sites that are Pro/Business validated through Quidnug carry
non-trivial weight when issuing PURCHASE attestations. Sites
that aren’t validated can still issue them but observers may
discount them. Brushing (the empty-box attack) is harder
because it requires either a Pro/Business validated seller
willing to sign fraudulent PURCHASE events (and risk losing
their validation) or an unvalidated seller whose attestations
carry near-zero weight.
13. End-to-end test checklist
For an integrator validating their setup:
Widget loads and renders without console errors.
Anonymous observer sees a baseline rating that matches
the operator-rooted computation in algorithm.py.
Logged-in observer (with wallet) sees a different rating
that matches their trust-graph-weighted computation.
Posting a review from the widget produces a signed event
visible at api.quidnug.com/api/streams/<reviewer>/events.
Helpfulness vote on an existing review produces a
HELPFUL_VOTE event visible in the same stream.
PURCHASE attestation flow works for validated sites.
Schema.org JSON-LD is present in HTML source and
validates against Google Rich Results Test.
Browser extension overlay displays correctly on
Amazon/Yelp test pages.
Domain validation flow completes end-to-end (DNS
challenge → quorum → TRUST edge visible at
api.quidnug.com/api/trust/<truster>/<trustee>?domain=...).
14. Migration from existing review systems
For a site with an existing review database:
Map the site’s product IDs to canonical Schema.org
identifiers (ASIN/UPC/EAN/ISBN). The deterministic
product Title quid follows.
For each reviewer email, run the OIDC bridge offline (or
ask reviewers to sign in once) to mint quids.
Bulk-import reviews via a one-time CLI: each review becomes
a REVIEW event signed by the imported reviewer’s quid,
with the original timestamp preserved (sequence numbers
reordered by timestamp). Mark them with an
imported_from: "<site-domain>" attribute so observers
can choose to weight imports differently.
Publish TRUST edges from the importing site’s validated
domain to the imported reviewers at a baseline level
(e.g., 0.4) reflecting partial known-good status.
Run the existing system in parallel for 30-90 days; cut
over once new reviews are flowing primarily through the
Quidnug widget.
This pattern lets a Yelp or Amazon-class site preserve their
existing reviewer corpus while migrating to the new substrate
and giving reviewers portable identity going forward.
Threat model
Adversaries, assumed capabilities, mitigations.
Threat model: trust-weighted reviews
Catalog of attacks on trust-weighted reviews: the seven
classic gaming patterns from existing systems plus
Quidnug-specific adversaries. For each: mechanism, mitigation,
residual risk. Companion to README.md,
architecture.md, and
implementation.md.
1. Threat-model framing
Three adversary classes:
A1: Sybil-class spammer. Cheap volume, no real-world
identity. Buys aged accounts, rotates IPs, generates
reviews with LLMs.
A2: Insider-class actor. Legitimate participant who
abuses position: a seller running review-trade rings, a
validated site issuing fake PURCHASE attestations, a
reviewer accepting payment without disclosure.
A3: Targeted attacker. Capable, motivated. Goal-directed:
destroy a specific competitor, suppress a specific reviewer,
capture a specific topic’s governance, compromise the
network root.
Defenses must be evaluated against all three. A defense that
only stops A1 is not enough.
2. Attacks on the existing review market and how Quidnug differs
T-1: Click-farm sybils (A1)
Existing-system mechanism. Buy aged accounts at $0.50-$3
each. Rotate residential proxies. Post 5-star reviews via
review-as-a-service shop.
Quidnug-specific landing. Same accounts can mint quids on
Quidnug for free (no entry cost on the protocol; the OIDC
bridge requires a Google/GitHub account but those are also
cheap on the gray market).
Mitigation.
Per-observer weighting demotes them: a sybil quid has no
trust edges from anyone the observer trusts, so its review
weight is multiplied by ~zero in the algorithm.
Anonymous-observer baseline (operator-root weighted) is also
near-zero for new quids without OIDC verification, so even
unauthenticated readers don’t see meaningful uplift from
sybils.
DNS-anchored validation gives real reviewers a costly,
persistent identity that sybils cannot afford to replicate
at volume.
Residual. Sybils can still create noise visible to the
“raw event count” indicator. Observers must rely on weighted
ratings, not raw counts. UI design problem; addressed by
showing weighted-by-default with raw-count behind a click.
T-2: Brushing (A2)
Existing-system mechanism. Seller ships empty packages to
fake addresses (or scraped real addresses); receiving “buyer”
posts verified-purchase 5-star review.
Quidnug-specific. PURCHASE events must be signed by the
seller’s quid. A validated seller signing fraudulent
PURCHASEs at scale becomes detectable: the seller’s
PURCHASE-to-review-conversion ratio is anomalously high; the
volume of single-buyer-single-purchase patterns is
detectable.
Mitigation.
Validated sellers (Pro/Business) put their site domain at
risk. Loss of validation = loss of seller’s TRUST edge =
PURCHASE attestations from them carry near-zero weight.
Auditor / fraud-hunter role (T-15 below) can publish FLAG
events against suspect seller quids; observers who trust
the auditor inherit the flag.
Statistical detection: brushing produces signature patterns
(impossibly fast purchase-to-review conversion, repeated
buyer addresses, single-purchase-per-buyer-quid). The
network’s append-only history makes these patterns
impossible to hide.
Residual. Small-scale brushing by validated sellers who
discipline their volume can still slip through. Reduces the
ROI of brushing significantly without eliminating it.
T-3: Review-trade networks (A2)
Existing-system mechanism. Closed groups (Facebook,
Telegram) where sellers swap 5-star reviews. Real humans, real
purchases, very hard to detect by content.
Quidnug-specific. Trade rings appear in the trust graph
as densely-mutually-connected clusters with little outside
connection. Graph analysis exposes them.
Mitigation.
Per-observer weighting: trade-ring members have trust edges
among themselves but no edges from observers outside the
ring. Weights collapse for outside readers.
Auditor role: clustering analysis publishes FLAG events
against ring members.
Topical scoping: a trade ring covering “tech.laptops” doesn’t
pollute “restaurants” or “books.” Vertical isolation limits
blast radius.
Residual. Cohorts of real-purchase-real-human reciprocal
reviewers are inherently legitimate-looking from inside; only
graph topology and behavioral patterns differentiate.
Effective defense requires active auditors; no purely
algorithmic defense suffices.
T-4: Incentivized review schemes (A2)
Existing-system mechanism. Insert-card schemes (“review
us for a $20 gift card”) inducing reviews outside the
platform’s audit pipeline.
Quidnug-specific. Inducement is invisible to the protocol
unless disclosed. QRP-0001 includes a DISCLOSURE event for
voluntary disclosure (“this review was sponsored by …”).
Mitigation.
Make undisclosed inducement a violation of QRP norms;
observers can filter or down-weight reviews from quids that
the auditor has flagged for undisclosed inducement.
Brand-disclosure marketplace (see README §6) offers an
on-protocol path for sponsored reviews that’s better-priced
and more credible than off-protocol bribery, undercutting
the gray market.
Residual. Off-protocol inducement is undetectable from the
protocol alone; relies on whistleblower flagging and pattern
analysis.
T-5: Brigading (A3)
Existing-system mechanism. Coordinated negative-review
attacks driven by politics, competition, viral grievance.
Weekend brigade can move 4.6 → 3.2.
Quidnug-specific. Brigaders are typically new or low-rep
quids with no trust edges from existing observer graphs.
Mitigation.
Per-observer weighting: brigader weights collapse to near-
zero from any observer with an established trust graph.
“Weighted from people you trust” UI replacing “average
rating” UI. The brigading attack is invisible to a
weighted-rating reader.
Anonymous-observer baseline uses operator-root weighting,
so brigaders need a TRUST edge from operators to count;
Quidnug LLC issues those only via OIDC bridge (level 0.2)
or paid validation. Brigading via OIDC requires creating
many Google/GitHub accounts (still possible but more
expensive than today’s brigading).
Residual. A determined attacker with budget for thousands
of OIDC-bridged identities can still produce visible noise in
raw counts; weighted ratings remain robust.
T-6: Suppression (A3)
Existing-system mechanism. Brand sues reviewer for
defamation, files DMCA strike, or pressures platform to
de-rank negative review. Reviewer has no permanent record
because platform owns the only copy.
Quidnug-specific. Reviews are append-only, signed, and
hosted on the public network. No platform can delete a
review. Brand cannot pay anyone to bury it.
Mitigation.
Operator-level non-gossip per QDP-0015: an operator who
receives a valid takedown request (defamation ruling, GDPR
erasure, DMCA) can choose to stop gossiping a specific
event ID through their nodes. Other operators may continue
serving.
Federation discipline: an operator who systematically
removes negative reviews of their advertisers loses
validator trust from peer operators; their network
influence shrinks.
Reviewer migration: if Quidnug LLC is captured (e.g., bought
by an entity that suppresses), reviewers can re-anchor at
another federated operator without losing reputation.
Residual. Legal regimes (GDPR, defamation) require some
takedown capability; Quidnug provides operator-level
non-gossip but cannot prevent another operator from serving.
Publish a clear moderation policy at quidnug.com/policy
before launch.
T-7: Generative-AI flooding (A1)
Existing-system mechanism. GPT-class models produce
reviews indistinguishable from human prose. Defense based on
“this reads like real text” is dead.
Quidnug-specific. AI-generated reviews require an
identity that has cost. Without DNS-anchored validation or
costly OIDC accounts, AI-generated reviews live in the
sybil-weight bucket (T-1).
Mitigation.
Identity is the defense, not text-detection. Reviews from
unvalidated, no-trust-edge quids carry near-zero weight
regardless of how good the prose is.
Validated reviewers (alice-eats.com Pro tier) staking their
domain can still write AI-assisted reviews, but they put
their identity at risk if caught.
Residual. Validated reviewers with poor judgment can use
AI to produce dishonest reviews under their real identity.
This is a reputation-management problem, addressed by the
auditor role and observer-driven trust adjustments, not by
the protocol.
3. Quidnug-specific attacks
T-8: Validation-operator key compromise (A3)
Mechanism. Attacker steals the
VALIDATION_OPERATOR_KEY Wrangler secret. Can issue arbitrary
TRUST edges in operators.<anything>.network.quidnug.com.
Mitigation.
The validation-operator quid is subordinate to the seed
governor root: the seed quid issued the validation-operator
its authority.
On detection: governor root publishes
AnchorInvalidation against the compromised
validation-operator key, freezing its edges. New
validation-operator quid generated and authorized.
Customer-side impact is limited: existing TRUST edges from
the compromised operator are also invalidated;
re-validation runs automatically.
Residual. Window between compromise and detection.
Mitigated by short rotation cadence and key-usage anomaly
detection (rate of edge-issuance vs. customer signup rate).
T-9: Seed-validator quorum capture (A3)
Mechanism. Attacker compromises both seed nodes
simultaneously, achieves 2-of-2 validator quorum, can produce
arbitrary blocks.
Mitigation.
Two physically separate operators (home + VPS); compromise
of one doesn’t compromise the other.
Guardian quorum on each seed key (3-of-5, 24h time-lock)
prevents long-term capture: even if attacker gets both
keys, seeds can be recovered through guardian process.
Federation (QDP-0013): once 3+ operators federate, no
single operator’s compromise destroys the network.
Residual. Pre-federation single-operator phase has higher
risk. Mitigation: faster path to federation, conservative
governance, status-page disclosure if compromise suspected.
T-10: Customer key theft (A3)
Mechanism. Reviewer’s wallet key stolen. Attacker can
publish reviews and TRUST edges in reviewer’s name.
Mitigation.
Guardian recovery (QDP-0002): reviewer initiates
GuardianRecoveryInit; guardians approve; key rotated;
attacker’s window is the time-lock period.
Reviewer publishes AnchorInvalidation from the new key
retroactively invalidating attacker-issued events.
Observers who notice the attack can publish FLAG events
immediately; the rating algorithm should de-weight events
near a flagged time window.
Residual. Reviewer’s reputation may take a hit during the
recovery window. Reviews issued by the attacker that match
the reviewer’s normal pattern are hard to retroactively
distinguish.
T-11: Domain hijack of validated site (A3)
Mechanism. Attacker compromises DNS for acmestore.com,
publishes their own challenge, gets validated as the “owner.”
Mitigation.
Validation Worker requires the DNS challenge to be at
_quidnug-challenge.<fqdn> and the resolver quorum must
match across 4 DoH providers. A DNS hijack via a single
resolver doesn’t pass quorum.
Recheck cadence (15min Business, 1h Pro): if the legitimate
owner regains DNS within the recheck window, the attacker’s
TRUST edge is auto-revoked.
Domain-level anomaly: a domain with an existing TRUST edge
that suddenly fails verification multiple times triggers
manual review by Quidnug LLC ops.
Customer can publish a manual revocation request via signed
request from a backup channel (email + KYB-verified
identity proof).
Residual. A registrar-level hijack (attacker controls
the registrar, redirects authoritative nameservers) can pass
DoH quorum. Mitigation requires monitoring DNS via additional
tooling (e.g., DNSSEC validation in the Worker) and customer
backup channels.
T-12: Governance capture (A2/A3)
Mechanism. Quidnug LLC (or its corporate successor) is
acquired by a hostile entity that uses governor authority to
reshape the public review tree, suppress validators, or
issue self-serving TRUST edges.
Mitigation.
Federation (QDP-0013): once multiple operators federate,
any single operator’s governance authority is
geographically/legally distributed.
Foundation transition: long-term, governance authority over
the public review tree migrates to a 501(c)(6) trade
association or comparable non-profit structure (year 2-3
per the entity plan).
Observer disintermediation: observers who don’t trust the
current governor set can ignore the operator root and rely
purely on their direct trust graph; the algorithm degrades
gracefully.
Residual. Acceptably low for a federated/foundation-
governed network; concerning for a single-operator network.
The pre-federation phase carries this risk.
T-13: Brand-disclosure marketplace abuse (A2)
Mechanism. Brands offer payment for reviews via the
on-protocol marketplace; reviewers accept payment but submit
biased reviews disguised as honest. Or: disclosure is technically
present but buried in metadata.
Mitigation.
DISCLOSURE events are first-class; widgets surface them
prominently in the reviewer card and review body.
Observers can filter or apply different weights to
disclosed-sponsored reviews. Default rendering shows
sponsored reviews separately from unsponsored.
Reviewers caught accepting undisclosed payment lose their
validation (PR/legal pressure on the validation operator
to revoke); on-chain DISCLOSURE history is auditable.
Residual. Sophisticated bias (technically disclosed but
written to favor the sponsor anyway) is an editorial-judgment
problem, not a protocol problem. Auditor role + observer
judgment.
T-14: Cross-network spoofing under federation (A3)
Mechanism. Under QDP-0013 federation, attacker stands up
a malicious “federated network” claiming compatibility with
the public Quidnug network, copies real reviews, and adds
malicious edges that propagate cross-network at the federation
discount.
Mitigation.
Federation requires bilateral signed peering edges (QDP-0013).
Quidnug LLC reviews each peering request manually; rejection
reasons are documented in
deploy/public-network/rejection-reasons.md.
Cross-network discount (default 0.8) limits the damage from
a malicious peer.
A peer caught issuing malicious edges is defederated
(TRUST level=0.0 published bilaterally); their cross-network
edges collapse.
Residual. Window between malicious peer activity and
defederation; mitigated by active auditing of peer behavior.
T-15: Auditor / fraud-hunter capture (A3)
Mechanism. Auditor role becomes powerful (their FLAGs
move ratings); attacker captures a prominent auditor either
by buying them or by compromising their key.
Mitigation.
Multiple auditors competing in the same topic; observers
trust a basket of auditors, not a single one. No auditor’s
compromise alone moves observer ratings.
Auditors must validate their own domain (Pro/Business);
their own credibility is at stake when they publish FLAGs.
Auditor flags themselves are subject to FLAG events (meta-
flagging); a captured auditor publishing bad-faith FLAGs
can be flagged by other auditors, demoting their weight.
Residual. Single dominant auditor (Wirecutter-of-flagging)
is a single point of failure; market design should encourage
plurality. Foundations can fund multiple competing auditors to
prevent monopoly.
4. Defense-in-depth summary
The trust-weighted-review system has no single defense.
Layered properties combine:
Property
Stops which attacks
Per-observer weighting
T-1, T-3, T-5, T-7
Topical trust scoping
T-3, T-13
Append-only signed events
T-6 (suppression)
DNS-anchored validation
T-1, T-2, T-7 (raises floor)
Guardian recovery
T-8, T-9, T-10
Subordinate operator quids
T-8
Resolver-quorum DoH probes
T-11
Federation
T-9, T-12
Auditor / FLAG mechanism
T-2, T-3, T-13, T-15
KYB attestation
T-4, T-13
Operator non-gossip policy
T-6 (legal compliance)
Each layer alone is incomplete. The layered combination is
what makes the floor of credible fraud rise sharply against
the existing market.
5. Open questions and residual risk
Items not solved by this design, called out for future QDP
work:
Anonymous reviews. Some review categories (medical
experiences, employer reviews) require pseudonymity for
legitimate safety reasons. QDP-0021 (blind signatures) and
QDP-0024 (group encryption) are paths but not yet active.
Cross-jurisdictional content moderation. A review legal
in Texas may be defamatory in Germany. Operators in
different legal regimes will disagree on what to gossip.
QDP-0015 partially addresses but the policy boundaries are
per-operator.
Long-term reputation portability across federation
schisms. If two operator clusters defederate after a
governance dispute, what happens to reviewer reputations
that span both? Open per QDP-0013 §5.
Quantum threat to ECDSA P-256. Long-term: post-quantum
crypto migration. Not specific to reviews; protocol-level
concern.
Network effects of single-operator phase. The pre-
federation phase concentrates governance risk. Mitigation
is faster federation; risk is operational drag of getting
second operator on-line.
These are called out so reviewers know what they’re trusting
and observers know how much weight to assign.
6. Threat-model maintenance
This document is a living catalog. Add a new entry when:
A new attack pattern is observed in the wild.
A new defense is shipped that changes the residual risk
on an existing attack.
A new actor class emerges (e.g., regulator-as-adversary
if a hostile government targets the network).
Updates are PR’d against this file; significant changes to
the threat model that affect protocol design should be
captured as their own QDP.