Prosocial and Relational Ecosystem Use Cases

A comprehensive, platform-agnostic taxonomy of human activities that prosocial technology must support — organized by use-case domain, centered on trust, and designed for interoperability across the decentralized technology ecosystem.

A Platform-Agnostic Taxonomy for the Prosocial Technology Ecosystem

Introduction

Prosocial technology is technology designed to support human flourishing—strengthening the social fabric, enabling genuine coordination, and cultivating the conditions in which communities can thrive. At its heart, this means building not merely transactional trust (will you deliver what you promised?) but relational trust (will you show caring and concern for me even when it’s hard?). The experience layer describes what it feels like to be inside a community where technology scaffolds the conditions for trust to develop, deepens trust that exists, and repairs trust when it has been damaged.

The ecosystem architecture describes the same project from the protocol layer’s point of view. Its emphasis is on interoperability and interactability across apps and platforms. The backend requirements—P2P, federation, proof-of-humanity, data sovereignty, privacy preservation—map directly onto the sovereign, self-hosted features that relational trust requires. What this perspective adds is the critical recognition that no single prosocial platform can be a walled garden. The prosocial technology ecosystem will involve many apps and platforms, and the use cases need to describe what people do in ways that are platform-agnostic.

This is not a tension. It is a productive complementarity. The intersubjective vision brings the why and the felt experience. The interoperable architecture brings the how and the technical structure. The use cases serve both. They describe human activities—what people and communities actually do—at a level of abstraction that works whether the implementation is a single platform, a federation of instances, or a broader ecosystem of prosocial apps connected through shared protocols.

Specific platform implementations are instances of this broader taxonomy. They fit within an ecosystem framework that says: here are the things people and communities do, here is where interoperability matters, and here is how a given platform implements them. Other implementations will emerge. The use case layer should be durable across all of them.

Trust as the Organizing Principle

Every use case in this taxonomy exists because of trust. Some create conditions for trust to develop—verified identity, explicit agreements, safe communication channels, group formation practices. Some protect trust that has developed—privacy controls, data sovereignty, confidentiality infrastructure, circle consciousness. Some repair trust when it has been damaged—rupture and repair pathways, conflict navigation, slow decision architecture that prevents the brittle speed that fractures relationships.

The trajectory from transactional trust to relational trust is the foundational process that every prosocial technology must support. In the early stages of any relationship or group, trust is transactional: I do for you, you do for me, and we’re both watching. As trust accumulates through enough experience—including, crucially, rupture and repair—the watching relaxes. The transition from calculating to trusting is where mutuality lives, where belonging becomes felt, where collective wisdom becomes possible. The use cases below describe the human activities through which that transition happens.

This trust-centered framing clarifies what distinguishes the prosocial technology ecosystem from every existing platform. Existing platforms build transactional trust to facilitate commerce and content exchange. They have almost nothing to say about relational trust. The entire taxonomy below addresses that gap.

Triage, Transition, Long Term

This taxonomy operates on three timelines simultaneously, and each use case can be understood in terms of all three:

  • Triage. What can be shipped now on available technology—Discourse, Nostr, Matrix, self-hosted servers—to give communities safe, secure ways to have conversations that matter? The taxonomy identifies which human activities are most urgent and most achievable with existing tools. We ship now, broken and partial, and learn from what happens.

  • Transition. What must be designed for migration to decentralized architectures? The interoperability notes on each use case identify where platform lock-in is the risk and where emerging standards (Trust over IP, AT Protocol, Holochain) provide the path forward.

  • Long term. What does the mature prosocial technology ecosystem look like? The taxonomy as a whole is the answer—a comprehensive set of human activities that any platform in this space would need to support, with interoperability as a first-class concern, so that no community is ever dependent on a single product.

Three Dimensions of the Project

Three dimensions cohere across this project:

  • The intersubjective vision: why this matters, what trust between people actually is, how the process of secure attachment works, and what it feels like when technology supports rather than undermines it. This is the soul of the project.

  • The ecosystem architecture: why this is bigger than one product, what the full range of human activities looks like, where interoperability is essential, and how the triage/transition/long-term framework applies. This is the skeleton that makes the soul scalable.

  • Platform implementations: where both dimensions meet the ground—specific applications that instantiate the ecosystem vision in working software. This is the body.

Prosocial Technology Use Cases

A comprehensive taxonomy of functions that people and communities perform, organized by domain. These are platform-agnostic—they describe human activities, not software features. Each could be implemented in a single platform, in a federated ecosystem of prosocial apps, or across interoperable platforms connected through shared protocols. Backend architecture (P2P, federation, proof-of-humanity, data sovereignty, privacy preservation) and frontend design (prosocial principles, anti-addiction, relational awareness) are implementation concerns that apply across all of them.

Where a use case requires interoperability across platforms or apps, this is noted. The trust function of each domain is identified: whether it primarily creates conditions for trust, protects existing trust, repairs damaged trust, or deepens trust through relational practice.

1. Identity and Trust

Trust function: Creates the conditions for trust to develop. Without verified identity, real presence, and data sovereignty, relational trust has no ground to stand on.

  • 1.1 Establish Verified Human Identity — A person proves they are a real human being without surrendering personal data to a centralized authority. This is the first condition for relational trust: knowing that the person across from you is a person. Verification is not a one-time event—ongoing attestation protects against impersonation and ensures that communications actually come from who they claim to come from. Requires proof-of-humanity protocols. Interoperability: identity must be portable across platforms.

  • 1.2 Create Context-Dependent Profiles — A person maintains different presentations of themselves for different relational contexts—not personas for manipulation but genuine facets of who they are in different settings. This honors the commitment to come with real identity while recognizing that who we are shifts with context.

  • 1.3 Vouch for Another Person’s Capabilities — A person stakes their own relational credibility to attest to another person’s skills, character, or reliability. Trust travels through relationships, not through ratings. Vouching is an act of relational trust—you are putting your own trustworthiness on the line. Interoperability: vouches should be legible across platforms.

  • 1.4 Manage Personal Data Sovereignty — A person controls where their data lives, who can access it, and how it is used. Data can be exported, migrated, or deleted at any time. This includes the active exercise of data rights: requesting access to one’s own data, correcting inaccurate records, and requesting deletion—not just as regulatory compliance but as a relational practice of maintaining sovereignty over one’s own story. Trust requires knowing that your vulnerability will not be exploited. Interoperability: data portability across platforms is essential.

  • 1.5 Establish and Manage Trust Relationships — Two or more people or groups establish explicit trust parameters for sharing data, communication, or collaboration. This includes the assessment step that precedes trust extension: before sharing identity or data with a platform or service, a person can verify that it participates in a recognized trust network and meets the standards the person requires. Interoperability: trust relationships must be recognizable across federated instances.

  • 1.6 Confirm Cross-Context Identity — A person recognizes and connects with someone they already trust across platform boundaries. This is relational continuity—the human activity of saying “I know this person from another context and I want that trust to carry over.” Interoperability: cross-platform identity recognition is a core requirement.

  • 1.7 Maintain Identity Resilience — A person’s relational history and trust relationships survive the failure or loss of a platform they were using. This extends data sovereignty into the unplanned-loss scenario. Interoperability: portable identity and relationship records across platforms.

  • 1.8 Ensure Age-Appropriate Access — Spaces accessible to minors are bounded, verified, and governed with appropriate safeguards. A community that protects its most vulnerable members demonstrates the kind of care that deepens trust for everyone.

2. Communication

Trust function: Protects trust through privacy and consent; deepens trust through communication modes designed for relational depth rather than performance.

  • 2.1 Send Private Messages — One-to-one communication with end-to-end encryption and mutual control over content sharing. Interoperability: messaging across platforms using shared protocols (Matrix, Nostr).

  • 2.2 Communicate Within a Bounded Group — Post, discuss, and share within a group that has explicit membership and privacy boundaries. Multiple communication modes—standard, exploratory, partial thought—support the safety to think out loud without being held to rough drafts.

  • 2.3 Share Content With Chosen Audiences — Publish text, photos, video, documents, or blog posts with explicit control over which circles or publics receive it. No algorithmic amplification. Content can be archived with context—marked as reflecting a past position rather than a current one—because people are allowed to grow beyond what they once said.

  • 2.4 Publish to External Audiences — Produce and distribute content (journalism, reports, media, event promotions) to people outside the community through controlled channels.

  • 2.5 Communicate Across Platforms — Send and receive messages, posts, and shared content between users on different prosocial platforms or protocol implementations. Interoperability: this is the core interactability requirement.

  • 2.6 Search and Discover Content — Find relevant posts, discussions, media, documents, and knowledge across one’s own community and, where permissions allow, across federated communities. No algorithmic ranking—relational proximity and intentional search.

3. Group Formation and Governance

Trust function: Creates the container within which trust can develop. The agreements that constitute a group are the behavioral commitments that make relational trust possible.

  • 3.1 Form Small Groups — People self-organize into small groups (4–7) with shared purpose and explicit agreements. The act of forming—defining shared purpose through dialogue rather than directive—is itself the first practice of mutuality.

  • 3.2 Discover and Join Groups — Find groups that match your interests, values, location, or relational connections. Discovery is relational, not algorithmic.

  • 3.3 Establish and Revise Group Agreements — A group collaboratively defines and periodically revisits its norms, commitments, and expectations. These are not rules imposed from above but promises made among equals.

  • 3.4 Make Group Decisions — Navigate decisions through deliberate processes: proposal, reflection, refinement, resolution. Slow decision architecture with dissent pathways.

  • 3.5 Steward a Group — A designated person tends to the group’s relational health, facilitates process, manages membership transitions, and holds the center of mass.

  • 3.6 Federate Groups Across Communities — Groups in different communities or on different platforms connect, share, and collaborate while maintaining sovereignty. Interoperability: federation protocols, inter-instance trust handshakes, privacy boundary negotiation.

  • 3.7 Facilitate Structured Dialogue Across Difference — People who do not share starting assumptions engage in structured conversation designed to build understanding across difference rather than resolve it prematurely.

4. Relationship Development and Awareness

Trust function: Deepens and repairs trust through the relational practices that constitute the transition from transactional to relational trust.

  • 4.1 Build One-on-One Relationships — Intentionally develop a relationship over time with tools that make the connection visible and tend-able without gamification. The relationship belongs to the people in it, not the platform.

  • 4.2 Navigate Relational Rupture and Repair — Name and work through tensions, disagreements, and hurts with structured support. Repair is routine, not emergency—the commitment to repair is made in the group’s agreements before the rupture ever happens. This is the single most important use case in the taxonomy.

  • 4.3 Sense the Collective Field — Attune to the state of a group as a whole: relational patterns, emotional weather, coherence, energy shifts.

  • 4.4 Acknowledge Relational Evolution — Recognize how people and relationships have changed over time. Honor growth without locking people into past identities.

  • 4.5 Practice Discernment About Attention — Make conscious choices about where to place attention. No algorithmic feed. Intentional navigation. Anti-addiction design.

  • 4.6 Engage in Shared Presence — Come together with minimal or no agenda for the practice of being present together—silence, reflection, grounding, collective discernment.

5. Co-Creation and Knowledge

Trust function: Deepens trust through the experience of collective intelligence — discovering that the group can produce something no individual could have produced alone.

  • 5.1 Co-Create Shared Artifacts — Collaboratively produce documents, plans, research, art, or media. Interoperability: shared workspaces across platforms, portable artifact formats.

  • 5.2 Gather and Vet Information Collectively — Research, share, annotate, challenge, and corroborate information as a community. Track provenance.

  • 5.3 Build and Tend a Shared Knowledge Base — Accumulate, organize, and maintain collective learning over time—searchable, replicable, and governed by the community. Interoperability: knowledge bases should be exportable and federable.

  • 5.4 Conduct Collective Sensemaking — Interpret events, situations, and systemic conditions as a community rather than consuming narratives manufactured elsewhere.

6. Events and Coordination

Trust function: Extends trust from small groups into larger coordination — proving that relational trust scales through nested sovereignty rather than centralized control.

  • 6.1 Host Events (Online, In-Person, Hybrid) — Organize, invite, prepare, execute, and document events with relational grounding and privacy controls.

  • 6.2 Coordinate Local Projects — Organize people and resources around shared local initiatives with multi-dimensional impact tracking.

  • 6.3 Coordinate Across Scales — Local initiatives connect to regional strategies, which connect to continental and global coordination. Nested sovereignty: each level maintains autonomy while choosing to align. Interoperability: cross-scale coordination requires federated communication and shared sensemaking across platforms.

  • 6.4 Map Community Ecosystem — Visualize civic infrastructure, active projects, collaboration patterns, gaps, and resource flows. Interoperability: ecosystem maps should aggregate data across federated instances.

  • 6.5 Engage with Local Government — Translate digital community organization into in-person civic participation—attending hearings, submitting public comments, tracking legislative and regulatory processes, coordinating testimony.

7. Mutual Aid and Exchange

Trust function: Expresses trust through care — mutual aid is relational trust made tangible. The transition from transactional reciprocity (“I do for you, you do for me”) to genuine mutuality (“I care for you, you care for me”) is visible here.

  • 7.1 Request Aid from the Community — Express a need and receive support—material, practical, or relational—matched through relational proximity rather than algorithmic marketplace.

  • 7.2 Offer Aid and Capacities — Proactively make resources, skills, and time visible to the community.

  • 7.3 Offer and Receive Direct Services — One-on-one services (coaching, tutoring, repair, consultation) discovered through relational channels, not platform intermediation.

  • 7.4 Facilitate Gift and Barter Exchange — Support non-monetary exchange of goods, services, and resources within and across communities. Interoperability: exchange protocols that work across platforms without centralized ledgers.

  • 7.5 Track and Distribute Shared Resources — Manage community-owned resources (tools, spaces, vehicles, land, funds) with transparent governance. Interoperability: resource registries across federated communities.

8. Learning and Development

Trust function: Develops the human capacities that make trust possible — perspective-taking, vulnerability, repair, emotional responsiveness.

  • 8.1 Participate in Collaborative Learning — Courses, workshops, study groups, and skill-sharing organized within relational containers.

  • 8.2 Develop Relational Capacities — Structured or emergent practice of the developmental markers of mutuality: perspective-taking, vulnerability, repair, emotional responsiveness, transition from reciprocity to mutuality.

  • 8.3 Mentor and Be Mentored — Asymmetric relational development with tools that honor the relationship rather than the hierarchy.

  • 8.4 Track Personal and Group Development — Reflect on and record developmental trajectories over time—not as external metrics but as self-directed awareness of growth.

9. Platform Evolution and Sovereignty

Trust function: Ensures that the technology itself is trustworthy — that communities are sovereign over their own infrastructure, that AI serves human connection rather than surveillance, and that no community is ever locked into a dependency it did not choose.

  • 9.1 Self-Host Community Infrastructure — Community owns and operates its own server, data, and governance. No dependence on corporate platforms. Interoperability: self-hosted instances must be able to federate.

  • 9.2 Participate in Platform Design — Community members experiment with, evaluate, and improve the tools they use.

  • 9.3a Engage Individual AI Augmentation — A person electively uses AI to support personal relational awareness, reflection on their own patterns, or individual developmental insight—with full control over access and data.

  • 9.3b Engage Collective AI Augmentation — A group electively uses AI to support collective sensemaking, collaborative work, or group-level pattern recognition—with group-consented access to shared relational data.

  • 9.4 Measure Impact Multi-Dimensionally — Assess community health across relational, civic, economic, and ecological dimensions without reducing to single metrics. Interoperability: impact data should be aggregable across federated instances for ecosystem-level assessment.

  • 9.5 Migrate Between Platforms — Move identity, data, relationships, and content from one platform to another without loss. Interoperability: this is the ultimate test of data sovereignty.

  • 9.6 Bridge Web2 and Web3 — Support communities currently on centralized platforms in migrating to decentralized architectures incrementally—without requiring everyone to understand cryptographic key management on day one.

10. Place-Based Mapping and Ecosystem Awareness

Trust function: Creates conditions for trust by making visible the shared geography, shared resources, and shared challenges that give people concrete reasons to coordinate. Trust between people deepens when they can see what they share.

  • 10.1 Map Community Capacities and Needs — Maintain a living picture of what a community has and what it needs—skills, resources, spaces, tools, knowledge, and gaps. Interoperability: capacity maps should be legible across federated communities.

  • 10.2 Map Practitioner and Coach Communities — Locate people who can help—coaches, facilitators, therapists, mediators, mentors—organized by approach, relationship, and relational proximity rather than by directory categories.

  • 10.3 Map Regenerative Projects and Land Initiatives — See how restoration work, food systems, and land stewardship connect geographically so coordination becomes possible. Interoperability: project registries across federated communities.

  • 10.4 Map Civic and Jurisdictional Infrastructure — Understand the governance structures that affect your community—municipal boundaries, school districts, water authorities, legislative districts, regulatory jurisdictions—so you can engage effectively.

How to Use This Taxonomy

For the technical community: it provides the comprehensive, well-structured, platform-agnostic use case list that ecosystem partners need. Each use case describes a human activity, not a software feature. The interoperability notes identify where cross-platform protocols are essential.

For platform builders: it provides the bridge between the intersubjective vision and the architectural thinking. Every use case in the taxonomy has a human reason for existing—it serves trust, mutuality, belonging, wisdom, or sovereignty. And every use case has a technical requirement—it needs to work across platforms, preserve privacy, support data sovereignty, and resist centralized control.

Specific platform implementations are instances of this broader taxonomy. They should be referenced from it but not collapsed into it. The taxonomy is the ecosystem map. Each platform implementation is the walking directions for one trail.