The social fabric of complex and healthy societies is composed of many interlocking social contracts involving many community subsets. We propose a grammar and implementation of The Weave, of a set of open protocols and standards for spinning up all kinds of small social agreement units and knitting them together in a meaningful and easy to use way.

Social Substrate

We start with substrate that provides the capacity to instantiate small social-contract units.

Call the templates for instantiating these units Social DNAs or Rules of Engagement Call instances of instantiated Social DNAs Cells

Distributed Context

The specific nature of this substrate is important (see “Considerations” below), but the most critical ones are that:

1. any group of agents that wants to interact according to a Social DNA can do so, i.e. that there is no intermediary enforcing the rules of engagement.
2. any single agent always has full and complete access to any data they contributed to the social context.

These criteria make possible some of most important functional aspects of the Weave as will be described below.

One such substrate that matches these criteria is Holochain, which is built out of:

1. a distributed, validating data store (integrity zomes + graphing DHT)
2. with mutation described by clear API (coordinator zomes)
3. where each set of validation rules comprises a separate network of participating agents, co-holding and validating the actions of other agents.

Typology

Notice that large scale society is build out of many types of these Social DNAs assembled in many ways. Some of the types include those Social DNAs that can be used to:

1. define “social contexts” i.e. as a membrane to manage membership of individuals into the social context. These are the the games of “Who”. Call Social DNAs of this type Membranes. Call instances of Membranes Groups.
2. define functional components for the group (chat, document editing, KanBan board, drawing). These are the games of “What”. Call Social DNAs of this type Capacities. Call instances of Capacities Tools.
3. hold, and make sense of templates, or starting points, which can include SocialDNAs themselves, or initial content for Capacities. Call Social DNAs of this type Sources. Call instances of Sources Libraries.

Instantiation & Runtime

Notice that Cells (instances of these DNAs) and the UIs to access them must exist inside some run-time application. This is similar to how web-sites are accessed using a “web-browser”. Call the type of computer application used to access instances of Membranes, Capacities & Sources (Groups, Tools & Libraries) a Frame. Any Frame will be expected to manage the instantiation and display of these different types of Social DNAs in meaningful ways.

Composablity

Notice the level of power that arises when Tools are interoperable and composable by end-users. For example, imagine composing a thread from a chat tool into a document from a collaborative editing tool such that a group’s members can converse about documents in context, without having this functionality be added by software developers. You can think of this as “very-late-binding”. For this to be possible a number conventions and protocols must be adhered to by Frames, just like how web-browsers (Chrome, Firefox or Brave) all adhere to common definitions of HTML, CSS, Javascript, DOM, etc.

Call the conventions around how Cells can be composed and interoperate: the Weave Interaction Pattern (WIP). The WIP creates standards for the things that are managed by the Cells, how to declare and interpret their meaning, how to establish relationships between them, how to create, view and interact with them, how to search for things you know exist, discover new things meaningful to you, and how to help manage attention as things change.

Things

Abstractly, Capacities provide access to, creation and modification of coherent units of data. Call such a unit an Asset.

Meaning

As a coherent data unit, an Assets must be interpreted meaningfully. Assets types are thus defined by:

• Asset Identifier definition: A schema that describes how and asset can be identified, e.g. index, hash, uuid, etc.
• Asset Semantic Tree definition: A schema that describes semantically the content of the Asset which can be used to retrieve parts of the Asset, as well as to subscribe to Asset changes.

Relations

Capacities compose with other Capacities by being able to link to their Assets. Call a link to an Asset a Weave Asset Locator (WAL). A WAL is like a URL for the web but is used to identify an Asset. A WAL consists of a Holochain Resource Locator (HRL) + Asset Identifier.

Presentation

Capacities define the following UI elements:

1. “Main” renderer: presents contextually relevant UI when an end-user selects the Tool in general instead of a specific Asset created by the Tool. This rendered will usually include UI to create and administer new Assets.
2. Asset renderer: presents a specific Asset given a WAL.
3. Create renderer: presents UI that can create an Asset of a given type. Note that a create renderer must collect any appropriate information needed to create the Asset type (i.e. if the asset is a KanBan card, the capacity to specify which board and column in which to add the card). The create renderer returns a WAL for the created asset, because this renderer may have been activated at the request of a different Tool that wants to store a link the created Asset.
4. “Cross-instance” renderer: Such renderers are given access to all of the instances of the same Capacity such that they can provide an end-user a unified experience of all of the assets of that abilities type. For example a calendar Capacity can display all of a user’s events across all of their groups in such a renderer.
5. Capacities may include other capacity-specific blocks which are made available to be composable by end-users into views. Such blocks are useful for creating dashboards.

Discovery/Search

There are some important distinctions that we start from regarding how we find and find out about things:

• search: I know [thing] exists but I don’t remember where. I need to search for it.
• discovery: I’m confronted with a specific need or challenge and am looking for a thing that I don’t yet know exists that helps me with that (active discovery). Or I discover something accidentally that I realize (or will remember later) is useful in a context I’ve been in the past or will be in the future (passive discovery).
• propagation: I discovered something useful and want it to propagate to people in similar contexts.

Furthermore we must hold to the truth that information makes sense only in context. These understandings create some mandates in the context of the Weave:

1. searching should respect boundaries
2. context should move with information.
3. information should propagate along axes of contextual similarity

The consequences of these mandates to the WIP are:

• Capacities may define a Search function which implements search across the Assets created by the Tool. This function is triggered by end-users and is called either with a plain-text search string or with a Sematic Tree Regular Expression, and should return any matching Assets. Thus, the Frame can always return the context of the found items to the user because it knows which abilities are associated with which groups.
• Libraries are available to search for and discover across the range of classes of entities that might exist, i.e. specific information (Assets), functional capacities and their instances (Capacities/Tools), starting points (templates within for addition to specific Tools).
• Capacities may also provide information to the Frame about Asset data that should be indexed for fast searching and propagation.

Attention

Members of social contexts need a ways of managing what to pay attention to. In the “information age” healthy social fabric depends on respecting and supporting the management and awareness of the critical limited resource of our individual attention.

Thus, abilities can define a set of Notification Definitions that end-users can subscribe to. Frames can then present unified present UI for setting notification preferences.

Services

There are often specific types of functions that all Tools in a group may want to access, for example consider sending SMS or email notifications or messages. This is a kind of functionality that a given Capacity may define abstractly as desired, but needing to be fulfilled specifically for each given Group. The WIP defines a Service Specification that Capacities can list in the Capacity manifest as being required or optional for instantiation.

Sources & Libraries

When creating new instances in a Frame, e.g. new Groups, new Tools, or new Assets in a Tool, there always needs to be some kind of source for the instance. In the context of social fabric, we also operate according to social agreements about how we relate with curating, accessing and interacting with these sources. In the physical world think of all the social agreements around checking out books in lending libraries. Think about the code package management systems like NPM or Crates.io. Think about stock-photo websites. The Weave Interaction Pattern therefore supports a grammar for creating, and interacting with Sources in general and instances of Sources as Libraries in specific.

The most prominent Library in a Frame is the Tool Library where end-users can add to Tools into groups. Additionally specific entries in the Tool Library can specify other instantiated Libraries for the Tool. For example, a Games Tool, may point to an existing Game Library from which to instantiate game Assets into a given instance of the Game Tool. That Library will probably, not necessarily, be maintained by the the Capacity developer.

Our Methodology

Many deep infrastructure projects are built by creating a very detailed specification, and then building to it. With The Weave, this is not our way.

Instead we have built Moss, as a reference frame and discovery tool to understand what needs to exist inside The Weave, as we begin using it organically ourselves to grow our own social fabric. The concepts described in this website emerged over time, beginning from what was at first just understood as a distributed groupware platform, and are now solidifying into a more formal protocol with the Weave Interaction Pattern described above.

We expect this to become more formalized over time, but for now we want it to emerge from the experience and needs of actual groups using this framework. Thus we are not prematurely creating a "hard-spec" of for the WIP

We expect very soon to open a Group that uses a Tool in development called How to "dog-food" the landing of the WIP spec.

Building Tools

Coding a Weave Tool is a matter of updating a standard Holochain hApp in a few ways.

It's trivial (a 5 minute task) to simply update your hApp to run in the context of a Weave Frame, this just involves getting the AppAgentClient from the Frame instead of building it directly using the holochain-client library.

It takes a little more work to add support for other aspects of the Weave Integration Protocol, but each of these affordances (searching, linking, embedding, creating) can be added one piece at a time and are not a heavy lift. Detailed instructions for how to add can be found in the client npm package docs

But the easiest approach may simply be to clone any one of the Moss Tools (clicking on the icon takes you to each Tools's github repo), and modify it to your needs. That's what we often todo!