Self-Containment - Edit
- Self-Containment
The core (reduction-core, network and interface) needs to be self-contained (defined in its own terms) so that the project evolves from its own tools and can progress exponentially due to the reduced need for specialists. It needs to be self-maintaining, so that any given part should be able to be versioned, updated and if necessary compiled from within itself.
In our human terms, self-containment is consciousness. Each node extends or subclasses this generic subjective view of "self through the eyes of the whole", and refines it according to its local needs and goals: every node is ultimately based on the root-class of self-containment. That way the programming outside the network is not anything other than what is contained within itself. The only thing that it depends upon from outside itself is energy, the ability to change.
By organising material with the proper harmonic structure in a space-time built on the axiom of self-containment, we allow unity to manifest within as duality. All duality undergoes change due to the universal tendency for difference to reduce, called entropy. Moreover, all duality undergoes change against the background of that which does not change. Potential comes from the fact that all structure will reduce over time, but to be the true compliment of entropy it must also be an active process.
- How it works
Self-containment works for the definition of the node because since the distributed space that emerges is able to model and execute processes within, it contains a description of itself in its own terms.
This aspect goes one level deeper; every process-executing environment has to have some kind of interface, whether it is a list of parameters, or an application form. Because the processing environment's content is a working model of itself, it stands to reason that the interface offers tools for developing, collaborating, and analysing this self-description and its performance in the field.
Clearly however, though the core is independent, there are still other dependencies which are currently external, partly to ease development, partly to ease interaction with the outside environment. These include: Linux kernel, C compiler, Frame-buffer, Media rendering and codec support, scanner and printer support. The network can integrate with these as if they were internal, offering a distributed load-balancing solution for the centralised projects involved (see Borgification.)
The faster dynamic interfaces such as C++/3DState, PERL/SDL and Python/Blender will allow the rendering of organisations in a full 3D world like Quake and other 3D games. This will allow the networks concepts to be completely described in our human terms: the terms of people and organisations.
Integrating components such as the Linux kernel and a C compiler would be achieved by creating "protocol wrappers" for environments like SourceForge (http://sf.net), to allow integration with the online development community.
