Black box Corporate ERP systems > P2P transparent REA Open Value Network
This is pretty spot on, and more or less how https://www.sensorica.co/ & collaborators talk about the original https://github.com/django-rea/rea-app/.
I’d add to Lynn’s answer on material enclosability that a key aspect afforded by this generation of software that “you won’t find in traditional ERP systems” is that of fractal composability. This has an impact on a group’s ability to manage and protect a commons in that it allows anybody to add additional data as an overlay on top of a closed network. In other words, enabling external parties to track and record waste flows and externalities which a dishonest actor may choose not to publish—
Since Lynn has covered the physical aspects pretty well, I’ll try to give a bit of a different perspective from that of information enclosability.
Information security is a complex subject and we’d have to talk about specific threat models to arrive at anything remotely concrete, but I can at least tell you these things:
- All traffic within a Holochain DNA (network) is encrypted with a shared SSL key. I’m unsure of the exact cipher & key strength, but presume it’s pretty robust.
- Holochain agents are identified within these networks via public key alone. Again, I’m unsure of exact details and would love anyone who knows to add them here (CC @pauldaoust).
- A Holochain hApp bundle (in this case, a Holo-REA “instance”) is composed of multiple separate DNAs.
- Agents need not have the same public key in every network within the bundle (though it helps to keep things simple and we may code it this way… need more info to determine if we’re foregoing anything there…)
- Acceptance into each DNA is enforced by all peers, via verification of a “joining proof”. Without this proof, no data will be synced and effectively foreign agents cannot enter the network.
- In Holo-REA’s module architecture, each Holo-REA “instance” is considered a collaboration space and all records are written publicly into the shared space. In future we may opt to keep some private, but for now each “instance” (set of cooperating DNA microservices) is considered a shared, trusted space.
- Holo-REA “instances” may reference each other in an ad-hoc fashion. Currently there are some limits to this, but eventually such flexibility will exist down to the record level.
- Holochain networks can only be disabled if all nodes participating in the network are shut down and wiped.
The result of all this is that you have some small, simple components that act as private, secure, un-eavesdroppable network spaces which can be combined together in limitless ways. Various arrangements yield various permission structures: for example, a private business network’s internal bookkeeping system connecting to their client-facing work management system connecting to a public freelancer hire marketplace.
Or, the private details of the management of a commons connected to an environmental watchdog’s public alert & compliance system connected to a set of corporate networks that provide compliance and production data.
How does bridging work and how do Zomes and DNA’s work here?
I think I’ve summarised some of that above, but these are essentially the building blocks of Holochain apps. Much of this has changed in RSM and I haven’t yet updated my code so some of this is a bit speculative… I’ll try to indicate where I’m unsure and do a bit of a terminology mapping.
Webservices HC 0.2 (RSM) HC 0.1
============= ============== ========
Internal HTTP Event hooks(?) Bridging
Code library Library(?) Zome
microservice DNA DNA
So, yeah, I’m a bit unclear on the revised terminology myself but expect that all the basic building blocks for composing services and connecting them together will be there as before.
Compared to a centralized Ruby on Rails/MVC ERP app, what are the changes, and the new opportunities of modularity?
There isn’t much difference compared to traditional microservice app architectures. If you have ever built a clustered web application then you’ve more or less had to deal with the same kinds of architectural concerns. The main leap is in usability… far fewer variables to consider when building Holochain DNA modules than when building nodejs apps talking to DynamoDB on AWS Serverless, for example. With Holochain, you get to focus on the bare essentials of storage, business logic and inter-module API contracts.
I think the new opportunities here come as artifacts of distributed architectures in general. Content-addressable identifiers and link traversals are the new norm. These things make linking between objects stored in disparate networks much simpler and more flexible, allowing one to start developing loosely pluggable modules which can reference each other and be swapped out for altered functionality.
Some of the components in Holo-REA are already pretty good examples of this. Here’s a set of tests for different module configurations that various usergroups may wish to tailor to their specific needs. There is probably more modularising to do, FWIW— it’d be nice to be able to drop inventorying functionality from a system for those who only need to track raw event observations.
Hope these reflections help some, let me know if you’d like to go deeper into anything in particular