Building on Living Ground

Abstract

Theory without practice is speculation; architecture without construction is drafting. The Myceloom Protocol articulates principles of digital sovereignty, reciprocity, and emergent intelligence. What does this mean when choosing a platform, joining a community, or adopting a tool? This report translates Myceloom's philosophical foundations into an actionable decision framework for digital citizens navigating contemporary infrastructure.

Through four domains (Identity, Community, Tools, and Contribution), we present assessment criteria, evaluation questions, and practical orientations grounded in the protocol's core axioms. The framework synthesizes into Seven Questions that structure attention toward ownership, exit viability, governance legibility, extraction patterns, interoperability, reciprocity, and sustainability. This framework provides a lens: a way of seeing digital situations that makes sovereignty, community health, and long-term viability visible. The result is an orientation: a practiced way of inhabiting digital space that changes what becomes visible, what becomes possible, and what becomes necessary.

I. The Practice Problem

Every framework faces the challenge of translation.

Articulating principles of sovereignty and reciprocity is one matter. Knowing what to do on a Tuesday afternoon when choosing a platform is another. Theory orients; practice demands decision.

The Myceloom Protocol offers resources: philosophical foundations, governance models, and biological analogies.¹ But it lacks terrain maps for daily choice. We must move from what it means to what it changes.

II. Identity and Presence

Identity concerns where digital presence lives, how it is constituted, and who controls it.

The Ground Audit

The Ground Principle holds that every person deserves digital ground they own—space that cannot be revoked.²

Audit existing digital presence. For each location, ask: Whose ground is this?

If a primary email is Gmail, Google owns the ground. Access is tenancy, not ownership. An address at an independently owned domain approaches ownership.

Apply this widely:

• Social profiles: Whose servers hold the data? Can it be exported?
• Creative work: Where do writings and projects live? Are they backed up on controlled ground?
• Professional identity: Does a career hinge on an unowned profile?
• Communication: Do direct contact paths exist independent of platforms?

Most digital presences spread across ground with varying degrees of ownership. The purpose is visibility: seeing clearly the dependencies digital life has accumulated.

The Autogravitas Criterion

Beyond location, we must weigh the quality of presence: is authority inherent or borrowed?

Autogravitas is self-weight—authority derived from action and relationship. Heterogravitas is borrowed weight—authority conferred by platforms.³

Where does authority come from?

A platform checkmark is heterogravitas. A reputation built through consistent contribution is autogravitas.

• Build portable reputation: Contribute in ways that create visible records.
• Diversify authority sources: Rest on multiple domains of recognized contribution.
• Own verification: Use identity systems under personal control.
• Invest in relationships: Follower counts are borrowed; mutual relationships are owned.

Ensure borrowed authority rests on inherent authority. If external validation disappeared tomorrow, the digital presence must still stand.

The Portability Test

For any significant element of digital presence: If this had to move tomorrow, could it?

• Email: Can it redirect to a new address?
• Website content: Is it in movable formats?
• Social connections: Do independent contact paths exist?
• Reputation: Is standing platform-specific?
• Data: Are exports available?

Portability measures sovereignty. What cannot move is not owned.

III. Community and Governance

The second domain concerns community: where people gather, how gatherings are governed, what power participants hold.

The Governance Legibility Assessment

Governance frameworks require transparency and subsidiarity.⁴ Invisible governance is unaccountable governance.

For any community, identify the mechanics of power:

• Who decides? Identify the people or processes making significant decisions.
• How are decisions made? Look for legible processes—voting, consensus, discussion.
• What voice exists? Can members propose changes or contest outcomes?
• What recourse exists? Are there appeals or accountability mechanisms?
• Who benefits? Does governance serve community interests or external parties?

Twitter/X has opaque governance. A well-run Mastodon instance typically has clear rules and identified moderators.

We do not demand perfect democracy. We demand visibility. Know how power works so evaluation becomes possible.

The Subsidiarity Evaluation

Decisions should be made at the lowest level capable of effective action.⁶

For decisions affecting a community: At what level is this decision made, and is that the right level?

A global platform moderating locally fails subsidiarity. A federated system lets communities set their own standards while sharing infrastructure. This respects subsidiarity.

• Prefer locally-governed communities: Governance should happen close to the community.
• Attend to federation structures: Understand the interaction between local and network-level governance.
• Diagnose level problems: Ask whether decisions are made too high (imposing uniformity) or too low (fragmenting coordination).

Subsidiarity is respect. It honors knowledge from proximity.

The Exit Viability Assessment

No one should be trapped. Systems must enable departure without devastation.⁷

For any community receiving significant investment: If departure became necessary, what would be lost?

• Social connections: Do independent relationships survive?
• Identity and reputation: Is standing portable?
• Content and history: Can contributions leave too?
• Skills and knowledge: Are capabilities transferable?

Exit viability disciplines communities—they must earn continued participation.⁸

• Maintain outside relationships: Preserve connections independent of the community.
• Keep portable records: Export what can be exported; capture what cannot.
• Diversify participation: Avoid letting any single community become so central that departure is unthinkable.
• Evaluate lock-in costs early: Understand the price of leaving.

IV. Tools and Platforms

The third domain concerns tools: the platforms, software, and services mediating digital life.

The Extraction Analysis

Distinguish extractive architectures (capturing value from users) from generative architectures (creating value with users).⁹

For any significant tool or platform: What is extracted, and by whom?

• Attention: Does the tool optimize for user goals or for engagement?
• Data: What is collected? Who benefits?
• Content: Who owns what is created?
• Network: Is relationship value captured and monetized?
• Labor: Is uncompensated moderation or curation benefiting the platform?

Extraction-free options rarely exist. We demand seeing extraction clearly.

• Audit the tool ecosystem: Map significant tools.
• Prefer less-extractive alternatives: Open-source, paid, and self-hosted services often extract less.
• Reduce extraction points: Consolidate used platforms.
• Compensate with protection: Use privacy tools and separate contexts.

The Interoperability Criterion

Tools should work together without requiring uniformity.¹⁰

For tools handling significant data or relationships: Does this work with other systems, or does it create silos?

• Data formats: Are standards open or proprietary?
• Export capabilities: Is data extractable and usable?
• API access: Can other tools interact programmatically?
• Federation: Can interaction cross platform boundaries?

Interoperability is sovereignty infrastructure. Only interoperable tools respect the ability to move; silos create lock-in.

• Prefer open standards: Markdown over proprietary formats.
• Test exports: Verify export usability before committing.
• Value federation: Choose services compatible with ActivityPub.
• Avoid format lock-in: Create content in portable formats.

The Resilience Audit

Resilience relies on distribution, redundancy, and graceful degradation.¹¹

For an overall tool ecosystem: What happens when things fail?

• Single points of failure: Do dependencies cascade?
• Backup coverage: Is data backed up separately?
• Alternative paths: Are alternatives available?
• Degraded functionality: Can essential tasks still be done in failure states?

Resilience is prudence. Services fail. Platforms disappear.

• Map dependencies: Find single points of failure.
• Create redundancy: Redundant backups, redundant paths.
• Practice recovery: Test backups and exports.
• Prefer distributed over centralized: Distributed architectures rarely fail completely.

V. Contribution and Reciprocity

The fourth domain concerns contribution: participation in the commons, what is given to networks providing benefit, how reciprocity operates.

Reciprocity Accounting

Sustainable networks depend on mutual contribution. Those who take without giving exhaust the commons.¹²

For networks and communities providing benefit: What is being contributed?

Contributions take many forms:

• Content: Creating original work.
• Curation: Organizing and recommending.
• Feedback: Responding to others' work.
• Maintenance: Keeping communities functioning.
• Moderation: Resolving conflicts.
• Financial support: Sustaining infrastructure.
• Documentation: Making knowledge accessible.
• Hospitality: Welcoming newcomers.

Reciprocity does not demand equality. It requires some contribution, scaled to capacity.

• Audit participation: Is the balance reasonable?
• Identify unique contributions: Offer what others might not.
• Sustain dependencies: Contribute to the sustainability of essential infrastructure.
• Accept imperfect reciprocity: Look for the pattern over time, not transaction-by-transaction equality.

The Attribution Practice

Acknowledge the contributions that work builds on.¹³

For work building on others' contributions: Is what has been received being acknowledged?

Attribution is infrastructural. Acknowledged contributions make contributors visible. Visible contributors build reputation. Growing reputation feeds the commons.

• Cite sources: Acknowledge ideas, frameworks, and information.
• Credit collaborators: Invisible collaboration benefits no one.
• Link to original sources: Bypass intermediaries.
• Acknowledge infrastructure: Tools and platforms are contributions too.

The Sustainability Assessment

Commons require care. They do not maintain themselves.¹⁴

For communities and commons depended upon: Is this sustainable?

• Maintainer burden: Are maintainers burning out?
• Funding model: Is funding secure?
• Succession planning: Is knowledge documented?
• Growth dynamics: Is growth overwhelming governance?
• Conflict resolution: Is conflict accumulating?

When an unsustainable community fails, all who depend on it are affected.

• Support sustainability: Contribute effort, funding, or attention.
• Avoid dependence on the unsustainable: Develop alternatives before crisis.
• Contribute to succession: Document practices and mentor newcomers.
• Address conflicts: Unresolved tensions drain capacity.

VI. Integration

The domains of identity, community, tools, and contribution are not distinct; they are facets of a single digital existence. An integrated orientation inhabits these questions simultaneously.

The Seven Questions

1. Whose ground is this?
   Identify ownership. Whose servers? Whose rules? The answer shapes what is possible.
2. Is exit viable?
   If departure is unthinkable, sovereignty is absent.
3. How does power work here?
   Who decides? How? Illegible power is unaccountable power.
4. What is being extracted?
   Attention, data, content, labor. Visible costs enable informed choice.
5. Is this interoperable?
   Can it move? Interoperability is sovereignty infrastructure.
6. What is being contributed?
   Is it proportional to what is received? Sustainable networks require mutual contribution.
7. Is this sustainable?
   Can this persist? What supports its continuation?

These questions do not determine answers; they structure attention. They are a lens—a way of seeing digital situations that makes sovereignty, community, and sustainability visible.

Orientation in Practice

• Before joining: Assess ground, governance, and exit.
• Before creating: Consider attribution and portability.
• Before investing: Evaluate sustainability.
• Periodically: Review digital presence.
• Continuously: Make reciprocity practice, not afterthought.

This orientation is not about perfection. It is about direction. Progress, not purity.

VII. What Changes

What becomes visible: Ownership structures. Extraction models. Governance mechanisms. Exit costs. Sustainability risks. These are not new features; they are old features newly illuminated. Visibility enables choice.

What becomes possible: Visible extraction can be reduced. Visible lock-in can be avoided. Visible governance failures prompt seeking alternatives. Myceloom does not create these possibilities; it reveals them.

What becomes necessary: Once extraction is seen, it cannot be unseen. Once alternatives are known, their absence is choice. Myceloom creates obligation: the weight of knowing things could be otherwise.¹⁴

This is the practice problem resolved through orientation. The Myceloom Protocol asks: Does this serve sovereignty or extraction? Does this enable cooperation or capture? Does this sustain the commons or deplete them?

Build on living ground. The network holds those who participate—but only if they help it hold together.