Analysing Holo-REA technical viability for use-cases

I’m going to provide a few rough thoughts based on murmurings from @kristofer & @ViktorZaunders in this thread. @lynnfoster or others may want to add more info below…

Short version: what you’re proposing (local food buyers clubs and cooperatively run grocery stores) is not only possible with the framework, it’s exactly the sort of use-case we’re designing for. And Holo-REA is ready to be used in that capacity.

We have also done some other prototypes in enterprise environments and have realised that the loosely coupled nature of our modules allows Holo-REA to solve for complex regulatory situations with strict privacy and accountability constraints, without requiring any code customisation or complex deployment. In the end it mostly comes down to app bundles or conductor config files. Eventually we could drive this via network setup wizards / config hApps.

Longer version:

There’s some new stuff in the example directory in our project repo which shows how to extend the core functionality with custom resource attributes or domain-specific knowledge systems. The former is what you need for adding per-resource metadata, the latter for functionality that applies to an entire classification of resources rather than individual items.

We think in at least 98% of use-cases these are the only customisations people will need. The resource attributes generally end up being pushed into related modules (one in particular seems in high demand; but we haven’t yet built a measurement DNA for storing IoT sensor data to be referenced in resource quality inspections). So probably in the majority of cases, it would just be knowledge system extensions.

These are queries like “find me all the types of beef in the supply chain that have an O- blood type”, which yield lists of ResourceSpecifications. You then query on the basis of these specifications to select sets of EconomicResources stored in Holo-REA economic ledger DNAs.

As to the other mixin zomes you’re identifying, yes! We will need those soon as well.

  • Group agents
  • mutual credit: we would probably do these with ResourceClassifications for currency resources. You can then use the standard EconomicEvent API to manage increments & decrements, see here.

Not sure what your needs are for these, if you could unpack more that would be interesting!

  • group wallets
  • shared budgets
  • voting
  • private transactions: would like to hear more. I think you could do these with private entries & the messaging API. Would also like to see QR codes for offline transactions.

I think upgradability is a core thing, and something I sense a strong need for. Without this, I can’t yet hand off Holochain apps to anyone knowing that their data will be safe moving forward… they need off-ramps to get them to future upgrades and bugfixes…

9 Likes

Thanks @pospi ! A few small (also rough) notes:

mutual credit: we would probably do these with ResourceClassifications for currency resources

I think ResourceSpecifications would be best, but same idea.

group wallets

Once we have group agents, then any agent (group/organization or person) can have a wallet in the same way. A wallet should be an economic resource like any other, except you may want to connect it to the currency’s technical mechanisms to actually do the transfers, and possibly to get balances, which would be extra work beyond Holo-REA, and probably currency-specific.

Good to see more on this, as we’re developing synergies in a number of these areas.

Awesome @pospi, I’d love to get into that. Doing a design session or something like that to start mapping things out. Not totally sure when the time for that is going to come though, the coming few weeks are pretty hectic here :sweat_smile:

Smart contracts

Paul Frazee, creator of Patchwork, the first flagship SSB app, on smart contracts without blockchains:

You create the contract with an INIT block that declares the source code, then run the code against the log.

Each participant creates their own log which the contract can add. Now you’re weaving multiple logs together

The “executor” reacts to new blocks in each log according to the contract code.

This would be nice for things like DAOs and forums and software distribution, where you have a group of people collaborating on the database state and don’t want the costs of a blockchain

1 Like

Sounds like convergence! :ok_hand::slightly_smiling_face::v:

Wondering whether he’s aware of and understands Holochain.

2 Likes

Good question! I’ll ping him in SSB and ask him to comment here. But he’s not in SSB as much anymore, has moved his attention to new networks based on different but somewhat similar protocols.

1 Like

P.S.

“Trustlessness,” one of the Bitcoin blockchain goals, is a dead end road.

-Kip Twitchell

2 Likes