Glowrm — Trust & Relationship Layer
Portable trust primitives for decentralized social environments—how identity, reputation, and consent travel across networks.
The Core Problem
Social platforms collapse trust, identity, and moderation into a single service’s control. When you move to a new platform, you start from zero:
- No reputation history
- No verification credentials
- No interaction context
- No trust signals from previous communities
Worse, there’s no way to route trust between spaces. A community vouching for you in one place doesn’t travel. References and reputation are trapped in silos.
What Glowrm Does
Glowrm is infrastructure for trust that travels. It provides lightweight primitives for:
1. Identity Verification
- Portable credentials (not locked to one platform)
- Multi-source verification (domain ownership, social proof, community attestations)
- Cryptographic signatures for tamper-proof claims
- Granular disclosure (prove attributes without revealing data)
2. Reputation Tracking
- Interaction history that users control
- Community vouches and endorsements
- Negative signals (blocks, reports) with context
- Reputation scores across dimensions (reliability, expertise, civility)
3. Consent & Boundaries
- Persistent preference declarations (communication style, boundaries)
- Context-aware consent (different rules for different spaces)
- Revocable permissions (pull access back when trust breaks)
- Transparent data flows (who sees what, when, why)
4. Trust Routing
- How do vouches from one community inform decisions in another?
- Can endorsements be weighted by relationship strength?
- How do negative signals propagate without becoming permanent scarlet letters?
- What happens when trust networks conflict?
Design Principles
Portable, Not Platform-Locked
Trust data lives with the user, not the platform. You can take your reputation, credentials, and interaction history anywhere AT Protocol is supported.
Granular & Context-Aware
Trust isn’t binary. Glowrm supports:
- Different trust levels for different contexts
- Relationship-specific permissions
- Time-bounded credentials
- Conditional visibility
Transparent & Auditable
Users can see:
- Who vouched for someone (and why)
- What data is being shared (and with whom)
- How reputation scores are calculated
- When/why trust signals changed
User-Controlled
You decide:
- What credentials to share
- Which communities can vouch for you
- How your reputation travels
- When to revoke access
Use Cases
Moderation Tooling
Communities can:
- Check if a new member has community vouches
- See interaction history across networks
- Route trust signals from allied spaces
- Apply graduated moderation based on reputation
Example: A forum checks if applicants have endorsements from trusted communities, reducing cold-start spam/harassment.
Safe Onboarding
New platforms can:
- Accept portable verification instead of starting from zero
- Trust vouches from established networks
- Apply reputation-based permissions (e.g., new users can read but not post until vouched)
Example: A dating app (like HeyPBJ) uses Glowrm credentials to verify identity and check for safety flags across networks.
Consent Management
Users can:
- Declare communication preferences that follow them
- Set boundaries that platforms must respect
- Revoke permissions if trust breaks
- See who accessed their data and when
Example: A user sets “no unsolicited DMs” as a persistent preference; compatible platforms enforce this automatically.
Trust-Based Discovery
Matching/routing systems can:
- Weight compatibility by mutual connections
- Use vouches as signals for quality
- Route people toward communities where they’re already trusted
- Reduce cold-start problems in social discovery
Example: HeyPBJ uses Glowrm trust scores to prioritize matches where mutual friends have vouched for both parties.
Technical Architecture
AT Protocol Foundation:
- Decentralized identity (DIDs)
- User-controlled data repositories
- Cryptographic signatures for attestations
- Composable schemas for trust primitives
Trust Primitives (Data Structures):
- Credentials: Portable identity claims (verified email, domain ownership, community membership)
- Attestations: Third-party vouches (endorsements, references, community approvals)
- Interaction Records: Encrypted logs of connection history
- Reputation Scores: Multi-dimensional trust metrics
- Consent Declarations: Portable preference/boundary records
Services:
- Verification Service: Cryptographically validate credentials
- Reputation Aggregator: Compute trust scores from multiple sources
- Trust Router: Determine how signals propagate between networks
- Consent Enforcer: Check if actions respect declared boundaries
Privacy Layer:
- Zero-knowledge proofs for selective disclosure
- Encrypted interaction logs (only participants can decrypt)
- Relationship-scoped visibility (different people see different data)
- Revocable access controls
How It Works: Example Flow
-
User joins new community:
- Presents AT Protocol DID (decentralized identity)
- Shares relevant credentials (e.g., “verified member of X community since 2023”)
- Community checks Glowrm for reputation/vouches
-
Community evaluates trust:
- Sees endorsements from allied spaces
- Checks interaction history for red flags
- Applies graduated permissions based on trust level
- Grants access or requests additional verification
-
Trust signals accumulate:
- As user interacts, reputation updates
- Community members can vouch/endorse
- Positive signals increase access/privileges
- Negative signals trigger review/moderation
-
User moves to another space:
- Brings full trust history (portable)
- New community can reference previous vouches
- User controls what’s disclosed
- Trust doesn’t restart from zero
Research Questions
Glowrm explores:
- Can portable reputation reduce cold-start problems without creating permanent records?
- How do trust networks interact when they have conflicting signals?
- What consent primitives are needed for decentralized social spaces?
- Can cryptographic proofs enable privacy-preserving verification?
- How do we prevent reputation marketplaces or gaming?
Integration with Other Projects
HeyPBJ (Matching Platform)
Uses Glowrm for:
- Identity verification in dating/social rundles
- Safety checks (cross-network reputation)
- Trust-weighted compatibility scoring
- Consent enforcement (communication preferences)
Leafroll (Professional Identity)
Uses Glowrm for:
- Endorsement verification (are these references real?)
- Skill attestations from collaborators
- Trust routing for hiring/collaboration
- Reputation portability across professional networks
Occupant (AI Benchmarks)
Could use Glowrm for:
- Contributor verification (who’s submitting data?)
- Community moderation (trusted contributors vs. spam)
- Peer review attestations
Part of the AT Protocol Suite
Glowrm is one of several interconnected projects exploring decentralized infrastructure:
- AT Protocol Projects (Parent project)
- HeyPBJ (Matching platform)
- Leafroll (Professional identity)
- Occupant (Public data infrastructure)
What This Demonstrates
- Decentralized trust infrastructure: Building reputation systems that don’t require centralized platforms
- Portable identity primitives: Proving credentials and reputation can travel across networks
- Privacy-preserving verification: Using cryptography to prove claims without revealing data
- Context-aware consent: Designing granular permission systems for decentralized spaces
- Trust routing: Solving how vouches and reputation propagate between communities
- Moderation tooling: Creating safety infrastructure that works across platforms
- User sovereignty: Giving people control over their trust data and how it’s shared