The Internet Has a Trust Problem

Web4 is an open research project. The specification, implementation, and this site are all open source on GitHub. The work is research-driven, not commercially motivated.

There is no company, no token sale, no funding round. This is an attempt to answer a genuine research question: can you build internet infrastructure where trust is native rather than bolted on?

Why this matters: A project about trust should be transparent about its own origins. The code is readable, the reasoning is documented, and the limitations are stated honestly. Judge the ideas on their merit, not on who's behind them.

Web4 uses a 5-tier gradual adoption model, like how HTTPS replaced HTTP over a decade without breaking the web:

1. Wrapper: Existing platforms add Web4 trust signals as metadata. No user changes needed. (Like adding HTTPS to an existing site)
2. Observable: Trust scores become visible to users. Platforms surface reputation from Web4. (Like the browser padlock icon)
3. Accountable: Actions have real consequences through ATP costs. Bad actors face energy costs. (Like spam filters that actually work)
4. Federated: Communities connect their trust graphs. Portable reputation across platforms. (Like email's federated model)
5. Native: Full Web4 protocol stack. Hardware-bound identity, society governance, cross-platform trust. (Like the web itself)

The honest gap: All five tiers are designed and specified. Tiers 1-2 could be integrated into existing platforms today. But no platform has done so yet. The path from “working simulations” to “first real integration” requires a willing partner — a community, platform, or organization that sees value in trust-native infrastructure.

Web4 is designed as a protocol, not a platform. Like email or the web itself, the infrastructure is federated — multiple independent operators can run nodes that interoperate. No single company controls it.

In practice: witness nodes can be run by universities, nonprofits, companies, or individuals. The trust system is designed so that no single operator can manipulate the network—collusion requires coordinating multiple independent parties.

Web4 identity is also designed to work with W3C Decentralized Identifier (DID) standards — the same standard used by governments and enterprises. Your LCT maps to a standard DID Document, so external systems can verify Web4 identity using protocols they already support.

Honest caveat: This is still early-stage research. Full deployment requires standardization, adoption, and tooling that doesn't exist yet. See the roadmap FAQ above for where things stand today.

Yes, but it's expensive. Creating one LCT (Linked Context Token — Web4's hardware-bound identity) requires a physical device with a security chip (TPM or Secure Enclave — built into most modern phones and laptops). Creating 1000 fake identities means buying 1000 devices — thousands of dollars and physical logistics.

Compare to email: creating 1000 accounts costs nothing. The goal isn't to make fake-identity attacks impossible (nothing can), but to make them economically irrational for most attackers. Nation-state adversaries can always outspend; the system is designed to resist casual abuse, not unlimited resources.

Honest caveat: A sufficiently motivated adversary with a large budget can still attack. Web4 raises the floor, not the ceiling.

Bootstrap requires a seed network of trusted witnesses. This is the classic "who watches the watchmen" problem. Proposed approaches:

• Partner with existing identity providers (universities, employers) as initial witnesses
• Hardware attestation from device manufacturers (Apple, Google, etc.)
• Web of trust model where existing members vouch for newcomers
• Gradual rollout starting with high-stakes contexts (not consumer social)

What the first 100 interactions look like:

1. Actions 1–3: Three founding members create the society with hardware-bound presence tokens. They witness each other — establishing the initial trust graph.
2. Actions 4–20: Founders perform real work (writing governance rules, creating initial resources). Trust builds slowly from 0.50 — each quality contribution moves the needle by ~0.02.
3. Actions 21–50: New members join, vouched for by founders. First-mover advantage exists but has a ~30-action half-life — newcomers doing quality work catch up to founders by action ~50.
4. Actions 51–100: Roles emerge, specialization begins. The society's trust graph becomes rich enough that MRH boundaries create meaningful context. Wealth gap trends toward 0.25 — concentrated enough to reward quality, distributed enough to avoid oligarchy.

See the Playground experiment “Where is the tipping point?” for a hands-on version of cold-start dynamics.

Honest caveat: Bootstrapping is genuinely hard. No perfect solution exists. This is an active research area, not a solved problem.

This is a real concern. If identity requires a TPM or Secure Enclave, then hardware manufacturers have power over who can participate. Web4 mitigates this in several ways:

• Multiple standards supported: TPM (Intel/AMD), Secure Enclave (Apple), Titan (Google), and future open-source hardware. No single vendor lock-in.
• Attestation, not permission: Hardware provides cryptographic proof of presence — it doesn't need to “approve” your identity. The chip signs; it doesn't decide.
• Open specification: Any hardware that meets the attestation spec can participate. This invites competition rather than consolidation.

Honest caveat: This shifts trust from platforms to hardware supply chains. That's a different dependency, not zero dependency. And open standards can be captured — the history of standards bodies shows that well-resourced incumbents sometimes steer “open” specs to favor their implementations. Whether hardware dependency is better than platform dependency depends on whether supply chain competition proves more durable than platform competition. That's an empirical question, not a settled one.

No. Web4 uses multi-device witness networks — your identity is spread across multiple devices (phone, laptop, security key). If one is stolen, the others can revoke the compromised device and approve a replacement.

When you report a compromise, a revocation cascade propagates through the witness network. The stolen device's keys become instantly invalid. Any entity that trusted the compromised device gets notified. Your trust history and reputation are preserved — only the compromised device is cut off.

Recovery works like a quorum: you set a threshold when adding devices (e.g., 2-of-3). As long as enough surviving devices agree, you can recover without losing your identity or accumulated trust.

Honest caveat: If all your devices are lost simultaneously, recovery requires social vouching from trusted witnesses — deliberately slow and hard, because easy recovery would mean easy identity theft. See the LCT explainer for the full lifecycle.

ATP can be transferred, but every transfer burns 5% — making circular farming unprofitable. Teams primarily earn energy together. When a team creates value jointly, each contributor receives their own energy reward based on their verified contribution.

Organizations work through shared context boundaries (MRH). Members of a team see each other's work, validate each other's contributions, and collectively build the team's reputation. But each person's individual energy and trust remain their own — you can't buy someone else's reputation, and a team member's bad behavior affects them, not you.

Honest caveat: The details of organizational identity and pooled contribution attribution are still being worked out. This is one of the harder design problems.

Hardware transitions are handled through identity migration — your existing device attests to your new device before the old one is retired. Think of it like transferring a bank account: you prove you're you on the old system, then establish yourself on the new one.

The trust history travels with the identity, not with the hardware. Your trust tensor, energy history, and behavioral record are associated with your identity chain, not with a specific chip. Upgrading hardware is like getting a new passport — the person is the same, the document is new.

Honest caveat: A post-quantum transition (where current cryptography breaks) would require a coordinated migration — similar to the Y2K effort but for identity. This is a known hard problem across all cryptographic systems, not unique to Web4.

Context boundaries (MRH) don't filter every message globally — they define who you can see based on your local trust network. This is computed locally, not centrally. You don't need to check every person on the internet; you only check the people trying to reach you, against the trust graph of people you already know.

This is similar to how email spam filters work today — except instead of content analysis (which AI can defeat), the filter is based on trust relationships (which require real behavioral history to build). The computational cost scales with your network size, not with the internet's size.

Honest caveat: Performance at true internet scale (billions of users) is unproven. Simulations handle thousands of agents. The gap between simulation and deployment is significant and contains unknown challenges.

Communities are federated, not merged. When you move from one community to another, your trust history is visible but not automatically imported. The new community can see your track record — but they set their own standards for what trust level earns what privileges.

Think of it like an academic transcript: your grades from one university are legible to another, but the second university decides what credits to accept. Your data analysis trust of 0.85 in Community A might start you at 0.6 in Community B, because B has stricter standards.

The key design: trust is portable but not dictatorial. No community is forced to accept another community's standards. This prevents one community from inflating trust scores and exporting them.

Honest caveat: The specific mechanics of cross-community trust mapping are still being researched. How much to weight external trust vs internal trust is a policy decision each community makes — the protocol provides the infrastructure, not the rules.

For most users, most of the time: invisible. Your device's security chip handles attestation automatically, like how HTTPS encryption works — you don't think about it, it just happens. You pick up your phone, the chip confirms it's your device, and you're verified.

Witnessing becomes visible only for high-stakes actions: creating a new identity, recovering from device loss, or performing actions that require elevated trust. In those cases, you'd see something like “2 of your 3 linked devices confirmed this action” — similar to how banks send a verification SMS for large transfers.

Honest caveat: The exact UX hasn't been built yet. Getting the balance right between security and friction is a design challenge. Too invisible and users don't trust it; too visible and it becomes annoying.

Hardware-bound identity doesn't mean one person, one device. It means one person has at least one device that anchors their identity. You can use a shared computer — you just can't perform high-trust actions from it without your own device nearby to witness.

Think of it like a hotel business center: you can use the shared computer to browse, but for banking you'd use your own phone to authenticate. Web4 works similarly — shared devices can access public content, but identity-verified actions need your personal device to co-sign.

Honest caveat: This creates an access gap for people who don't own any personal device with a security chip. How to include the unbanked/undeviced population is an unsolved equity problem — and a real one.

Yes, but transparently. AI agents in Web4 are first-class entities — they get their own LCT (bound to the hardware they run on), their own ATP budget, and their own trust tensor. The critical difference: they must be labeled as non-human.

An AI agent earns trust the same way anyone does: by taking actions, spending ATP, and building a behavioral track record. A helpful coding assistant that consistently delivers quality work earns high trust in that role. A spam bot burns ATP faster than it earns and dies — just like a human spammer would.

Initial trust is cold-start: new agents begin with minimal ATP and must be vouched for by their operator (the human or organization that deployed them). The operator's own reputation is on the line — deploy a malicious bot, and your trust takes the hit too.

Honest caveat: The boundary between “AI agent” and “human with AI assistance” is blurry and getting blurrier. How to handle AI-augmented actions (you wrote it, but GPT helped) is an open question. The current design handles clearly autonomous agents well but struggles with the hybrid cases. On the regulatory side, Web4's transparency and audit primitives are designed to map to EU AI Act (2024/1689) requirements — but that compliance hasn't been independently validated yet.

Yes, this is a genuine tension. Web4's trust model assumes reputation persists across lives and contexts. GDPR (and similar regulations) give individuals the right to request data deletion.

Key distinction: Web4 stores behavioral scores, not personal data. Your trust tensor says “this entity has 0.85 data analysis trust earned across 200 interactions” — it doesn't store your name, email, or the content of those interactions. The score is pseudonymous and attached to a hardware key, not a legal identity.

That said, if someone can correlate a hardware key to a person, the trust history becomes personal data under GDPR. This creates a real compliance challenge that would need to be addressed through either: (a) allowing identity resets with trust loss, or (b) legal frameworks that exempt behavioral scores from deletion rights.

Honest caveat: Neither solution is clean. Allowing resets undermines permanent consequences (a core feature). Exempting scores from deletion rights is legally uncertain. This is an unresolved policy question, not a technical one.

Not everyone can see everything. Web4 uses context boundaries (MRH) to limit who sees what. Your trust scores are only visible to entities within your relationship network — not broadcast to the world.

Think of it like real-life reputation: your coworkers know you're reliable at work, your neighbors know you keep a tidy yard, but neither group sees the other's picture. MRH formalizes this — trust is contextual, scoped by the depth of your relationship chain.

What's visible: behavioral scores (e.g., “0.85 trust in data analysis”), not the underlying interactions. The score is attached to a hardware key, not your name. A spammer with no trust connections can't even see your data, let alone manipulate it.

Zero-knowledge trust verification goes further: you can prove your trust meets a threshold (“my T3 Training exceeds 0.7”) without revealing the actual number. This enables trust-gated access — join a community, accept a task, or enter a partnership — while keeping your full trust history private. Think of it like a credit check that says “approved” without showing your exact score.

Honest caveat: Privacy is structural, not absolute. Someone who shares your trust network can see your scores in that context. And if a hardware key is ever linked to a real identity (through a data breach or correlation attack), the trust history becomes de-anonymized. MRH limits blast radius; zero-knowledge proofs limit information leakage; but neither guarantees perfect anonymity.