Trust That Travels With You

The web solved login.

We have passwords, OAuth, passkeys, wallets, sessions, CAPTCHAs, magic links, and enough “verify your email” flows to last several lifetimes.

So yes, the internet can usually answer one question:

Can this account get in?

But it is much worse at answering the question we increasingly care about:

Should this account be trusted?

Every platform has to figure that out for itself. Every forum rebuilds moderation. Every marketplace rebuilds seller credibility. Every game rebuilds anti-cheat identity. Every community fights spam like it is the first community to ever meet spam.

That was annoying before. With AI-generated users, bot farms, synthetic identities, and disposable accounts, it becomes a real infrastructure problem.

The internet solved authentication. It did not solve portable trust.

Every App Treats You Like a Stranger

Modern internet identity is fragmented. Your GitHub history, forum reputation, marketplace credibility, moderation history, open-source contributions, competitive rankings, and AI-agent reliability all live in separate boxes.

Join a new platform and you start from zero.

That is strange when you think about it. A developer with ten years of open-source contributions can look identical to a bot with a fresh email address. A trusted community member can join another community and be treated like an unknown risk. A spammer banned in one place can simply appear somewhere else with a clean face.

This creates obvious problems:

• spam becomes cheap
• ban evasion becomes easy
• moderation work gets duplicated
• trust cannot compound over time
• credible users look too much like disposable accounts

AI makes the gap wider. Accounts are becoming effectively free. Trust is becoming the scarce resource.

The Idea: Portable Trust

Instead of building yet another profile system, imagine a portable trust layer.

The basic idea is simple:

• users control cryptographic identities
• apps and communities issue signed attestations
• reputation can travel between systems
• each app decides which signals it cares about

Not identity as a profile page.

Identity as verifiable history.

Think of it less like a universal social network and more like a backpack of receipts. You decide what to carry. Apps decide what they trust. Nobody has to believe a central platform just because it says so.

The Building Blocks

Identity

Each user controls a cryptographic keypair. That keypair becomes the anchor for their identity.

The keypair is not the product. Nobody wants to “manage a keypair” over breakfast. It should feel closer to passkeys or browser credentials: boring, quiet, and mostly invisible.

Claims

A claim is something you say about yourself, backed by proof.

{
  "type": "github",
  "value": "joris",
  "proof": "signed gist"
}

Claims could include:

• domain ownership
• GitHub accounts
• email verification
• Bluesky accounts
• package ownership
• competition profiles

The important part is that claims are verifiable. “I own this domain” becomes something software can check, not something a profile page merely asserts.

Attestations

An attestation is something someone else signs about you.

{
  "from": "community.xyz",
  "to": "user_pubkey",
  "claim": "trusted_contributor",
  "signature": "..."
}

Or, less flattering:

{
  "from": "forum.example",
  "to": "user_pubkey",
  "claim": "spam_banned"
}

This is where trust becomes interesting. A single attestation is just a signal. Many attestations, from sources you already trust, can become a useful reputation graph.

Reputation Should Be Useful Outside One Website

A new community could look at a user and know things like:

• this person has contributed to open source
• this identity has existed for years
• this user owns verified domains
• trusted developers have endorsed this user
• several communities have flagged this identity for spam

That does not mean the new community must blindly accept someone. It means it can start with useful context instead of pure guesswork.

Reputation should compound, not reset.

Why AI Makes This Urgent

We are entering a world where synthetic users are cheap, convincing, and tireless.

That changes the question from:

Can this account log in?

to:

What do we know about this entity?

For humans, that means better spam resistance and less duplicated moderation. For AI agents, it may become essential.

An autonomous agent might need to prove:

• which actions it has signed
• which capabilities it has verified
• whether other systems trust it
• whether it has behaved badly before

If agents are going to act on our behalf, they need histories. Not just names. Not just API keys. Histories.

Design Goals

Invisible UX

Users should not have to think about wallets, seed phrases, or ceremony. If this requires normal people to become part-time cryptographers, it loses.

The experience should feel closer to:

• passkeys
• browser credentials
• OAuth, but less trapped inside one provider

The cryptography should be real, but mostly invisible.

No Blockchain Dependency

Portable trust does not need to start with a token. Most of the useful parts require simpler primitives:

• signatures
• verification
• append-only events
• replication
• revocation

Blockchains may be useful in some designs. They should not be the default answer to every sentence containing the word “trust”.

Programmable Trust

Different communities should be allowed to care about different things.

{
  "requires": [
    "github_verified",
    "trusted_by_3_users",
    "older_than_6_months"
  ]
}

A marketplace, a game server, an open-source project, and an AI platform will not share the same trust model. That is fine. The point is not one global score. The point is portable evidence.

What the Architecture Might Look Like

Identity documents

{
  "pubkey": "...",
  "claims": [],
  "attestations": []
}

Signed events

Claims, attestations, updates, and revocations can all be signed events. Anyone can verify them independently.

Federation

Servers could replicate attestations, trust graphs, and revocations in a federated way, similar in spirit to ActivityPub, Matrix, or Nostr relays.

That avoids requiring one global database for everything. It also means trust can remain local where it should be local, while still becoming portable where that is useful.

Where This Would Help

Developers

• verified package ownership
• merged pull requests
• contributor endorsements

Communities

• cross-community spam resistance
• portable moderation context
• better Sybil resistance

AI platforms

• persistent AI-agent trust
• signed outputs
• capability verification

Games

• portable competitive reputation
• anti-cheat trust
• persistent rankings

Marketplaces

• verified trade history
• portable seller credibility
• fraud prevention

The Goal

This is not about replacing governments. It is not about making one universal reputation score for every human being on Earth. That would be creepy and dangerous.

The goal is smaller and more useful:

Portable cryptographic trust for the internet.

Trust should not be trapped inside every app forever. If you have earned it somewhere, you should be able to carry useful parts of it elsewhere.

That is the missing primitive.