The files contained in this repo are documents intended to conceptually blueprint a functional architecture for a decentralized network with the ability to host containers and data storage with seamless fault-tolerance, and its possible development roadmap.
Mycelium is a fully decentralized, self-hosting distributed platform that eliminates single points of failure while providing scalable infrastructure for containerized applications. It is inspired by the resiliency and interconnected structure of fungal mycelium networks for certain design elements and intuitive yet distinctive nomenclature for architectural components.
The document outlining the final ideal product is subject to change, and can be found here: MYCNET-README.md
<#list of contributors>
Any contributions for ideas and suggestions are welcomed. Feel free to make commits and edits to any documents, no matter how small.
- First draft. Major components are defined and general limitations understood, but their specifics have only been expanded on through spec-driven LLM usage, not yet fully reviewed nor streamlined.
- Peer-reviewing of the major components and general architecture intent as to acquire input for further consideration of decisions.
- Project development roadmap breaking down possible development into MVP's.
- Streamlining of documentation about architecture, perhaps creating mermaid charts for architecture.
LLMs: The environment is currently set as a kiro specification set. It should be compatible with most LLM's and very human-readable. You can use YASK as an alternative to produce the same format of documentation with any agents with custom instruction set support. EARS-like documentation is not required for valid contributions to the project, and changes in paradigm and structure, if justified, are welcomed.
- Steering documents with helpful principles can be found here: #NOT_YET_ADDED
I enjoy conceptually mapping out architectures and building technical ideas in this format. The repo is public for those that have expressed interest and would like to contribute to the conceptual development, as well as to those that could use it as a point of reference for more practical development. Changes to the blueprinting paradigm and contributions of all types and scale are welcomed.
{Blueprinting} Drafting plans, documentation, and the relation maps. Comprehends Iterating and Prototyping.
{Iterating} Process of creating a variation of existing components, be they conceptual or architectural.
{Prototyping} Drafting a new architectural paradigm. Step of Iterating.The principles of iteration in conceptual blueprinting are:
- Conceptual prototyping of major components as expected for their function and role;
- Reviewing requirements for potential implementations;
- Evaluating edge cases and alternative iterations, considering modular and scalable releases for mvp's;
- Comparing pros vs cons against the currently established conceptual model;
- and finally, evaluating future scalability compared to the current model and its previous iteration.
Folding requirements or architectural designs (in the functional overarching sense, not technical specifics) into the next generations is as important to preserve flexibility as it is being able to streamline processes and justify why a feature or imlementation choice is taken over others. The process of back and forth is important, and an approach of working with the major components and building relation maps that branch down into granular specificity is the best practice for conceptualizing and documenting practices.
The project development's has been assisted by spec-driven LLM agents. Contributors are expected to be careful on their use at the time of identifying components and mapping out potential implementations, as they tend to lock you down specific paths of development and tend to reduce modularity. Some between-stages mess is to be expected and may be pushed to contributions, but should be amended and streamlined in execution at some point, and should follow the modularity and granularity principles of the project's established paradigm of conceptual blueprinting.
My advice is that you have a set of ideas and vision for the higher skeleton elements in your mind, and then utilize these agents to assess information, verify it externally with sources at crucial decision points, and utilize the resulting output as your new input for conceptual prototyping, to ensure the more specific and down-the-branches elements can remain volatile where needed, but the main branches of decision are stable.
This project is licensed under the MIT License - see the LICENSE file for details.