Project Expanse: Autonomous Decentralized Networks — Establishing a Research Working Group
Black Roses | Project Expanse | 2027 Research Program
Introduction: Infrastructure That Must Survive Its Own Isolation
The modern Internet creates the impression of a global, continuously available communication system. However, behind this apparent availability lies a complex infrastructure of network operators, backbone links, data centers, routing systems, DNS services, cloud platforms, and centralized service providers.
Failures of individual components, physical infrastructure damage, communication channel disruptions, power outages, or administrative restrictions can make significant parts of digital services inaccessible.
The problem is not limited to losing access to the global network. Users may also lose the ability to exchange messages, retrieve documents, access local services, synchronize data, and communicate with other participants.
The traditional connectivity model assumes that an external network environment remains available. But what happens when it does not?
This question is the starting point of the Black Roses / Project Expanse research program.
We do not view mesh networks merely as another alternative to Wi-Fi or as a way to establish local wireless connectivity. Our objective is much broader: to investigate autonomous, heterogeneous, decentralized communication infrastructure that remains practically useful even under prolonged isolation, partial node failures, and degradation of physical communication channels.
1. From Mesh Networks to AHDN
Within this research program, we use the working term AHDN — Autonomous Heterogeneous Decentralized Network.
It describes a concept for an autonomous, heterogeneous, decentralized network built through the interaction of multiple technological layers.
Its fundamental properties include:
Independence from a single operator or central server.
Support for multiple independent physical communication channels.
Automatic route recovery capabilities.
Message delivery without requiring continuous end-to-end connectivity.
Continuity of local digital services.
Distributed data storage and replication.
Cryptographic protection of communications.
Autonomous operation of isolated network segments.
It is important to clarify that AHDN is currently a research architecture, not a finished software product or a standardized networking protocol.
We do not intend to invent another universal protocol. Instead, we aim to investigate the integration of existing open technologies, identify their compatibility boundaries, and verify the practical performance of proposed solutions.
2. Five Core Research Areas
2.1. Self-Healing Networks
Conventional networks often depend on predefined routes and the availability of specific nodes.
In a dynamic mesh network, this dependency becomes a limitation. Nodes may move, lose power, fail, or temporarily lose connectivity with neighboring nodes.
The network must detect topology changes and automatically reconstruct its routing paths.
Key research tasks include:
Detecting unavailable nodes.
Evaluating link quality.
Selecting alternative routes automatically.
Preventing routing loops.
Restoring connectivity when nodes return.
Minimizing data loss during network reconfiguration.
Particular attention will be given to Babel, a dynamic IP routing protocol designed for wired and wireless networks, including environments with changing topology.
However, automatic route recovery does not necessarily restore a service. If data or an application was available only on a failed node, separate replication and redundancy mechanisms are required.
2.2. Delay-Tolerant Networking — Communication Without Continuous Connectivity
This is one of the central research areas of the program.
Delay-Tolerant Networking (DTN) is designed for networks where connectivity may be intermittent, delays may be significant, and end-to-end communication may temporarily be impossible.
Its fundamental principle is Store-Carry-Forward.
A node receives a message, stores it, carries it or waits for an available communication opportunity, and then forwards it to the next node.
This means that information delivery does not necessarily require a continuous connection between sender and recipient.
The technological foundation for this research is Bundle Protocol Version 7, specified in RFC 9171.
This standard provides a framework for delivering data in challenging network environments where conventional assumptions about continuous IP connectivity do not hold.
Another relevant reference is RFC 9675, the DTN Management Architecture, which addresses asynchronous operation, autonomous local management, and resource-constrained environments.
Practical research tasks include:
Message queue management.
Data preservation during communication outages.
Information transfer between isolated network segments.
Message expiration and retention policies.
Data integrity verification.
Duplicate delivery handling.
Synchronization after connectivity is restored.
DTN should not be confused with ordinary caching or file transfer. It is a distinct architecture for information delivery.
2.3. Heterogeneous Mesh — Integrating Different Physical Communication Channels
One of the most promising research directions is the development of a network that does not depend on a single type of physical connection.
The technologies under investigation include:
Wi-Fi and Wi-Fi Mesh.
Ethernet.
LoRa.
Packet radio.
Cellular communication.
Satellite connectivity.
Fiber-optic and backbone networks.
Each transport has different characteristics.
Wi-Fi and Ethernet provide relatively high throughput. LoRa enables low-power communication over long distances with limited data rates. Satellite connectivity can provide external links for remote network segments. Radio channels offer opportunities to establish independent physical communication paths.
The central challenge is to make different physical media serve a common logical communication environment.
Particular attention will be given to Reticulum Network Stack. This open networking stack supports heterogeneous interfaces, including Ethernet, Wi-Fi, serial links, and LoRa through compatible hardware.
Yggdrasil, a decentralized IPv6 overlay network, will also be investigated.
Their architectures and approaches to transport integration are fundamentally different. They cannot be considered interchangeable components or combined simply by installing them on the same device.
We need to determine which use cases allow parallel operation and where dedicated gateways or inter-network data transfer mechanisms are necessary.
Meshtastic will also be investigated as an existing implementation for experiments with low-power LoRa networks.
An important distinction: LoRa is a radio modulation technology, LoRaWAN is a networking protocol, and Meshtastic implements its own mesh communication logic. A typical LoRaWAN architecture is not a mesh topology.
2.4. Autonomous Routing
This research area focuses on intelligent network management.
Traditional routing algorithms use defined metrics such as hop count, link cost, latency, availability, and other parameters.
However, autonomous heterogeneous networks introduce additional complexity.
One route may be fast but energy-intensive. Another may have limited throughput but remain available for much longer. A third may be congested or unstable.
In the longer term, we intend to investigate:
Adaptive link-quality evaluation.
Energy-aware routing decisions.
Dynamic load balancing.
Connectivity degradation prediction.
Route selection algorithms.
Multi-Agent Reinforcement Learning.
However, machine learning is not an immediate priority.
We must first obtain measurable results using conventional algorithms. Only then can we determine whether adaptive models provide a genuine advantage.
2.5. Privacy-Preserving Infrastructure
Decentralization does not automatically guarantee privacy.
An encrypted channel does not necessarily conceal network topology, metadata, the presence of a particular node, or communication patterns.
Research will therefore include:
Cryptographic node identity.
Participant authentication.
Key management.
Key rotation and revocation.
Protection against node impersonation.
Sybil attack mitigation.
Reducing traffic observability.
Network segmentation and compromised-node isolation.
I2P will be examined as a technology for building private overlay services.
At the same time, we will not equate encryption, privacy, and anonymity. None of these properties is absolute. The actual level of protection depends on the threat model and operating conditions.
3. Research Technology Stack
At the initial stage, we have identified the following core components.
Yggdrasil
A decentralized IPv6 overlay network. It will be investigated as a foundation for logical IP connectivity between nodes and access to local IP services.
Reticulum
A networking stack designed to operate over heterogeneous communication media. One of the primary candidates for experiments involving heterogeneous transport and autonomous communications.
Babel
A standardized IP routing protocol. It will be considered for building and recovering IP routes within compatible network segments.
DTN / Bundle Protocol v7
The foundation for asynchronous message delivery in networks with intermittent connectivity.
Meshtastic
A practical platform for experiments with LoRa, low-power radio nodes, and multi-hop message delivery.
IPFS
A distributed content-addressing and data exchange system. It will be investigated for local storage, content replication, and document integrity verification.
Long-term content availability requires persistent storage across multiple nodes. Publishing a file to IPFS does not, by itself, guarantee permanent availability.
I2P
A private overlay network that will be investigated for protected access to services and reducing the observability of communications.
This list is not a finalized technology stack. Each component will be evaluated according to its functionality, compatibility, security, resource requirements, and actual experimental results.
4. Proposed System Architecture
To organize the research, we propose a five-layer model.
Layer 1. Computing Infrastructure
Physical nodes, mini-computers, routers, servers, storage devices, autonomous power systems, and monitoring infrastructure.
Layer 2. Physical Communication Channels
Wi-Fi, Ethernet, LoRa, radio communications, satellite links, and other compatible transmission technologies.
Layer 3. Transport and Delivery
Packet transmission mechanisms, DTN, buffering, retransmission, and synchronization.
Layer 4. Network Layer
IPv6, Yggdrasil, Babel, Reticulum, and mechanisms for interoperability between different network environments.
Layer 5. Local Digital Services
Messaging, distributed storage, local directories, DNS, documentation, information resources, and other applications.
This is a conceptual model. The actual placement and interaction of protocols and services will be determined through experimentation.
5. The Main Research Hypothesis
We propose testing the following hypothesis:
A local digital infrastructure can remain functionally useful even after losing external Internet connectivity, some physical communication channels, and individual network nodes, provided that it combines autonomous routing, DTN, distributed storage, and locally available services.
To test this hypothesis, we intend to establish a laboratory experimental environment.
The initial scenario will include:
Several physically or logically separated network segments.
Local nodes hosting independent services.
External Internet connectivity at the beginning of the experiment.
Complete disconnection from the external network.
Controlled loss of selected nodes.
Degradation of individual transport links.
Movement of a mobile node between segments.
Restoration of external connectivity and subsequent synchronization.
The experiment will evaluate more than basic network connectivity. It will test whether users can still perform specific tasks.
Can a user discover a local service? Can they send a message? Can they retrieve a document stored on another node? Can information be transferred between segments without a permanent direct connection? Can synchronization resume after connectivity returns?
These results will define whether the experiment is successful.
6. The Working Group: Structure and Responsibilities
We are initiating the formation of the Black Roses / Project Expanse research working group.
Its purpose is not simply to monitor technology news, but to build an independent, structured, and practically useful knowledge base covering autonomous decentralized networks.
The working group is intended to become a coordination point for research, technical documentation, experiments, and knowledge exchange between individual participants and projects.
Core Responsibilities
Monitor technologies, standards, scientific publications, and open-source software projects.
Verify the current status of documentation, releases, and technical capabilities.
Analyze interoperability between different networking components.
Prepare technical reviews and comparative studies.
Develop experimental scenarios.
Document testing results.
Build and maintain an open knowledge base.
Prepare technical recommendations for other decentralized initiatives.
Research Area Curators
To prevent fragmented and uncoordinated research, we propose dividing responsibilities into dedicated areas.
Network Architecture Curator
Responsible for Yggdrasil, Reticulum, Babel, IPv6, network topologies, and networking stack interoperability.
Radio Technologies and Transport Curator
Investigates Wi-Fi Mesh, LoRa, Meshtastic, radio links, Ethernet, and satellite communication.
DTN and Data Delivery Curator
Responsible for Bundle Protocol, asynchronous delivery, buffering, synchronization, and delivery recovery mechanisms.
Distributed Services and Storage Curator
Investigates IPFS, replication, local services, edge infrastructure, and digital resource persistence.
Security and Privacy Curator
Studies cryptography, trust models, key management, I2P, threats, and protection mechanisms.
Research and Testing Curator
Develops experimental scenarios, measurement methodologies, comparative tables, and research reports.
Curators should not become owners of individual technologies or closed research domains. Their role is to coordinate investigations, verify claims, maintain documentation, and ensure that knowledge is shared with other participants.
One person may temporarily cover multiple responsibilities. Clear accountability matters more than creating a formal organizational structure.
7. How the Knowledge Base Will Work
We do not want the results of this work to remain within a small circle of developers.
Every research area should therefore have its own documentation.
Each technology profile should include:
Purpose and architecture.
Current version.
Official documentation.
Development status.
Supported platforms.
Hardware requirements.
Known limitations.
Compatibility issues.
Testing results.
Security assessment.
Practical use cases.
Every technical claim should have a clearly defined status:
Confirmed — verified through documentation, a standard, or a reproducible experiment.
Experimental — demonstrated in a specific test environment but not yet validated under other conditions.
Hypothesis — a promising assumption requiring further investigation.
Unverified — insufficient information is available to support a reliable conclusion.
Refuted — the claim contradicts verified evidence or experimental results.
This approach will prevent the knowledge base from becoming a collection of promotional descriptions of various technologies.
Our objective is not to prove that a particular software product is superior. We want to establish where, under what conditions, and with which limitations it actually works.
8. Research Roadmap for 2027
Phase I. Architecture and Laboratory Prototype
Determine component compatibility, establish a test environment, deploy network nodes, and configure local services.
The initial objective is to investigate the basic interaction between Yggdrasil, Reticulum, and local IP infrastructure.
Phase II. Autonomous Data Delivery
Investigate DTN, message persistence, retransmission, and data exchange between network segments with intermittent connectivity.
Phase III. Heterogeneous Transport
Introduce additional physical communication channels and investigate LoRa, Wi-Fi Mesh, radio links, and cross-transport communication mechanisms.
Phase IV. Distributed Services
Integrate IPFS, local storage, document replication, and autonomous information services.
Phase V. Security and Field Testing
Evaluate fault tolerance, energy consumption, node security, service availability, and recovery after communication failures.
The sequence may be adjusted according to the results of previous phases. We will not declare a phase complete simply because its calendar deadline has arrived.
9. How We Will Measure Results
The research program must rely on measurable indicators.
Core metrics include:
Network connectivity recovery time.
Successful message delivery ratio.
Message delivery latency.
Throughput of individual communication channels.
Local service availability.
Data loss.
Synchronization recovery time.
Node energy consumption.
Resilience to individual component failures.
Network behavior during segment isolation.
Each experiment will document its configuration, software versions, hardware, testing conditions, and results.
This is essential to allow other researchers to reproduce experiments and independently verify conclusions.
10. Who Can Benefit from This Work?
Our research is not limited to our own infrastructure.
The results may be useful to:
Decentralized platform developers.
Open-source communities.
Networking researchers.
Community mesh network operators.
Developers of autonomous information systems.
Distributed storage projects.
Organizations building backup communication systems.
Digital resilience initiatives.
We intend to publish not only successful results, but also failed experiments, identified limitations, and technical mistakes.
Sometimes understanding why a particular solution does not work is just as valuable as having instructions for implementing one that does.
11. Working Principles
The research group will follow several fundamental principles.
Openness. Publish results that may be useful to other members of the ecosystem.
Verifiability. Separate confirmed facts from assumptions and promotional claims.
Technology neutrality. Avoid dependence on a single vendor, protocol, or platform.
Practical validation. Test architectural concepts on real devices and in controlled experiments.
Reproducibility. Document testing conditions and provide sufficient information for independent verification.
Decentralization of knowledge. Make documentation and research results accessible regardless of participation in a particular organization.
12. Invitation to Participate
Black Roses / Project Expanse is beginning to form a research working group focused on autonomous heterogeneous decentralized networks.
We are not looking for nominal team members. We are looking for people willing to work with specific technologies, verify documentation, conduct experiments, analyze results, and share knowledge with others.
We welcome cooperation with developers, system administrators, network engineers, researchers, information security specialists, and open-source software advocates.
Participation can begin with a single, well-defined task: evaluating a protocol, analyzing compatibility between two components, testing hardware, or preparing a technical review.
There is no requirement to be an expert in every research area. What matters most is the willingness to investigate, document, and share results.
Our goal is not to create another closed technology platform. Our goal is to investigate how to build infrastructure that remains useful when the Internet as we know it stops working.
Technical Sources and Documentation
Yggdrasil Network — official documentation and project repository. Version 0.5.15 release, October 24, 2026.
Reticulum Network Stack — official technical documentation, version 1.6.0.
IETF RFC 9171 — Bundle Protocol Version 7, January 2022; subsequent updates include RFC 9713 and RFC 9758.
IETF RFC 9675 — Delay-Tolerant Networking Management Architecture.
IETF RFC 8966 — The Babel Routing Protocol.
Meshtastic — official documentation on mesh messaging and managed flooding.
IPFS Documentation — Persistence, Permanence and Pinning.
I2P Documentation — Threat Model.
IEEE 802.11s — Mesh Networking specification.
Black Roses | Project Expanse
Research. Document. Share knowledge. Build decentralized infrastructure.
#ProjectExpanse #BlackRoses #AHDN #MeshNetworks #DecentralizedNetworks #Yggdrasil #Reticulum #DTN #IPFS #OpenSource
Comments
Post a Comment