Glowrm
Trust infrastructure for ATProto social applications. Apps plug in for cross-app reputation, shared moderation, and a configurable resource-allocation system — the trust plumbing nobody should have to rebuild from scratch.
What it does
Think of Glowrm as Stripe for reputation. Instead of every dating app, professional network, or friendship platform building its own trust and moderation systems, apps plug into Glowrm to share a common reputation layer.
- Cross-app reputation. User trust scores on a 20–80 scale that travel between apps. Good behavior on a dating app means you start with that same reputation on a professional network.
- Shared moderation. When someone gets reported on one app, it affects their reputation across the network. Bad actors can’t platform-hop into a clean slate.
- Resource allocation (SPA). A configurable system that caps how many people a user can contact per period. Each app picks its own units, count, and refresh cadence.
- Identity registry. Maps ATProto DIDs to apps, tracks verification status, lets apps query each other’s coverage without storing each other’s user data.
The problem it solves
ATProto gives users portable identity — your DID and profile follow you across apps, you own your data, no app can lock you in. The trade-off 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. You trade freedom for safety.
Glowrm enables both: users keep the freedom to move between apps, and reputation follows them. Accountability without lock-in.
How it works in practice
Trace what happens when two apps both speak Glowrm.
- Alice signs into YGF with ATProto. YGF tells Glowrm to register her DID. Glowrm creates an identity record, starts her reputation at
50, gives her fifteen jars for the week. - Alice sends five jars to Bob. YGF asks Glowrm to deduct five units. Balance:
10. - Bob and Alice match. YGF reports a
positive_interaction. Both reputations tick up by one. - Alice reports Bob for harassment. YGF posts a high-severity trust event. Bob’s reputation drops three points and the event flags for admin review.
- Bob is banned on YGF. Admin issues a global ban through Glowrm. His reputation drops to
20; his status becomesbanned, network-wide. - Bob tries to join Roster, a professional network. Roster asks Glowrm to register his DID. Glowrm finds the existing identity, returns
{ reputation: 20, status: "banned" }. Roster declines. - Alice joins Roster. Glowrm returns
{ reputation: 51, status: "active" }. Roster shows her as a trusted user from day one.
Alice’s good behavior on YGF gave her a head start on Roster. Bob’s bad behavior on YGF kept him out. Neither app had to build that coordination — Glowrm did.
Reputation scores (20–80)
The scale is borrowed from baseball scouting. 50 is average. Scores cluster around the middle; outliers at either extreme are rare and meaningful.
Scoring is designed to be hard to game. Multiple low scores are required to move a rating; outliers are dropped; recent events weigh more; reports from trusted users count for more.
Trust events
Every consequential interaction posts a trust event. The vocabulary is small on purpose.
| Event | Impact |
|---|---|
| Positive interaction (match, conversation, completed transaction) | +1 (capped at +15 from this source) |
| Report — low severity | −1 |
| Report — medium severity | −2 |
| Report — high severity | −3 |
| Block | −3 |
| Warn / suspend | weighted |
| Ban | sets to 20 |
Strategic Profile Allocation (SPA)
Unlimited actions invite spam. Tinder-style swiping creates a spray-and-pray default. LinkedIn InMail becomes a sales pitch fire hose. SPA fixes that at the infrastructure layer: every app issues users finite units per period, and recipients see how many units someone spent on them. The cost is the signal.
Each app configures its own SPA shape:
| App | Units | Name | Period | Variable? |
|---|---|---|---|---|
| YGF (dating) | 15 | jars | 7 days | Yes (1–10) |
| Roster (professional) | 10 | credits | 30 days | Yes (1–5) |
| Roomies (roommate) | 20 | waves | 14 days | No (1 only) |
Data separation
Glowrm holds the trust layer and nothing else. Profile content lives in the user’s ATProto repo; conversations and matches live in the calling app’s database; Glowrm sees only DIDs, scores, events, and unit allocations.
- Profile, photos, bio
- User’s ATProto repo · user controls
- Messages, matches
- Calling app’s database · app controls
- Reputation score
- Glowrm
- Trust events
- Glowrm
- Unit allocations
- Glowrm
- Verification status
- Glowrm
The separation is the design: users own their content (ATProto principle), apps own their unique features, Glowrm owns the shared trust layer. No single point of failure for user data.
Reference implementations
Three apps were sketched against the Glowrm API to demonstrate the delegation model end-to-end. Each picks its own SPA shape — different units, different cadence, different rules — but speaks the same trust layer underneath.
What Glowrm is not
- A dating app or social app itself.
- A payments rail.
- A single-app backend.
- A profile data store. That lives in users’ ATProto repos.
Status
Glowrm is a working spec with a published API, three reference implementations, and a documentation site. It’s the trust plumbing that YGF sits on top of and that Roster and Roomies are designed against. The harder work — operating a real trust clearinghouse at scale (governance, appeals, due-process, regulatory standing) — is what the spec is in service of arguing about.