ATProtoFans introduces a novel approach to creator support by leveraging ATProtocol's decentralized architecture and cryptographic attestations. This article explores the technical foundations of the system, focusing on the three-way relationship between supporter records, supporter proofs, and broker proofs, and how developers can integrate these records into their own applications.

The Problem with Traditional Support Platforms

In conventional creator support platforms, the relationship between a supporter and creator exists solely in a centralized database. This creates several issues:

  • No portability: If the platform shuts down, all support history vanishes

  • No verifiability: There's no way to independently prove a support relationship existed

  • Platform lock-in: Creators can't take their supporter lists elsewhere

ATProtoFans addresses these problems by storing support relationships as cryptographically verifiable records distributed across the ATProtocol network.

Remote Attestations: The Foundation

Before diving into the specifics, it's important to understand remote attestations. An attestation is a signed statement vouching for the validity of a claim. In ATProtoFans, multiple parties create attestations that together form a verifiable chain of proof.

When someone claims "I support this creator," that claim alone isn't particularly meaningful—anyone could say that. But when that claim is backed by attestations from both the creator and an independent broker, it becomes cryptographically verifiable and has weight.

The Three-Way Relationship

ATProtoFans creates three distinct records when a support action occurs:

1. The Supporter Record (com.atprotofans.supporter)

This record lives in the supporter's repository and represents their declaration of support. It's the primary record that says "I support this creator."

{
  "$type": "com.atprotofans.supporter",
  "subject": "did:plc:creator123",
  "txnid": "01ARZ3NDEKTSV4RRFFQ69G5FAV",
  "signatures": [
    {
      "$type": "com.atproto.repo.strongRef",
      "uri": "at://did:plc:broker789/com.atprotofans.brokerProof/3abc123def",
      "cid": "bafyreixyz..."
    },
    {
      "$type": "com.atproto.repo.strongRef",
      "uri": "at://did:plc:creator123/com.atprotofans.supporterProof/3def456ghi",
      "cid": "bafyreiabc..."
    }
  ]
}

Key fields:

  • subject: The DID of the creator being supported

  • txnid: A unique transaction identifier that de-duplicates support instances

  • signatures: An array of attestation references that validate this support claim

The signatures array uses ATProtocol's strongRef type—each entry points to a proof record in another repository via its AT-URI and CID. This allows independent verification by fetching and validating the referenced records.

2. The Supporter Proof Record (com.atprotofans.supporterProof)

This record lives in the creator's repository and serves as their attestation that the support relationship is legitimate. When a creator's repository contains a supporter proof, they're vouching for the validity of the supporter's claim.

{
  "$type": "com.atprotofans.supporterProof",
  "cid": "bafyreiabc..."
}

With remote attestations (the default), only the $type and cid fields are present. The cid references the content being attested to, in this case, the supporter record. The proof itself is the existence of this record in the creator's repository, signed by their PDS.

3. The Broker Proof Record (com.atprotofans.brokerProof)

This record lives in the broker's repository (ATProtoFans itself) and provides independent third-party verification. The broker witnessed the transaction and can attest to its legitimacy.

{
  "$type": "com.atprotofans.brokerProof",
  "cid": "bafyreixyz..."
}

The broker proof serves several important functions:

  • Independent verification: A neutral third party confirms the transaction occurred

  • Fraud prevention: The broker can invalidate attestations if a refund is issued

  • Trust anchor: Applications can choose which brokers they trust

Why Three Records?

This three-way structure provides defense in depth:

  • The supporter declares their support (but could be lying)

  • The creator attests they received support (but could collude with the supporter)

  • The broker independently verifies the transaction occurred (neutral third party)

For a support relationship to be fully verified, all three records must exist and be valid. An application can choose its own trust model—perhaps it only requires the supporter and creator records, or perhaps it demands all three including a specific trusted broker.

The Attestation Flow

When a supporter makes a payment, ATProtoFans creates the attestation chain:

  • Payment Processing: The supporter completes payment via Stripe

  • Broker Attestation: ATProtoFans creates a brokerProof record, signing the supporter's claim

  • Creator Attestation: A supporterProof record is created in the creator's repository (using their app password)

  • Record Distribution: The supporter record (with strongRef signatures) is written to the supporter's repository

  • Cache Population: Attestation CIDs are added to a bloom filter for fast validation

This chained attestation ensures that both the broker and creator have independently vouched for the support relationship before it's finalized.

The XRPC API

ATProtoFans exposes several XRPC endpoints that developers can use to query and validate support relationships.

Validating a Supporter

The com.atprotofans.validateSupporter endpoint checks whether a valid support relationship exists between two identities, validated by a specific signer.

Request:

GET /xrpc/com.atprotofans.validateSupporter
  ?supporter=did:plc:supporter123
  &subject=did:plc:creator456
  &signer=did:plc:broker789

Parameters:

  • supporter - DID of the alleged supporter

  • subject - DID of the creator being supported

  • signer - DID of the signer whose attestation must be valid

Response:

{
  "valid": true,
  "profile": {
    "did": "did:plc:supporter123",
    "handle": "supporter.bsky.social",
    "displayName": "Jane Supporter",
    "supporterCount": 5
  }
}

The signer parameter is particularly important—it lets you specify which attestation authority you trust. You might require ATProtoFans' broker attestation, or you might accept any attestation from a set of trusted signers.

Errors:

  • InvalidRequest - Invalid DID format or missing required parameters

  • ServiceUnavailable - Validation service temporarily unavailable

Retrieving Supporters

The com.atprotofans.getSupporters endpoint returns a paginated list of all supporters for a given creator.

Request:

GET /xrpc/com.atprotofans.getSupporters
  ?subject=did:plc:creator456
  &limit=50
  &cursor=

Parameters:

  • subject - DID of the creator

  • limit - Maximum number of results (default: 50, max: 100)

  • cursor - Pagination cursor for fetching additional results

Response:

{
  "supporters": [
    {
      "did": "did:plc:abc123",
      "handle": "fan1.bsky.social",
      "displayName": "Fan One",
      "supporterCount": 3
    }
  ],
  "cursor": "50"
}

This endpoint is useful for building supporter walls, exclusive content gates, or community features.

Fetching Profiles

The com.atprotofans.getProfile endpoint retrieves profile information including supporter counts.

Request:

GET /xrpc/com.atprotofans.getProfile?subject=did:plc:creator456

Response:

{
  "did": "did:plc:creator456",
  "handle": "creator.bsky.social",
  "displayName": "Jane Creator",
  "description": "Making cool things!",
  "acceptingSupporters": true,
  "supporterCount": 42
}

Errors:

  • InvalidRequest - Invalid DID format

  • ProfileNotFound - No profile found for the given DID

Trust Models

One of the strengths of this architecture is flexibility in trust models. Applications can decide:

  • Strict validation: Require all three records with a specific trusted broker

  • Creator trust: Accept any support relationship the creator has attested to

  • Federated trust: Accept attestations from any broker in a trusted set

  • Permissive: Accept supporter records with any valid attestation

This flexibility allows the ecosystem to evolve. New brokers can emerge, and applications can choose which ones to trust based on their own criteria.

Profile Records

In addition to support records, ATProtoFans maintains profile records (com.atprotofans.profile) stored at the key self in each user's repository:

{
  "$type": "com.atprotofans.profile",
  "displayName": "Jane Creator",
  "description": "Making cool things!",
  "acceptingSupporters": true,
  "avatar": {
    "$type": "blob",
    "ref": {"$link": "bafyrei..."},
    "mimeType": "image/png",
    "size": 12345
  }
}

These profiles are automatically imported from Bluesky on first login and can be customized through the ATProtoFans interface.

Conclusion

ATProtoFans demonstrates how ATProtocol's decentralized architecture can be leveraged to create verifiable, portable relationships between users. The three-way attestation model provides cryptographic proof of support that survives platform changes and can be validated by any application.

For developers, the XRPC API provides straightforward access to this verification system. Whether you're building supporter-gated content, community features, or entirely new applications, the foundation is there to create experiences built on verifiable support relationships.

Resources: