glowrm

What is Glowrm?

What Glowrm Provides

What Glowrm Is NOT

• Not a dating app or social app itself
• Not handling payments or financial transactions
• Not a single-app backend
• Not storing user profile data (that lives in ATProto repos)

The Problem

Decentralized Identity Creates a Trust Gap

ATProto gives users portable identity:

• Your DID and profile follow you across apps
• You control your data in your own repository
• Apps can't lock you in

But portability has a dark side:

• Get banned from one dating app? Join another with a clean slate
• Harass someone? Switch platforms, fresh start
• Bad behavior has no long-term consequences

Traditional platforms solve this with centralized control:

• Facebook bans you, you're banned everywhere Facebook operates
• But you're also locked into Facebook's ecosystem
• Trade freedom for safety

Why Apps Need Shared Infrastructure

Building trust systems is hard:

• Reputation scoring algorithms
• Moderation workflows
• Appeals processes
• Spam prevention
• Cross-platform coordination

Glowrm provides shared infrastructure:

• Apps focus on their unique value
• Plug into proven trust systems
• Coordinate on moderation
• Network effects: More apps = better trust data

How Glowrm Works

Data Flow Example

Let's trace what happens when someone uses two apps powered by Glowrm:

1. Alice joins PBJ (dating app)

Alice -> PBJ: Signs in with ATProto
PBJ -> Glowrm: "Register did:plc:alice123 in app 'pbj'"
Glowrm:
  - Creates identity record
  - Sets reputation: 50 (new recruit)
  - Initializes SPA: 15 jars/week
  - Returns: { reputation: 50, jars: 15 }

2. Alice sends jars to Bob

Alice -> PBJ: Sends 5 jars to Bob
PBJ -> Glowrm: "Use 5 units for did:plc:alice123"
Glowrm:
  - Checks: Does Alice have 5 jars? Yes (15 available)
  - Deducts 5 from her balance
  - Records allocation
  - Returns: { remaining: 10 }

3. Bob and Alice match

PBJ -> Glowrm: "Report positive_interaction"
Glowrm:
  - Creates trust event (type: positive)
  - Updates both reputations: +1
  - Alice: 50 -> 51
  - Bob: 50 -> 51

4. Alice reports Bob for harassment

Alice -> PBJ: Reports Bob
PBJ -> Glowrm: "Trust event - report, severity: high"
Glowrm:
  - Creates trust event
  - Decreases Bob's reputation: 51 -> 48
  - Flags for admin review

5. Bob gets banned on PBJ

Admin -> Glowrm: Ban did:plc:bob456 (global)
Glowrm:
  - Updates Bob's reputation: 48 -> 20
  - Marks status: banned
  - Global flag: affects all apps

6. Bob tries to join Roster (professional network)

Bob -> Roster: Signs in with ATProto
Roster -> Glowrm: "Register did:plc:bob456 in app 'roster'"
Glowrm:
  - Finds existing identity
  - Checks reputation: 20 (banned)
  - Returns: { reputation: 20, status: "banned" }
Roster -> Bob: "Cannot join - account flagged"

7. Meanwhile, Alice joins Roster

Alice -> Roster: Signs in
Roster -> Glowrm: "Register did:plc:alice123"
Glowrm:
  - Finds existing identity
  - Returns: { reputation: 51, status: "active" }
Roster: Shows Alice as trusted user

Core Concepts

1. Reputation Scores (20-80 Scale)

Why 20-80? Inspired by baseball scouting grades. 50 is average, scores cluster around the middle, outliers at the extremes are rare and meaningful.

Power Protection

Reputation is designed to be hard to game:

• Multiple low scores needed to impact rating
• Outlier scores dropped
• Recent events weighted more heavily
• Rater reputation affects weight (trusted users' reports count more)

2. Trust Events

Types

• positive_interaction: Match, successful conversation, completed transaction
• report: User reported for policy violation
• block: User blocked by another user
• ban: Administrative action removing user
• warn: Warning issued
• suspend: Temporary suspension

Impact on Reputation

3. Strategic Profile Allocation (SPA)

The problem SPA solves: Unlimited actions lead to spam. Tinder-style swiping creates a "spray and pray" approach. LinkedIn InMail becomes a sales pitch fire hose.

The solution: Give users finite "units" (jars, credits, picks, waves) per time period. Forces strategic choices.

Each App Configures

• unitsTotal: How many per period (e.g., 15)
• unitName: What to call them (jars, credits, picks)
• periodDays: Refresh interval (7, 14, 30 days)
• allowVariableAmount: Can users send 1-10 or just 1?

4. Identity & Verification

DIDs as Primary Identifier

• Every user has an ATProto DID (e.g., did:plc:abc123)
• Same DID across all apps
• Glowrm maps DID to reputation/trust data

Privacy

• Glowrm never sees profile content (photos, bio, interests)
• That lives in users' ATProto repos
• Apps read directly from repos
• Glowrm only tracks: DID, reputation, trust events, unit usage

Architecture

System Components

Data Separation

Why this separation?

• Users control their own content (ATProto principle)
• Apps handle their unique features
• Glowrm handles shared trust infrastructure
• No single point of failure for user data

Integration Guide

Quick Start (5 Minutes)

1. Register your app

curl -X POST https://glowrm.io/v1/apps/register \
  -H "Content-Type: application/json" \
  -d '{
    "id": "my-app",
    "name": "My App",
    "displayName": "My App - Find Your People",
    "appType": "dating",
    "spaConfig": {
      "unitsTotal": 15,
      "allowVariableAmount": true,
      "unitName": "credit",
      "periodDays": 7
    }
  }'

Returns:

{
  "appId": "my-app",
  "apiKey": "glowrm_xxxxxxxxxxxxx"
}

2. Configure your environment

GLOWRM_API_URL=https://glowrm.io
GLOWRM_API_KEY=glowrm_xxxxxxxxxxxxx

3. Add to your auth flow

// After user logs in with ATProto
async function onUserLogin(atprotoSession) {
  const { did, handle } = atprotoSession;
  
  // Register with Glowrm
  const response = await fetch(
    `${GLOWRM_API_URL}/v1/identities/register`,
    {
      method: 'POST',
      headers: {
        'Authorization': `Bearer ${GLOWRM_API_KEY}`,
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({ did, handle, appId: 'my-app' })
    }
  );
  
  const userData = await response.json();
  // userData = { reputation: 50, spaState: {...} }
  
  return userData;
}

4. Check units before actions

async function getUserUnits(did) {
  const response = await fetch(
    `${GLOWRM_API_URL}/v1/spa/${did}/state?appId=my-app`,
    {
      headers: { 'Authorization': `Bearer ${GLOWRM_API_KEY}` }
    }
  );
  
  const spaState = await response.json();
  // { unitsRemaining: 12, unitsTotal: 15, periodEndsAt: "..." }
  
  return spaState;
}

5. Report interactions

async function reportMatch(userDid, matchedDid) {
  await fetch(`${GLOWRM_API_URL}/v1/trust/events`, {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${GLOWRM_API_KEY}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      subjectDid: matchedDid,
      actorDid: userDid,
      appId: 'my-app',
      type: 'positive_interaction',
      notes: 'Users matched'
    })
  });
}

Best Practices

Report interactions proactively:

• Matches/connections: positive_interaction
• Messages exchanged: positive_interaction
• User reports someone: report with severity
• User blocks someone: block

Display reputation tastefully:

// Don't show exact scores to users
// Instead, use ranges or indicators
function reputationBadge(score) {
  if (score >= 70) return { text: "Trusted", color: "green" };
  if (score >= 50) return { text: "Verified", color: "blue" };
  if (score >= 30) return { text: "New", color: "gray" };
  return { text: "Flagged", color: "red" };
}

Reference Implementations

FAQ