Holo-REA and unenclosability?

[zeemarx_jeremyboom8]

How does unenclosability relate to Holo-REA?

Evolution from:
Black box Corporate ERP systems > P2P transparent REA Open Value Network?

Where is the unenclosability?

I’m most curious about perspectives from @pospi @lynnfoster, yet I am happy for others to jump on this thread too if they want to share theirs

Follow up question:

How does bridging work and how do Zomes and DNA’s work here? In a Holo-REA app, what is the difference between the use of them? Compared to a centralized Ruby on Rails/MVC ERP app, what are the changes, and the new opportunities of modularity?

I enjoyed the pdf with the slides of the cake recipe, and wonder if it could be enhanced by a comparison to how corporate ERP systems work today? To show what is used today, and how it could be done in an open P2P way.

E.g. evolution/transition from:

Corporate-IKEA → OVN-IKEA

or

Corporate-iPhone → OVN-iPhone

or

Corporate Supermarket/Food store → ONV Supermarket?

What internal systems changes are required, and in the way we work, in these examples?

I personally find having the old system contrasted with the new system to be the most clear. Often times there are structures i have not met in todays corporatized world, but that we will likely become more proficient in, in a Commons based society. In this way I learn both how it is done behind guarded walls today, as well as how the intent (or expected output) of these systems is carried over, but how the delivery/production method is changed.

[lynnfoster]

@zeemarx_jeremyboom8

How does unenclosability relate to Holo-REA?

Not sure I totally understand the question, but I’ll give it a try. I think of encloseability in relation to commons. Assuming you are not talking about code, but the actual resources being coordinated and accounted for using Holo-REA, then the question goes much farther than Holo-REA’s influence. A black box corporate ERP system could use Holo-REA. But Holo-REA does provide mechanisms you won’t find in traditional ERP systems that directly support and encourage open networks or cooperatives or other forms that go beyond capitalist organizational structures and relations - as well as new yet-to-be-thought-of experimentation in that direction, I think.

That doesn’t mean commons coordinated through Holo-REA can’t be enclosed. Seems like a separate political power and governance issue? Which Holo-REA is again agnostic about, except that it provides very flexible relationship structures for people and organizations, so gives the possibility. And will I think in the future provide more direct support for value equations and other economic governance.

How does bridging work and how do Zomes and DNA’s work here?

Above my pay grade, @pospi is the right person, but there was actually some discussion yesterday here https://forum.holochain.org/t/modularity-hackalong-bridging-whats-the-best-way-to-do-it-what-new-dimensions-does-it-open/4032.

What internal systems changes are required, and in the way we work, in these examples?

This sounds like it would take a book with several authors.

[zeemarx_jeremyboom8]

@lynnfoster

Not sure I totally understand the question, but I’ll give it a try. I think of encloseability in relation to commons. Assuming you are not talking about code, but the actual resources being coordinated and accounted for using Holo-REA, then the question goes much farther than Holo-REA’s influence. A black box corporate ERP system could use Holo-REA. But Holo-REA does provide mechanisms you won’t find in traditional ERP systems that directly support and encourage open networks or cooperatives or other forms that go beyond capitalist organizational structures and relations - as well as new yet-to-be-thought-of experimentation in that direction, I think.

thanks for your responses Lynn!

[pospi]

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 GitHub - django-rea/rea-app: Multi-platform UI application for OVN (Open Value Network) & REA (Resource / Event / Agent) backends- including Sensorica NRP, FreedomCoop OCP, GoPacifica DEEP & eventually django-rea project..

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

[zeemarx_jeremyboom8]

@pospi

In other words, enabling external parties to track and record waste flows and externalities which a dishonest actor may choose not to publish—

Do you mean, in other words, that it allows someone to 1) participate in an app about some production process, 2) host the data, and 3) add/publish new info (such as polluting waste) to the network?

A comparison I’m thinking of: in a public park with a lot of children playing, the more parents there are paying attention, the higher the chances of any conflicts being stewarded to peaceful resolution. If for some reason there was only 1 parent, with 10 children playing, that sole parent would probably have a really hard time seeing what’s going on, and have a hard time guiding the kids to a peaceful resolution if a conflict happens due to not being able to see all interactions

Still reading the rest, will comment again if i have more questions.

Edit: no questions! I feel excited, thanks for your response

[pospi]

1) yes, 2) yes, 3)...

3 depends on what “participate” in 1) entails. Consider that there may be a network held by the local police department, connected to CCTV and facial recognition that can track who enters/exits the park. Obviously, parents using the park would not have access to this network.

But they could always start their own network, and volunteer to publish their own data about who comes and goes. The question is how to make other parents aware that such a network exists, and how to get them onboarded. In this case, probably word of mouth would do as an invite mechanism.

Now zooming back out to the non-trivial (where the presence of networks may implicate activists in their activities, say)- I expect we will see various arrangements of fractally composed “broadcast” network spaces with varying levels of trust and acceptance criteria required to enter. Network spaces effectively playing the role of transmitting, “Hey! I created a space for parents to help keep the playground safe over here!”

Hope that answers your question?

[pauldaoust]

Looks pretty darn good to me @pospi; just a little correction:

@pospi

• 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).

There are two levels of privacy for a network:

1. Each network is identified by its own space ID, which is the hash of the rules it’s playing by (its compiled WASM code) plus some metadata (for instance, you could ‘fork’ one set of rules into two private spaces by adding a random UUID to its package file). If you don’t have the hash, then nobody is going to talk with you. (There are ways to steal that hash, I guess – if you manage to find the source code or discover its hash using a side channel, like breaking into a participant’s computer.)
2. Each node has their own self-signed TLS/SSL certificate whose key pair is separate from their identity key pair. (Not sure why they’re separate; I should try and find out.) This prevents eavesdroppers from learning either the network space ID or the content of the network’s messages. I’m assuming it’s TLS 1.3 using the strongest cipher suites currently recommended, because we don’t need to worry about legacy implementations of Holochain

A side note about proxies: to get around the problem of restrictive firewalls, Alice (behind a corporate firewall) can announce that she can be reached at Bob’s node, because he’s agreed to proxy for her. When Carol wants to connect with Alice, she talks to Bob, who opens a new connection for the two of them. It’s now up to Alice and Carol to set up end-to-end-encrypted communications on this channel, with their own TLS handshake. Bob is completely blind to all the traffic between them, including which network spaces they’re talking about.

@pospi

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.

Oh, this is really good stuff! Mind if I quote you on this? I’ve heard some people (Tom Gowan, for instance) say that Holochain feels like a build-your-own-database library; would you say that’s also true? If so, does that add some overhead vs just talking to a Postgres or MongoDB instance?

[pospi]

On the language & naming of things between different Holochain versions, some corrections here- Holochain RSM Migration Guide - HackMD

One other thing I think is worth commenting on in that document is the change from “remove” to “delete”. I think “delete” creates the false expectation that the data is actually gone… there was something in the original terminology that felt more ‘honest’. Though neither is really accurate- should be more like “retire” or “deprecate” or “tombstone”.

But yes- all this also in answer to your question about Postgres. It does feel like a “build your own database library”, but it also feels much reduced in complexity due to that reality. Talking to Postgres means learning SQL and probably its gibberish JSON extensions, then doing a bunch of expensive parsing and serialising and error checking across a membrane into the database. The adapter code you need to write to do that is essentially the overhead. For Holochain the API bindings are direct, and so you only need to learn one interface— that of the Rust API aka “the HDK”.

Oh yes and please quote away

[pauldaoust]

@pospi

One other thing I think is worth commenting on in that document is the change from “remove” to “delete”. I think “delete” creates the false expectation that the data is actually gone… there was something in the original terminology that felt more ‘honest’.

Hm, very interesting feedback; worth bringing up with the core team. If that doesn’t get changed, @e-nastasia @sidsthalekar and I are rewriting the Core Concepts, so I’ll be sure to talk about that in the CRUD page.

[pospi]

“deprecate” or “retire” feels like it could be appropriate nomenclature?

[AdamThompson]

It appears that there is no way to transfer a currency from one DNA to another… Have you thought about a way to do this with REA??

[pospi]

A little, want to co-speculate/design together? I think it ends up looking like coordinated records in difference cells.

Using the REA event ledger as an example, in one cell you can reference an EconomicEvent which transfers assets to an external EconomicResource — so a record local to this cell will be decremented, another in a remote one updated. Currently, record identifiers are specified as (DnaHash, EntryHash) tuples and requests are forwarded to remote cells via a handshake-based authentication mechanism (though that library is still a WIP) in order to keep records in sync.

Usually I try to stick to the pattern of running critical remote-cell operations first and failing early before updating entries in the local cell. But there are also some scenarios where you want the success/failure of the remote indexing update to be non-critical, eg. in mixed-authentication network environments.

Then there are some other patterns like REA’s satisfaction and fulfilment, where cells actually drive each other to duplicate records in both places, since both sides of the network boundary have an interest in the information. The observation cell wants to know how many EconomicResources were promised to fulfill local EconomicEvents; the planning cell wants to know how much of its Commitments have been fulfilled by remote EconomicEvents. These “joining” records (which act somewhat like compound keys in traditional RDBMS) allow cells to separate data into discrete (and complexly cross-referenceable) network spaces and preserve privacy whilst exposing enough information to allow neighbouring spaces to anticipate and coordinate private local actions.

The RSM upgrade is going to tick off a lot of older v2 milestone issues originally slated for a hREA beta release… all the more fine-grained network architectures are easily achievable now that the CellId construct has been brought to the surface

[jakintosh]

Not to bump an old thread with maybe a dumb question, but hREA and Commoning are the things I’m most excited to build against in holochain and I’m still learning, so:

What exactly do we mean here by “unenclosability”?

[jeremyboom8]

@jakintosh

What exactly do we mean here by “unenclosability”?

I sent this in a PM to Jak but didn’t want this question to seem unanswered so posting it here too:

zippy314 - 3 days ago

The language of enclosure we use comes from it’s use in political economy regarding the enclosure of the commons. In that case enclosure of the commons was about political rules for removing access to a commons space and converting it into a space owned and controlled by a powerful elite.

In the Holochain case the intent is to restore commons spaces not as a matter of political ruling but simply as a matter of architectural fact. Unenclosable means that no outside party holds the power to stop a group of people who want to play [a] given game together from doing so. Currently the main locus of enclosability in web app architecture is the web-server. Who ever holds the sys-admin rights to that server has defacto abilities to stop the app.

What makes Holochain unenclosable is the combination of it’s three parts, 1) DNA, all agents hold the “rules of the game”. 2) All agents make all their own “plays” locally on their own machines in the form of commits on their source-chains. 3) These commits are shared with [and] validated by, and stored by other “players” on the DHT.

These three things add up to unenclosability in that players who play by a game (a DNA) all know they are doing so. Only the players who want to play are needed for the game to work. Nobody else need be involved. Thus it’s an architecture that’s unenclosable.

Of course there are parts and levels of the system, i.e. the ISPs involved[,] that can effect enclosure to greater and lesser degrees, but Holochain fundamentally can (and will in the future) work over unenclosable carriers as well, i.e. mesh-networks[,] and other network topology and transport systems.