Trust Infrastructure Protocol

FAQ

Section 1 — The Basics

1. What is this system?

It is a private safety-check system that helps people in risky work or social situations quietly share information about who is safe and who is not.

It is not:

a marketplace
a dating app
a booking service
a public review site

It only answers one question:

“Has this person been safe to deal with before?”

2. Why does this exist?

Because many real-world situations are dangerous and under-protected, for example:

meeting strangers
entering private homes
working with powerful gatekeepers
dating
stigmatized or informal labor

In these environments:

police help is weak or too late
reporting can backfire
retaliation is easy
identity exposure is dangerous
profit-driven platforms ignore safety

So people lack a reliable way to warn each other.

This system provides that missing layer.

3. Who is this for?

Any group where:

harm is possible
retaliation is easy
formal enforcement is weak
privacy is essential

Examples:

gig workers
rideshare drivers
students
performers
freelancers
domestic workers
sex workers

4. Is this like Uber ratings or Yelp?

No.

Typical platforms:

collect identities
allow fake reviews
allow retaliation
optimize for growth
reward popularity

This system:

stores no identities
verifies every rating
blocks retaliation mathematically
is cooperative
measures safety only

Section 2 — Core Principles

5. What are the core rules?

Higher-risk side has more authority
No real identities
Only real interactions can be rated
Worst-case behavior matters most
Quiet exclusion, not punishment

6. Why give authority to the higher-risk side?

Because they face the consequences.

Risk should determine influence.

7. Why no identity collection?

Identity databases create:

leaks
subpoenas
doxxing
retaliation
legal exposure

If identity exists, it can be abused.

So it doesn’t exist.

8. Why avoid public blacklists?

Public accusations create:

lawsuits
harassment
escalation
spectacle

Quiet refusal is safer.

The system simply helps people say:

“No, thank you.”

Section 3 — How It Works

9. How do I join?

Join the cooperative.
Create an anonymous account.

No ID required.

10. How do ratings happen?

After a real interaction:

Both sides receive a one-time code
Enter code
Mark safe/unsafe and reliable/unreliable

Done.

11. Why one-time codes?

They ensure:

no fake reviews
no bots
no revenge spam
no sockpuppets

Only real interactions generate ratings.

12. What information is stored?

Only:

pseudonyms
safety flags
reliability flags
verification codes

Nothing else.

13. Can I browse people?

No.

No listings.
No search.
No discovery.

Only lookup after contact.

This prevents targeting or misuse.

Section 4 — The Scoring Logic (Simple Version)

14. How is trust calculated?

The system asks:

“How bad are their worst behaviors?”

Not:

“What’s their average score?”

Repeated harm shows up quickly.

15. Why not averages?

Averages hide predators.

Worst-case behavior determines risk.

16. What happens to unsafe people?

They gradually:

lose trust
lose influence
get screened out

No public punishment.

Just reduced access.

17. Can someone retaliate with bad reviews?

No.

Low-trust users’ ratings barely count.

Revenge becomes ineffective.

18. Can someone start over?

Yes.

Accounts can be deleted.

No permanent records.

This is about safety, not punishment.

Section 5 — Governance

19. Who owns it?

Members.

It’s a cooperative.

20. How are decisions made?

One member, one vote.

Not money-based.

21. How is it funded?

Fixed dues.

No per-transaction fees.

This avoids growth pressure.

22. Why not investors?

Investors demand:

data
monetization
growth

These conflict with safety and privacy.

Section 6 — Safety & Privacy

23. What if data leaks?

It contains only anonymous flags.

No identities.

No useful target.

24. Is this surveillance?

No.

It minimizes data and avoids tracking.

It is anti-surveillance by design.

25. Does it replace the law?

No.

It prevents harm before it happens.

Section 7 — Minimal Technology Stack

This section explains an important point:

This system is intentionally simple technology.

It is infrastructure, not a startup.

If it becomes technically complex, it becomes expensive, fragile, and easier to corrupt.

26. Why emphasize “minimal tech”?

Because complexity creates problems:

Complex systems:

cost more
need venture funding
collect more data
attract growth pressure
increase surveillance risk
create corporate capture

Safety tools should be:

small
cheap
boring
maintainable by normal people

Like a community library or a spreadsheet — not Silicon Valley software.

27. What is the simplest possible implementation?

At its core, the system only needs:

a website
a small database
login accounts
one-time codes
basic math

Nothing else.

No AI.
No machine learning.
No big data.
No apps.
No tracking.

28. What does the stack actually look like?

Conceptually:

Infrastructure

basic web server
simple hosting provider
encrypted connections (HTTPS)

Backend

small database (users + flags + codes)
simple logic for trust scores

Frontend

plain web forms
login page
“enter code” page
“check trust” page

That’s it.

Technically, this could be built in a few thousand lines of code.

29. Why web-only and not a mobile app?

Apps create:

app store control
censorship risk
forced updates
tracking frameworks
higher maintenance

A website:

works on any device
is harder to ban
collects less data
is cheaper to maintain
is easier for cooperatives to self-host

Web is more resilient and more private.

30. Why avoid advanced features like AI or analytics?

They are unnecessary and dangerous.

They:

increase data collection
create bias
require specialists
make systems opaque
invite misuse

This system uses simple, transparent math instead.

Everyone should be able to understand how scores work.

No black boxes.

31. How much data storage is required?

Very little.

Only:

accounts
flags
codes

Even a large cooperative could run on a tiny server.

This keeps costs low and independence high.

32. Can a small group host this themselves?

Yes.

That is the goal.

A local cooperative should be able to:

rent cheap hosting
deploy the software
run it without outside control

No dependence on corporations.

33. Why avoid third parties?

Every third party adds:

tracking
legal exposure
dependency
attack surface

So:

no external analytics
no ad networks
no social logins
no payment processors inside the system

Only essentials.

34. What is the philosophy behind the tech design?

Simple rule:

The safest system is the one that stores the least and does the least.

Less data = less risk
Less complexity = fewer failures
Less dependency = more autonomy

35. What should this feel like?

Not like an app.

More like:

a shared safety ledger
a digital notebook
a quiet utility

If it feels flashy or “platform-like,” it’s probably overengineered.

Section 8 — Practical Examples

(unchanged examples: sex work, ride-share, gig, campus, entertainment, small business)

Section 9 — Limitations

36. What can’t it do?

It cannot:

guarantee safety
stop first-time offenders
replace law enforcement
solve every conflict

It reduces repeated harm.

37. Is it perfect?

No.

But it is:

cheap
private
hard to game
easy to run
cooperative

Which makes it realistic.

Final Summary

In one sentence:

It’s a small, private, cooperative safety notebook that helps people quietly avoid dangerous individuals without exposing their identities.

In three ideas:

Minimal data
Simple math
Worker control

Everything else is implementation detail.

How This Differs from Existing Systems

And Why Existing Systems Fail

This appendix answers a common question:

“Don’t we already have rating systems, background checks, or reporting tools? Why build something new?”

The short answer:

Most existing systems were designed for convenience and commerce, not safety under retaliation risk.

They solve the wrong problem.

This protocol is designed specifically for:

asymmetric risk
weak enforcement
high retaliation costs
privacy sensitivity

Those constraints change everything.

Part 1 — The Core Mismatch

1. What normal platforms optimize for

Most modern platforms optimize for:

growth
transactions
engagement
revenue
liability reduction

Safety is secondary.

Safety features are added only if they:

reduce lawsuits
protect brand image
don’t reduce growth

So structurally:

Platforms protect the company first, users second.

2. What high-risk communities need

High-risk communities instead need:

privacy first
retaliation resistance
verified experiences
quiet exclusion
cooperative control
minimal data

These goals often conflict with platform economics.

Example:
A platform wants searchable profiles.
A vulnerable worker needs non-searchability.

These are opposites.

Part 2 — Why Common Systems Fail

Below are the main categories of existing solutions and their structural failure modes.

A. Star Rating / Reputation Platforms (Uber, Airbnb, Yelp, etc.)

How they work

public profiles
star averages
anyone can rate
companies control the system

Why they fail for safety

1. Averages hide harm

A person can:

behave well 90% of the time
be dangerous 10% of the time

Average still looks “good.”

For safety, one violent incident is enough.

Average scoring is the wrong metric.

2. Retaliation is easy

If I rate someone badly, they rate me badly.

Result:

victims stay silent
everyone leaves neutral reviews
system becomes meaningless

Fear suppresses truth.

3. Fake reviews are easy

friends inflate ratings
enemies deflate ratings
bots manipulate scores

No verification that interactions happened.

So trust becomes theater.

4. Platforms prioritize high-volume users

Companies protect:

frequent customers
high spenders
power users

If a top customer harms others, the platform has an incentive to keep them.

Safety loses to revenue.

5. Identity exposure

Profiles are public and persistent.

This creates:

doxxing risk
stalking risk
career retaliation
legal exposure

High-risk workers often cannot safely participate.

Summary of failure

These systems measure popularity and satisfaction, not risk.

They are commerce tools, not safety tools.

B. Background Checks

How they work

identity verification
criminal records
centralized databases

Why they fail

1. Only catch past convictions

Most harm:

is never reported
never prosecuted
never convicted

So background checks miss most real risk.

2. Slow and outdated

Records update slowly.

Harm can happen repeatedly before anything appears.

3. Require identity disclosure

Users must share:

legal names
addresses
documents

This creates:

surveillance
legal exposure
data breaches

Many vulnerable workers cannot safely provide this information.

4. Centralized power

Background checks depend on:

companies
governments
third parties

Communities lose control.

Summary of failure

Background checks measure legal history, not behavioral safety.

And they require the very identity exposure that high-risk users cannot accept.

C. Reporting to Authorities

How it works

Victims report harm to:

police
HR
institutions

Why it fails

1. Too late

Reporting happens after harm.

This system is preventative.

2. Retaliation risk

Reporting can cause:

job loss
blacklisting
social stigma
legal threats

So many victims stay silent.

3. Institutional protection of power

Organizations often protect:

employers
high earners
celebrities
senior staff

Victims are seen as liabilities.

4. High burden of proof

Victims must:

document everything
relive trauma
navigate bureaucracy

Most simply don’t report.

Summary of failure

Formal systems are punitive and reactive, not preventive and protective.

D. Public Blacklists / “Callout Lists”

How they work

public spreadsheets
social media posts
shared rumors

Why they fail

1. Legal risk

Defamation claims
Takedowns
Threats

Lists get shut down.

2. Escalation

Public accusations trigger:

harassment
counterattacks
drama
polarization

Not safety.

3. No verification

Anyone can post anything.

Truth becomes uncertain.

Trust collapses.

4. Permanent records

People can never recover, even for minor or disputed events.

This creates injustice and discourages participation.

Summary of failure

Public lists create conflict and legal exposure instead of quiet protection.

Part 3 — How This Protocol Differs Structurally

Instead of patching old models, this system changes the structure.

Key Differences

1. Not a marketplace

No discovery
No profiles
No growth pressure

Only screening

2. Not public

No searchable data
No lists
No shaming

Only private checks

3. Not identity-based

No names
No documents
No tracking

Only pseudonyms

4. Not average scoring

Worst-case behavior matters most

Safety-first math

5. Not corporate-owned

Cooperative governance

Members control rules

6. Not punitive

No bans
No exposure
No spectacle

Just reduced trust

Part 4 — Comparison Table

Feature	Typical Platforms	This Protocol
Identity required	Yes	No
Public profiles	Yes	No
Browsing/search	Yes	No
Average ratings	Yes	No
Verified interactions	Rare	Always
Retaliation resistant	No	Yes
Corporate ownership	Yes	No
Growth incentives	Yes	No
Privacy first	No	Yes
Quiet exclusion	No	Yes

Part 5 — Core Insight

Most existing systems ask:

“How do we maximize transactions safely?”

This protocol asks:

“How do we minimize harm without creating new risk?”

Those are different goals.

Different goals require different architecture.

Final Summary

Existing systems fail because they are:

identity-heavy
growth-driven
average-based
retaliation-prone
corporate-controlled

This protocol is:

anonymous
minimal
worst-case focused
retaliation-resistant
cooperative

It is designed specifically for people who cannot safely rely on mainstream systems.

That is why it works where others fail.

CollectiveSafetyNet