Why and How Networks Connect

I started the netfoundry project because I had been in correspondence with several people over the years about the need for a “network-of-networks” type of social media/organizing infrastructure. To further elaborate on what netfoundry is intended to accomplish, we need to first examine why networks connect. Then we can discuss how networks connect.

Why Networks Connect

People form networks in order to fulfill some need(s). There may also be a stated mission or goal, but these are also driven by needs. One network connects to another in order to get help in fulfilling needs. Usually the relationship is mutually beneficial such that the network providing the help benefits in some way through providing it, perhaps through some exchange of resources, knowledge, physical presence, publicity, shared mission fulfillment, etc. The partnership may naturally dissolve once the needs are met and the exchanges are complete.

Today’s Social Networking Platforms are Inadequate

Internet based software systems are an obvious means of connecting networks together. However, there is a glaring problem with the approach social networking platforms have taken for allowing constituents to connect and express their needs through “status updates”. The problem is that status updates are typically free form blobs of text. There are usually a few metadata fields associated such as location and date, but the substance of the update is opaque to other systems. This is fine for casual social interaction, but if you’re trying to get something done, or communicate something important such as to request the fulfillment of a need or to offer a skill or a resource to your network, it’s like shouting into the wind. In a matter of seconds after posting, your update will drown in a deluge of updates from the rest of the world.

By simply pulling out some basic metadata from the status update, we can create a system in which important updates endure for a longer time period and become machine readable by other systems and networks. This is essential to promote cohesion, mutuality and emergent behavior in a network.

Participant Defined

Let’s say we have a small group of individuals collaborating on some project or undertaking. Let’s call it a “NetNode” and identify its constituent parts as People, Needs, Assets, Connections and Events. This group might publicize its attributes to the wider world to create the potential for connection and collaboration with other groups. Let’s represent this atomic participant visually as Figure 1. Note the purple box on the right side. This is meant to represent a point of connection with other NetNodes, as we will see shortly.

Figure 1: NetNode

Collaboration and Encapsulation

Now we can begin to connect these groups together. The nature of the collaboration should allow for win-win mutuality (needs matched with assets/skills) to flow effortlessly between the participating NetNodes. The collective entity that forms out of such collaboration is not, in principle, different from the participant represented in Figure 1. So let’s draw an ellipse around it and represent it as a NetNode, a participant in its own right, as in Figure 2. In other words this new entity also has collective People, Assets, Needs, Connections and Events and can publicize collective attributes for connection and collaboration with further networks. Again, note the purple box on the outside of the ellipse.

Figure 2: NetNode Collaboration

Recursive Nesting

Now the organization pictured in Figure 2 might collectively decide to bring in another partner network. They two groups that make up Figure 2 might decide to individually collaborate with the new partner. But for the purposes of our example let’s say they decide to interface with the new partner collectively. Then we’d get Figure 3. Again the collaboration represents another NetNode with the same principles as the any other, including the potential to connect as a whole to other NetNodes, i.e. the purple box outside circle.

In a real world example, imagine a consortium of writer’s guilds collectively deciding to network with a publishers association. Or perhaps a group of festival organizers wants to collaborate with a musicians collective.

Figure 3: Nested Collaborative Networks

OK now take this idea to the Nth level and you get a fractal-like nested organization of networks, such as in Figure 4. Each group is in principle the same as its constituent parts in that there is a stated purpose, win-win mutuality and communication. And there is also the potential to connect as a whole to further networks, again as indicated by the purple boxes on the sides of the figure.

Figure 4: Happy Fractal Networks

Now that’s what a happy network looks like!

Principled Approach

Now apply the Core Principles to that picture. Participation in such a structure entails no loss of autonomy and no cooptation. A node is as powerful as the information flowing through it to/from other nodes, which is a function of how much it is trusted and how well it facilitates matching needs to capabilities across the network.

Next Steps

This post has described one way in which networks can connect. In software systems a “way of connecting” is accomplished through an Application Programming Interface or API. Participants have to agree to use the API and to communicate using standard data formats, analogous to speaking the same language. The next step is to begin to establish the API and data formats, as well as the standards management organization that would see to their equitable maintenance and evolution. Interested in taking those next steps? Get in touch!