🕊️ Freebird

The Problem

Online authorization commonly connects access to accounts and operational records. Freebird addresses one specific part of that system: separating token issuance from later redemption.

• Rate limiting often uses user or network tracking
• Access control commonly uses accounts
• Spam prevention can rely on activity monitoring
• Resource allocation often uses registration
• "One person, one vote" often depends on identity databases

A deployment may still collect network, timing, application, admission, and audit data. Those surrounding records remain outside the token protocol.

Traditional System:

User ──────────────────────────▶ Server
      "I am alice@example.com"
      "Give me access"
                                    │
Server logs:                        ▼
✗ Who you are                    Access
✗ When you accessed              Granted
✗ What you accessed              (maybe)
✗ Your usage patterns
✗ Your IP address
✗ Everything, forever

Freebird's Answer

Freebird currently exposes two experimental token modes. V4 uses a Freebird-specific P-256 VOPRF-like construction with DLEQ-style proofs and is not interoperable with RFC 9497 implementations. V5 uses Blind RSA signatures described by RFC 9474 for public bearer passes. Each mode has its own wire format and operating assumptions.

Freebird is a prototype privacy layer for authorization. A finalized token can prove issuer authorization without containing an application identity. The surrounding deployment can still observe and correlate metadata.

Freebird:

        ┌─────────────────────────────────────────────────────────┐
        │                                                         │
        │   User              Issuer              Verifier        │
        │     │                 │                    │            │
        │     │──[blind data]──▶│                    │            │
        │     │                 │ signs without      │            │
        │     │                 │ seeing content     │            │
        │     │◀─[signed blob]──│                    │            │
        │     │                 │                    │            │
        │     │ unblinds to     │                    │            │
        │     │ get token       │                    │            │
        │     │                 │                    │            │
        │     │───────[identity-free token] ────────▶│            │
        │     │                                      │            │
        │     │                              ✓ Valid signature    │
        │     │                              ✓ No app identity    │
        │     │                                                   │
        │                                                         │
        └─────────────────────────────────────────────────────────┘

Freebird reduces linkability at the token layer; network, device, and application metadata remain deployment responsibilities.

• Prove token authorization without putting an identity in the token
• Separate issuance records from redemption records at the token layer
• Support one-time redemption with configured replay storage
• Compose local admission controls before issuance

Token Properties & Operating Limits

These properties describe the protocol boundary and its deployment-dependent limits. Freebird is pre-1.0 and has not received an external security audit.

Private Access and Issuance Patterns

Freebird is built for evaluation and low-stakes deployments. These patterns show how its issuer, verifier, tokens, and admission controls can fit into real products.

Configurable Admission Controls

Freebird includes configurable admission mechanisms that can raise abuse costs or limit issuance. They are local controls. They do not prove a unique human or remove operational metadata.

Invitation System (Trust Graphs)

Users invite others. Operators can trace invitation relationships in admission records and cut off branches. This provides local social trust; it does not provide identity-free accountability or a global anti-abuse guarantee.

Proof of Work

Each token carries a computational cost. This can raise the cost of bot activity without collecting user identity data.

WebAuthn / Hardware Keys

WebAuthn or hardware authenticators can gate issuance. They do not prove humanity; credential and deployment records remain part of the operator's state.

Rate Limiting

IP-based throttling provides basic protection and necessarily uses network identity. It can be stacked with other mechanisms.

Social Graph Attestation

A separate Social Graph Attester service evaluates signed trust edges (compatible with Clout social graphs) and issues short-lived attestations proving a user stands within a trusted social graph, without revealing which node they are. The issuer verifies the attester's Ed25519 signature, policy, expiry, and eligibility level; the underlying graph stays with the attester.

Progressive Trust

Trust can accumulate through configured account age and usage history. New accounts may receive limited quotas. The mechanism uses local records and does not provide global anonymity.

Proof of Diversity

Experimental mechanism that scores requests on behavioral diversity signals to detect coordinated bot campaigns without fingerprinting individuals.

Multi-Party Vouching

N-of-M endorsement: a token is issued only when a quorum of existing trusted members vouch for the requester. No single party can approve or block.

Composable Combiners

Stack mechanisms with OR (any must pass), AND (all must pass), or Threshold (at least N of M). OR inherits the strength of its easiest mechanism, while AND is strictest. Proof replay protection and restart safety depend on the configured store.

Technical Architecture

┌─────────────────────────────────────────────────────────────────────┐
│                         Freebird System                             │
│                                                                     │
│   ┌──────────────┐  ┌──────────────┐  ┌────────────┐  ┌─────────┐   │
│   │    Issuer    │  │   Verifier   │  │   Redis    │  │ Attester│   │
│   │   (Rust)     │  │   (Rust)     │  │  (State)   │  │ (Rust)  │   │
│   │              │  │              │  │            │  │ optional│   │
│   │ - VOPRF eval │  │ - Token auth │  │ - Nulls    │  │ - Trust │   │
│   │ - Blind RSA  │  │ - Multi-     │  │ - Invites  │  │   graph │   │
│   │ - Sybil gates│  │   issuer     │  │ - WebAuthn │  │ -Scoring│   │
│   │ - Key mgmt   │  │   federation │  │            │  │ - JWKS  │   │
│   └──────────────┘  └──────────────┘  └────────────┘  └─────────┘   │
│          │                  │                 │               │     │
│          └──────────────────┴─────────────────┘               │     │
│                             │                                 │     │
│                    ┌────────▼────────┐                        │     │
│                    │   TypeScript    │◀───────────────────────┘     │
│                    │      SDK        │                              │
│                    │                 │                              │
│                    │ Browser/Node.js │                              │
│                    └─────────────────┘                              │
└─────────────────────────────────────────────────────────────────────┘

Current Experimental Implementation

These labels describe code present in the current experimental tree. They do not indicate an external audit, production readiness, or support for a planned profile.

Why Open Infrastructure Matters

Freebird is infrastructure that organizations can inspect, operate, and adapt themselves.

• Self-hostable: Run your own issuer and manage its operational dependencies.
• Federated: Multiple issuers can exist. Verifiers choose whom to trust.
• Auditable: The source is public for review of implementation and cryptographic claims.
• Forkable: Adapt the code and protocol to your own requirements.

Funding Goals

Funding supports evaluation, documentation, test coverage, reference prototypes, and independent review of this experimental project.

Try It

git clone https://github.com/flammafex/freebird
cd freebird
./launch.sh up

The launch.sh helper handles .env setup and ADMIN_API_KEY generation for you. Issuer on localhost:8081, verifier on localhost:8082.

# Get a token
curl -X POST http://localhost:8081/v1/oprf/issue \
  -H "Content-Type: application/json" \
  -d '{"blinded_element": "..."}'

# Verify it
curl -X POST http://localhost:8082/v1/verify \
  -H "Content-Type: application/json" \
  -d '{"token": "..."}'

Full documentation at github.com/flammafex/freebird/docs.

Standards & Prior Art

Freebird uses established cryptographic standards and related protocol designs:

• RFC 9497 — The VOPRF core protocol
• RFC 9577 / RFC 9578 — Privacy Pass HTTP API and issuance protocols (related work from Cloudflare/Apple)
• RFC 9474 — Blind RSA signatures (V5 public bearer passes)
• RFC 9380 — Hash-to-curve specification
• FIPS 186-5 — P-256 curve specification