Glowrm
Trust infrastructure for ATProto social applications. Apps plug in for cross-app reputation, shared moderation, and a configurable resource-allocation system, so apps share one set of trust plumbing.
What it does
Dating apps, professional networks, and friendship platforms plug into Glowrm to share one reputation layer for trust and moderation.
- Cross-app reputation. User trust scores on a 20 to 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, and no app can lock you in. The trade-off is that someone banned from one dating app can join another with a clean slate, and someone who harasses people can switch platforms and start fresh, so bad behavior carries no long-term consequences.
Traditional platforms solve this with centralized control. If Facebook bans you, you’re banned everywhere Facebook operates, and you’re also locked into Facebook’s ecosystem, which trades your freedom for safety.
Glowrm lets users move freely between apps while their reputation follows them.
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, and 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 kept him out, and Glowrm handled that coordination for both apps.
Reputation scores (20 to 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 defaults to spray-and-pray, and LinkedIn InMail turns into a fire hose of sales pitches. 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.
Each app configures its own SPA shape:
| App | Units | Name | Period | Variable? |
|---|---|---|---|---|
| YGF (dating) | 15 | jars | 7 days | Yes (1 to 10) |
| Roster (professional) | 10 | credits | 30 days | Yes (1 to 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
No single store holds all of a user’s data: content belongs to the user, features to each app, and the shared trust layer to Glowrm.
Reference implementations
Three apps were sketched against the Glowrm API to show the delegation model end to end. Each picks its own SPA shape, with its own units, cadence, and rules, and all three use the same trust layer underneath.
Outside its scope
- 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 spec is there to make concrete the harder work of operating a real trust clearinghouse at scale: governance, appeals, due process, and regulatory standing.