book: extend wallet.md section with specifics on plugins wrt to scene…

… graph

doc/src/arch/wallet.md

@@ -266,6 +266,89 @@ Multi-platform main view with splitting and these editors:
 * Explorer
 * Settings
 
+## Specifics
+
+### Story
+
+The story goes like this. There's a node running of some kind. This could be
+darkfid or darkirc.
+
+In the case of darkfid, there's additional per wallet processing that's done
+such as scanning transactions. Currently this is the role played by drk scan.
+
+Regardless of whether there's one node with functionality existing as pluggable
+modules, we assume now there are nodes running which the wallet/UI must
+communicate with.
+
+Inside the user wallet, there are multiple plugins. A plugin might need to
+query the blockchain, spawn a p2p network (to exchange data for OTC or
+coordinate DAO activity as examples). They do this by connecting to the nodes.
+
+### Key Concepts
+
+We now give an overview of the current iteration of the scene graph:
+
+* Nodes have a type. Each node can have multiple children.
+* It is a graph not a tree. A node can have multiple parents.
+* Each node has several properties which have types such as f32, u32, str, enum.
+  Properties can also be an array or vec of these types.
+  See `bin/darkwallet/pydrk/api.py:5` for the fields in a property.
+* Nodes have signals such as `mouse_clicked`. Multiple slots can be
+  registered for a signal. Think of this like notifications.
+* Nodes have methods such as `create_foo()` which is like request-reply.
+
+### Plugins
+
+Each app has a separate plugin. Plugins have their own private internal data.
+Any data they wish to expose can be done by providing properties or methods in
+their node in the scene graph.
+
+The scene graph then applies access restrictions depending on the ownership
+semantics of properties and methods (think like UNIX users and groups).
+
+Plugins provide `init()` and `update(event)` functions. `init()` is called when
+a new *plugin instance* is created. Plugins can have multiple instances.
+
+Using the scene graph, this is scriptable from any language, introspectable and
+with permissions - using a data structure inspised by UNIX and plan9.
+
+#### Example
+
+When a plugin is opened, the UI creates
+
+```
+    /plugin/dao/instance1
+```
+and gives it a layer to draw in, which is simultaneously linked into both
+```
+    /window/dao_instance1_layer
+    /plugin/dao/instance1/dao_instance1_layer
+```
+
+The plugin can then speak with modules by calling methods or subscribing to
+signals on `/mod/darkfid`. Methods and signals are automatically proxied from
+the node.
+
+### Running a New Node per Function
+
+Lets say we wish to do OTC swaps and utilize the event graph. Are users then
+required to run a new node per app?
+
+At least in this case, there should be a way to spin up an event graph.
+
+For scanning transactions, is this done at startup incurring an initialization
+cost when opening the wallet? I guess so to maintain independence of keys from
+the darkfid node.
+
+Another example is the task manager and darkirc chat. Do these remain separate
+daemons? When we add swarming support to p2p, it might be possible to merge all
+p2p functionality across apps into a unified subsystem, reducing complexity.
+In which case there should be a simple way to utilize this subsystem.
+
+The more nodes users are required to run, the more difficult it will become to
+have a decentralized network, so we should find a way to reduce the burden for
+users to setup our infra.
+
 ## References
 
 * [Veil: Private Browsing Semantics Without Browser-side Assistance](https://mickens.seas.harvard.edu/files/mickens/files/veil.pdf)