Wed 26 Aug 2020 3:02AM
Technical requirements for "Neighbourhoods-compatible" software
pospi Public Seen by 9
Specifically, in the context of building Holochain apps and leveraging the platform's intersubjective capabilities to their full potential.
Sid Sthalekar Wed 26 Aug 2020 1:13AM
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.
pospi · Tue 25 Aug 2020 5:10AM
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
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.