selfdriven Network/Infra Interface

Concept Paper - For Curiosity & Collaborative Design

Infrastructure, owned by community.

A federated network of community-owned infrastructure — sovereign computing, distributed storage, regenerative energy and verified autonomous coordination. Communities stop being customers of infrastructure and become its participants, stewards and beneficiaries.

See the five layers Or jump to the first deployment
SELFDRIVEN / COMMUNITY HUBS Sovereign hubs. No central operator.
5

Infrastructure layers — energy, compute, storage, connectivity, and intelligence & governance

Hubs

Every community is a sovereign hub — fully operational on its own, sharing only by choice

3

Phases — from one autonomous node, to a federated network, to regenerative infrastructure

Open

Open specifications stewarded by the selfdriven Foundation — communities own the hardware and the data

The idea

No community should have to rent its entire digital existence.

Not from centralised cloud providers, not from a single energy system, and not at the cost of control over its data and intelligence. Each community operates its own infrastructure, and cooperates with others through selfdriven.network.

Local autonomy. Networked abundance. Regenerative by design.

Part of the Infra Interface
Hub. ONE COMMUNITY, FIVE LAYERS Energy Compute Storage Connectivity Intelligence & governance Sovereign Replaceable layers

Sovereign hubs

A school, village, neighbourhood, cooperative or region runs its own small-scale digital and energy infrastructure — and keeps running when it's on its own.

  • Schools
  • Villages
  • Co-ops
  • Regions
Share. FEDERATED BY CONSENT compute encrypted backups policy Community A Community B

Federated by consent

Hubs voluntarily contribute and consume capacity across the network. The network gets stronger as participation grows, without one operator controlling everything.

  • Compute
  • Storage
  • Recovery
Sun. WORK FOLLOWS ENERGY Night Midday surplus Night

Regenerative by design

Flexible computing, AI processing and backups run when clean local energy is abundant. Essential services and battery reserves are protected the rest of the time.

  • Solar
  • Batteries
  • Scheduling
The five layers

Start with what you have.

Each layer is independently replaceable. A community might start with compute and storage on ordinary grid electricity and add solar and batteries later. Another might contribute only storage, or only connectivity.

Participation shouldn't require buying an entire infrastructure stack.

  • 01

    Energy

    Solar, wind where viable, batteries, energy monitoring, demand management and shared energy resources.

    Interfaces · Infra
  • 02

    Compute

    Low-power servers, CPUs, GPUs, local AI models and workload scheduling.

    Interfaces · Interfaces Node · AI
  • 03

    Storage

    Local encrypted files, databases, immutable archives and federated replication.

    Interfaces · Attachment · Entity
  • 04

    Connectivity

    Local networks, fibre, Wi-Fi mesh, Internet links and optional alternative connectivity.

    Interfaces · selfdriven.tel · Handshake
  • 05

    Intelligence & governance

    selfdriven applications, identity, trusted agents, verified policies and community decision-making.

    Interfaces · SSI · AI · Human
Regenerative computing

Work follows clean energy.

Rather than maximising server utilisation at all times, the network optimises for community value per unit of resources consumed — connecting computational work to energy availability.

A grid-connected solar installation doesn't automatically keep services up in a blackout. Islanding needs properly engineered inverters, switching and protection, and in Australia operating a shared electricity network can bring regulatory obligations — see the AER regulatory sandbox via the Energy Innovation Toolkit.

  • Solar surplus

    Run flexible computing, AI processing and backups when clean local energy is abundant.

  • Energy-aware orchestration

    Octonomous agents schedule non-urgent work by energy, cost, demand and service commitments.

  • Community resilience

    Protect battery reserves and essential services, defer optional work, or draw on available peer capacity.

  • Regenerative outcomes

    Measure avoided emissions, extended equipment life, recovered heat and contributions to local ecological restoration.

A conceptual objective, not yet a calibrated metric. Measurement has to account for embodied emissions, hardware manufacturing, batteries and actual grid emissions — not simply what the panels generate.
Federation

Publish what you're willing to share.

Federation is the architectural differentiator. Each community keeps authority over its own infrastructure, and publishes a machine-readable statement of the resources it will share — and on what terms.

The declaration is a candidate high-level specification for OctoLang, not unrestricted executable configuration. An independent validator checks resource declarations, authority, policy conflicts and execution constraints.

Resource declarationExample
community: school.community-a
network: selfdriven.network

resources:
  compute:
    available: 12
    unit: cpu-core
  storage:
    available: 2000
    unit: GB

policies:
  data_residency: australia
  priority: local_first
  sharing: trusted_communities_only
  carbon_preference: low_emissions
  reserve_capacity: 30%

federation:
  allow_remote_compute: true
  allow_encrypted_backups: true
  require_verified_workloads: true
Placement

Consent first, then capacity.

A selfdriven.network scheduler negotiates workload placement only across communities that have consented to it.

  • Discover

    Community A needs extra compute. Community B has declared spare capacity and renewable electricity.

  • Verify

    Both sides check the applicable policies — residency, priority, reserve and trust — before any work is allocated.

  • Record

    Usage is recorded transparently, as the basis for settlement between communities.

  • Isolate

    Sharing compute doesn't mean sharing data. Private workloads need explicit trust boundaries, encryption, and potentially confidential computing or local-only execution.

Coordination

Intelligence advises. Authority decides.

Octonomous agents act as conductors over verified context and constrained controllers. The crucial separation is between intelligence and authority.

An agent could recommend moving a backup to another community while renewable energy is available. It can't override safety limits, consent requirements or electricity protection systems.

  • 01

    Octonomous agents

    Discover requirements, forecast capacity, propose allocation and coordinate exchanges.

  • 02

    Verified context graphs

    Describe assets, ownership, capacity, evidence, dependencies and trust relationships.

  • 03

    OctoLang

    Expresses community-approved constraints, permissions, intentions and sharing agreements.

  • 04

    Verified controllers

    Execute validated operational actions within defined boundaries.

  • 05

    Audit & evidence layer

    Records decisions, measurements, authorisations and outcomes.

An auditable path

  1. 01Community intent
  2. 02Verified policy
  3. 03Authorised execution
  4. 04Measured outcome
Technology foundation

Most of it already exists.

The innovation is in the integration, the governance model and the regenerative coordination protocol — not in reinventing containers, databases or tunnels.

For sensitive data, replication is not a substitute for versioned, independently tested backups. Content addressing alone can't guarantee persistence either.

  • Container workloads

    Docker or Podman; K3s for larger multi-server hubs, built for lightweight edge and ARM devices.

  • Databases

    PostgreSQL, and SQLite for lightweight, offline-first services.

  • Federated object storage

    Garage — S3-compatible, aimed at smaller, geographically distributed clusters.

  • Backup

    Encrypted, independently recoverable off-site backups.

  • Node connectivity

    WireGuard tunnels and local network routing.

  • Identity

    Community-controlled credentials and hardware-backed keys, on W3C Verifiable Credentials 2.0 and the SSI Interface.

  • Agent execution

    The Octonomous runtime, with verified controllers.

  • Energy integration

    Metering APIs, SunSpec and OpenADR where appropriate.

  • Evidence

    Signed measurements, event logs and validated context graphs.

Ownership & economics

Communities own the assets. The Foundation stewards the standards.

The physical infrastructure is owned or controlled by the community itself — a cooperative, association, school, community trust or other suitable legal entity.

The economics combine community contributions, paid local services, reciprocal resource exchanges and grants for shared infrastructure. See the example Cooperative Infra Agreement.

  • Community-owned

    The hardware, the energy systems and the data belong to the community's own legal entity.

  • Foundation-stewarded

    The selfdriven Foundation stewards the open specifications, reference implementations, interoperability tests and trust framework — without owning any community's infrastructure or data.

  • Resource accounting

    Compute-hours, storage GB-months, energy use and network traffic. Settle directly, keep mutual-aid balances, or use optional tokenised settlement — the OCTO ecosystem may help coordinate, but no speculative token or public blockchain is required.

  • Equitable by design

    Governance stops well-resourced communities dominating weaker ones. Access to essential services doesn't depend on contributing hardware or electricity.

First practical deployment

From one node to a regenerative network.

The first pilot could run across three schools or community organisations, on their existing Internet connections and grid electricity. Energy infrastructure comes later, in a controlled and separately engineered stage.

  1. Phase 1 · Autonomous

    Autonomous community node

    Deploy a low-power server, encrypted storage, local selfdrivenOS services, identity, backup and monitoring — building on the Interfaces Node. Keep the node usable during Internet outages.

    OutcomeOne community operates core digital services locally.

  2. Phase 2 · Federated

    Federated community network

    Connect three independent nodes. Demonstrate authenticated resource discovery, remote workloads, encrypted replication and recovery.

    OutcomeCommunities exchange capacity without giving up autonomy.

  3. Phase 3 · Regenerative

    Regenerative infrastructure

    Introduce solar and battery telemetry, carbon-aware workload scheduling, surplus-energy utilisation and verifiable regeneration reporting.

    OutcomeDigital capacity adapts to available energy and ecological constraints.

What the pilot has to prove.

The tests that matter most are the hard ones, not the happy path.

  • Recovery after a failed node
  • Offline access
  • Verified permission boundaries
  • Workload migration
  • Energy measurement
  • Maintainable without a specialist cloud team

What makes this different

Decentralising the capacity for communities to self-actuate.

Longer term, the same trusted resource framework could coordinate water, food production, fabrication, transport and education.

Most decentralised infrastructure projects distribute servers, storage or consensus. This one also asks who owns the assets, who authorises their use, how energy is sourced, how resources are shared, how knowledge is retained — and whether the result strengthens the ecological and social environment around it.

The hard problems aren't technical.

Operational maintenance, cybersecurity, legal responsibility, long-term financing, equitable access and keeping services reliable through failure. The architecture has to address them from day one.

Roadmap & resources

Next: architecture & protocol.

This concept develops next into a formal selfdriven.network Architecture & Protocol v0.1 — the foundation for a working reference implementation.

Roadmap

Architecture & Protocol v0.1.

What the next version will define.

  • 01

    Community Node specification

    What an autonomous community node runs, building on the Interfaces Node.

  • 02

    Resource federation protocol

    How hubs declare, discover and negotiate shared capacity.

  • 03

    Trust framework

    Credentials, consent and the trust boundaries between communities.

  • 04

    Regenerative resource accounting

    Compute-hours, GB-months, energy and traffic — weighed against community and regenerative benefit.

  • 05

    Octonomous & OctoLang interfaces

    How agents propose, policies constrain and controllers execute.

Resources

Related.

Where this fits across the selfdriven Network.

Become a hub

Own the infrastructure your community depends on.