Sensemaker As a Mixin Zome Instead of Stand-alone Cell?

[weswalla]

As I am going through the NH-Launcher code and strategizing about how to refactor and lay out a path for more test coverage, I now wonder if we should use the sensemaker-lite as a mixin zome for a NH cell rather than a standalone cell. Below I outline what I see as the main considerations/trade-offs around this.

In the NH-Launcher, whenever a new neighbourhood is created, two cells are cloned (we and sensemaker, both of which belong to the we happ (see below diagram for visual reference)

Reasons to treat sensemaker as a mixin zome:

• there will always be NH-wide info / functionality not contained in the sensemaker (group name, applet metadata) as the sensemaker's concerns are metadata collection, indexing, and performing computations across that metadata.
• simplifies the creation of a new NH (as only one cell is to be cloned, the we cell - which should be renamed to neighbourhood)

Reasons to keep as a stand-alone cell:

• perhaps we will want a 3rd party computation plugin system (on-the-fly coordinator zomes?), by isolating the sensemaker as a stand-alone cell it sandboxes this future plugin system

Thoughts @pospi @julioholon @adaburrows @nick-stebbings ?

[pospi]

See these user stories as related explorations to this query:

• [STORY] As an Applet developer, I want to provide automatic bindings between my Resource data fields and Assessments #65
• [STORY] As an Applet developer, I want to author Sensemaker adapter modules for my Resource types #64

[pospi]

I don't think there's any particular reason not to deploy Sensemaking data locally adjacent to Resources (which, in our current terminology, is essentially what this is saying).

Question: can Cells be dynamically composed from zome WASMs at runtime within the NH Launcher application?

^that's about the only practicality concern. Migration complexity is another, but I imagine that the Sensemaker integrity zome structs wouldn't change all that often since Assessments and Dimensions are such integral concepts in the design.

I also like this arrangement from the design perspective of 'locally-adjacent context'. Most of the more complex logic in hREA is in supporting libraries for managing associative indexes, temporal indexing and history retrieval behaviours. It was always crucial that the additional context for such information be provided equally to anybody with access to the unindexed content-addressable entries themselves. When such inference capabilities are externalised I believe you end up with power imbalances in the network architecture and groups forming their own external contexts as invisible 'power over' the content in shared layers of a distributed data lake.

Still, maybe there are contexts within which these data arrangements make sense. We could explore this as 'detachable' shared Sensemaking contexts; i.e. the capability to copy Assessment data (with provenance) out of some existing community and into a new Sensemaker zome; or the mechanism for porting into an existing community as a set of verifiable credentials.

In all these cases we should be considering replication of Assessment data across the DHT space, and partitioning networks as appropriate to maintain appropriate human trust boundaries in the sharing of information. Which is to say- just because you don't have access to some data through a zome API call does not mean that you haven't had the information underneath it gossiped to you.

So, it is interesting to think about storing shared Sensemaking indicators in the part of the network fabric that the 'records of import' are written to. Different methods of managing the flow of public & private Assessment entries within these locally-adjacent Sensemaker zomes could provide for a great deal of fidelity and is a topic worth exploring further.

Thirdparty computation plugins are also a very interesting prospect. In this case, the NH Sensemaker would conform to a well-documented open API format which binds to SensemakerService, and different logics for varied Sensemaker operations could be implemented against that protocol. Any language or framework that compiles to WASM could implement something. Eventually a Method.program will just take a string, and people could write the code and its underlying interpreter in whatever format they like.