Foundational
Companion to:
This document defines the Pancakes node as the fundamental operational unit of the ecosystem.
A node is simultaneously:
Nodes allow individuals and communities to operate Pancakes locally while retaining authority over their own data, policies, services, and institutions.
This document explains:
It intentionally does not define:
Those topics are described elsewhere.
Pancakes is designed to be more than a hosted web service.
Official hosted deployments provide a convenient way for many people to begin using the ecosystem, but they are not the architectural center of Pancakes.
The architecture assumes that households, cooperatives, schools, clinics, communities, and other organizations should be able to operate their own instances using the same software.
This reflects several recurring design principles.
Communities should be able to govern themselves.
A household should not depend upon a distant platform operator to determine membership, permissions, or local policies.
Nodes provide a practical home for local self-governance.
Many Pancakes applications manage deeply personal information.
Examples include:
Whenever practical, that information should remain under the stewardship of the people and communities who produce it.
A community should retain meaningful control over:
Hosted deployments may provide convenience, but they should not become the only place where Pancakes can exist.
Nodes are not simply servers.
They are institutions entrusted with the care of people, services, and shared memory.
The architecture therefore treats stewardship as a first-class design concern.
Healthy communities should continue functioning despite changes in vendors, organizations, technologies, or funding.
Nodes support resilience through:
A Pancakes node is a locally governed computational community.
It provides a shared home for people, services, data, and applications within a defined social boundary.
A node may represent:
Every node combines technical infrastructure with institutional responsibility.
It is simultaneously:
The node does not replace human relationships.
It supports them.
Every node is responsible for providing a stable operational home for the community it serves.
Its responsibilities include:
Different communities may configure these responsibilities differently, but every node exists to support the people who depend upon it.
One of the primary purposes of a node is to establish clear boundaries.
These boundaries simplify governance, improve privacy, and make local autonomy possible.
A node defines what software, services, and data belong to one deployment.
Everything inside the node shares a common operational environment.
Everything outside the node communicates through explicit interfaces.
Hosted deployments and self-hosted deployments differ operationally, but both represent ordinary nodes within the ecosystem.
Every node possesses its own governance.
Governance answers questions such as:
Governance belongs to the community rather than to the software.
Nodes manage local identity.
Identity includes:
Membership within a node should remain under local control.
People may participate in multiple nodes throughout their lives.
Leaving one node should not require abandoning one’s personal history.
Every node controls access to its own information and services.
Permissions determine who may:
Permission systems should be understandable, auditable, and locally governed.
Nodes are responsible for the care of:
Stewardship extends beyond technical operation.
It includes preserving continuity, protecting trust, and supporting the people whose lives depend upon the node.
Every Pancakes node hosts a collection of reusable infrastructure that supports all applications running within the node.
Applications build upon these components rather than reimplementing them.
The identity subsystem manages people, organizations, devices, and other participants within the node.
It establishes who participates without determining how applications use those identities.
Permissions determine what actions each participant may perform.
Permission policies remain under local governance and may differ between communities.
The storage subsystem preserves:
Storage should support backup, migration, and long-term continuity.
Reference services provide shared information used throughout the ecosystem.
Examples include:
Reference services provide common knowledge rather than application-specific behavior.
Capabilities represent reusable services provided by the node.
Applications request capabilities rather than depending upon one another directly.
Examples include:
Capabilities make the ecosystem modular while allowing communities to choose which services they wish to provide.
Pitchfork provides the shared symbolic and accounting infrastructure used by applications running within the node.
Pitchfork records events, settles contracts, maintains provenance, and produces symbolic projections.
The node hosts Pitchfork as shared infrastructure rather than embedding accounting separately within every application.
Applications execute within the node using the shared infrastructure provided by the surrounding ecosystem.
Clients remain responsible for user experience.
The node remains responsible for shared operational services.
Every node requires administrative facilities for:
Administrative tools exist to support stewardship rather than centralize control.
They should make operating a trustworthy local node practical for both technical and nontechnical communities.
The Pancakes architecture is intended to support communities of many different sizes without requiring different software for each scale.
Every node shares the same architectural principles while differing in governance, operational complexity, and the capabilities it chooses to host.
A household node and a large institutional deployment are therefore different configurations of the same architectural model rather than different products.
A personal node serves one individual.
Typical uses include:
A personal node is typically governed by one person.
It may synchronize with other nodes or remain entirely standalone.
A household node serves a family, chosen family, or other long-term living arrangement.
Typical responsibilities include:
Household nodes emphasize consent and privacy between members while supporting shared stewardship of common resources.
A community node serves a voluntary association.
Examples include:
Community nodes generally support:
Institutional nodes serve organizations with formal operational or legal responsibilities.
Examples include:
Institutional deployments typically require:
The architectural model remains the same even when operational requirements are more demanding.
Hosted Pancakes deployments provide a convenient operational model for people who do not wish to administer infrastructure themselves.
Hosted deployments are ordinary nodes operated by a trusted organization.
They should not receive architectural privileges unavailable to self-hosted nodes.
Users should retain practical rights to:
Every node possesses its own governance.
Governance answers questions that software alone cannot answer.
Examples include:
The Pancakes architecture intentionally separates governance from software implementation.
Communities remain responsible for governing themselves.
Although governance may differ between communities, several principles should remain consistent.
Communities should govern their own affairs whenever practical.
Authority should remain close to the people affected by decisions.
Members should understand:
Opaque governance reduces trust.
Administrative authority should remain accountable to the community.
Important actions should be reviewable.
Responsibility should be identifiable.
Governance exists to preserve the conditions under which communities continue to flourish.
Authority exists to support stewardship rather than control.
Different communities may assign responsibilities differently.
The architecture distinguishes several conceptual roles even when one person holds multiple roles.
Members participate in the life of the community.
The node exists primarily to support them.
Stewards guide the long-term direction of the community.
Their responsibilities may include:
Custodians operate technical infrastructure.
Typical responsibilities include:
Custodians do not automatically possess authority over community governance.
Administrators perform operational tasks within the node.
Examples include:
Administrative authority should remain bounded by governance rather than replacing it.
A node maintains information belonging to individuals, communities, and shared infrastructure.
Different categories of information require different stewardship practices.
The architecture should therefore distinguish information according to its social meaning rather than only its technical format.
Information belonging primarily to one individual.
Examples include:
Personal information should remain private unless intentionally shared.
Information intentionally created or maintained by a community.
Examples include:
Governance determines how shared information is managed.
Information maintained on behalf of an organization.
Examples include:
Institutional information may require additional operational controls.
Some information is intended for publication.
Examples include:
Publication should always be intentional.
Private information should never become public by accident.
Nodes frequently generate information derived from other records.
Examples include:
Derived information may still reveal sensitive patterns.
Communities should therefore govern derived information with the same care given to primary records.
Long-term continuity requires durable archives.
Nodes should preserve:
Archiving is an act of stewardship rather than simple storage.
Export should be a first-class capability.
Communities should be able to retrieve their information without requiring continued participation in a particular hosted service.
Export supports:
Every node should support straightforward backup and recovery procedures.
Backups exist to preserve continuity rather than merely recover from technical failure.
Privacy is a foundational architectural principle.
Nodes should minimize unnecessary disclosure while allowing communities to cooperate effectively.
Whenever practical, information should remain within the node that created it.
External communication should be explicit rather than assumed.
Sharing should occur through informed consent.
Communities should understand:
Consent should be understandable rather than hidden within legal agreements.
Applications should request only the information necessary to perform their intended purpose.
Communities should avoid collecting information solely because it might become useful later.
Some forms of information deserve additional protection.
Examples include:
Nodes should allow communities to establish stronger protections for sensitive domains when appropriate.
Privacy is not achieved solely through encryption or access control.
Healthy privacy also depends upon:
Technical controls support these practices.
They do not replace them.
People should be able to leave a node without abandoning their own history.
Healthy communities encourage participation.
They do not rely upon technical lock-in.
Exit rights therefore include:
The ability to leave is an important component of meaningful consent and local autonomy.
The Pancakes architecture is designed to support many deployment models while preserving a common operational model.
A person using an official hosted deployment, a household running a small appliance, and a large institution operating its own infrastructure should all participate in the same ecosystem using the same architectural principles.
Deployment changes operational responsibility.
It does not change the constitutional structure of a node.
Every node should be capable of operating independently.
A standalone node should continue providing useful services without requiring:
Networking expands the usefulness of a node.
It should not define its usefulness.
Individuals and communities should be able to operate their own nodes.
Self-hosting provides direct stewardship over:
The architecture should make self-hosting practical without assuming advanced system administration expertise.
Hosted Pancakes providers offer operational convenience.
Typical responsibilities include:
Hosted providers should not receive architectural privileges unavailable to ordinary nodes.
People should remain free to migrate between hosted providers or to self-hosted deployments.
Organizations may operate Pancakes as shared institutional infrastructure.
Institutional deployments often require:
The architectural model remains identical.
Only operational practices become more sophisticated.
Healthy infrastructure assumes that change is normal.
Communities may wish to:
Migration should therefore be treated as an expected operational activity rather than an exceptional event.
Nodes should support migration through:
Nodes should evolve without disrupting community life.
Upgrades should emphasize:
Communities should understand what changes before adopting new software.
Failures are inevitable.
The architecture should therefore support recovery from:
Recovery procedures should prioritize continuity of community life rather than simply restoring software.
Federation is an important long-term goal of the Pancakes ecosystem.
It is not a prerequisite for useful local operation.
Nodes should therefore be designed so that federation may be added naturally as communities choose to cooperate.
Participation in federated networks should always remain optional.
A fully local deployment remains a complete and legitimate Pancakes node.
Communities should decide when and how they cooperate with others.
Federation should treat nodes as peers.
No node is inherently authoritative over another.
Communities cooperate through:
The architecture avoids assumptions of permanent central coordination.
Nodes should expose stable interfaces that support future interoperability.
These interfaces should prioritize:
Interoperability should arise from shared standards rather than proprietary integration.
Federation should never compromise local governance.
Every participating node retains authority over:
Communities cooperate without surrendering self-government.
Successful federation depends upon shared understanding rather than centralized control.
Examples include:
Standards enable cooperation while preserving diversity.
Many communities do not wish to administer servers.
For these communities, Pancakes appliances provide a practical operational model.
An appliance packages the software, configuration, maintenance tools, and operational guidance required to run a trustworthy node with minimal technical expertise.
An appliance is not a different architecture.
It is a different deployment experience.
The household appliance represents the primary reference deployment for the ecosystem.
It should be:
Its purpose is to make local stewardship practical for ordinary households.
Community appliances support organizations with somewhat greater operational requirements.
Examples include:
Community appliances may host additional capabilities while preserving the same governance model.
Some organizations may require standardized deployment platforms that simplify:
Institutional appliances should remain compatible with the broader Pancakes ecosystem rather than becoming separate products.
Appliances should assist rather than replace human stewards.
Operational tooling should make common responsibilities straightforward, including:
The goal is not automation for its own sake.
The goal is reducing unnecessary operational burden while preserving local control.
A node is one layer within the broader Pancakes architecture.
It neither defines the entire ecosystem nor merely hosts applications.
Instead, it provides the operational environment in which the ecosystem’s shared infrastructure becomes useful.
The Commonwealth defines the social and constitutional character of the ecosystem.
Nodes provide operational homes for Commonwealth institutions.
Communities govern nodes.
Nodes do not govern communities.
Applications provide user experiences.
Examples include:
Clients remain responsible for workflows and presentation.
Nodes provide the shared services upon which clients depend.
Pitchfork provides shared symbolic and accounting infrastructure.
Nodes host Pitchfork alongside the other shared runtime components.
Applications interact with Pitchfork through the node rather than embedding independent accounting systems.
This allows multiple clients to participate in a common symbolic and contractual model while preserving distinct user experiences.
Networking connects independent nodes.
Nodes remain complete without networking.
Networking allows communities to cooperate by exchanging:
The details of networking are defined in the Pancakes Network Architecture.
The node architecture intentionally provides a stable foundation upon which future infrastructure can be constructed.
Examples include:
These systems build upon nodes rather than redefining them.
The role of the node is to provide a trustworthy, locally governed operational environment in which they can evolve.
The Pancakes node architecture is intended to remain stable while supporting new capabilities over time.
The purpose of a node is not to predict every future application.
Its purpose is to provide a trustworthy, locally governed foundation upon which new communities, services, and institutions can build.
Future work should generally extend the ecosystem through capabilities, reference services, applications, and networking rather than changing the fundamental definition of a node.
Nodes will gradually acquire additional reusable capabilities.
Examples include:
Capabilities should remain modular.
Communities should be free to enable only the services they require.
The ecosystem will continue to develop community-maintained reference services.
Examples include:
Reference services provide shared knowledge without requiring centralized ownership.
Future applications may provide infrastructure for:
The node architecture is intended to support these communities without requiring new deployment models.
Service Exchange represents one of the primary long-term applications of the Pancakes ecosystem.
Nodes provide the local governance, identity, permissions, and shared infrastructure required for communities to coordinate services while preserving local autonomy.
The node architecture intentionally separates these shared operational responsibilities from the application itself.
The same node architecture may support future infrastructure for:
These applications should build upon shared node capabilities rather than creating independent infrastructure.
As communities choose to cooperate, federation may gradually expand to include:
Federation should emerge from voluntary cooperation rather than centralized control.
The node architecture intentionally leaves several questions open for future work.
These questions concern implementation rather than constitutional design.
How can node administration become simple enough for ordinary households, schools, and cooperatives?
Examples include:
How should people move between communities while preserving:
The architecture should support continuity without assuming permanent membership.
Communities may wish to delegate operational responsibilities without surrendering governance.
Questions include:
Communities evolve.
Questions remain regarding:
Nodes should support these transitions as ordinary parts of community life.
Communities often preserve information for decades.
Important questions include:
Stewardship extends beyond today’s technology.
As new applications appear, the ecosystem should continue expanding through shared infrastructure rather than fragmentation.
Future work should preserve a clear separation between:
Maintaining this separation allows the ecosystem to evolve without repeatedly redefining its foundations.
The reference Pancakes node should remain understandable, trustworthy, and practical.
A successful node should be:
Everything else in the ecosystem should grow from this foundation rather than replacing it.
A Pancakes node is more than a server.
It is a locally governed institution that combines technical infrastructure, community stewardship, and long-term continuity.
Nodes allow people, households, communities, and organizations to own their digital lives without isolating themselves from the broader ecosystem.
By separating local governance from shared standards, and shared infrastructure from individual applications, the node architecture provides a stable foundation upon which the Pancakes Commonwealth can continue to grow for many years without sacrificing its principles of autonomy, stewardship, and human flourishing.