Technical requirements for "Neighbourhoods-compatible" software

Technical architecture for NH-compatible software

So, sortof an aside but I can see the need for a few app-specific components to make this ergonomic:

• Some integration with the conductor to allow adding other running DNAs to the app bundle (Need to check that this is feasible.)

  • Some facility to re-share such configurations (probably app bundles can just be content-addressable?)

• Dynamic loading and injection of UI modules via conductor

  • Can do these as WebComponents served from an index file that bundles commonjs modules

    • NH apps would have to include this bundling as part of their build process in order to offer UI elements to other apps.

    • Lots to think through here: universal module format, dynamic inflation, build pipelines for other runtimes. Folks in the HC ecosystem have been thinking about this already (Nicolas Luck & Nathan Waters come to mind).

• A tab in the app’s ‘settings’ UI for… ‘customize’? ‘fork app’? (How to make this label legible and intriguing?)

  • Configuration section for each datatype, broken down by display context

  • Datatypes could be sourced from DNA metadata or zome API traits

  • UI WebComponents could be sourced from a predefined JavaScript URI that NH-compatible modules provide

  • Assignment of “pluggable datatypes” which are associatable via “base entries” (eg. https://github.com/pospi/holo-threaded-comments) & compatible zome API traits (I guess another nod here for real groups to drive demand for the components they feel are necessary, and for us to develop UI widgets based on that demand)

  • For each “display context” of an “app datatype”:

    • a UI for managing the available UI components of the assigned “pluggable datatypes” for the “app datatype” is created

    • saving the configuration overrides the base “display context” for the “app datatype” with the specified UI components

      • The UI components themselves handle all bindings to the DNA layer, so no configuration is necessary other than dropping them in.

• DNA module for storing personal UI configurations and for sharing them with others

  • Default configuration for the app UI available (We could make this a requirement of NH apps?)

  • As well as any other custom configurations app devs might want to offer. We could even deploy these as globally available networks.

There is so so much going on in this section. Maybe we pull it into a separate thread of its own? Will bring it up in tomorrows sync as well.

Done! (: