I wanted to take a moment to shed light on HoloREA’s current status and in the process hopefully gather up some Rust developers from other projects who might be interested in helping us package HoloREA for third-party integration.
First release: MIP
There is not much remaining work for our first milestone, which has evolved by necessity into what I will call the MIP, or “Minimum Integrateable Product”. The goal for this release is to have the 3 core DNAs needed by nearly all REA-based systems (“observation”, “planning” and “specification”) functional for use in trusted environments.
In this version there will be:
- no access control
- no protection from cheating record timestamps
- no counter-signing of records
- no agent profiles (Personas hApp can do that for now)
- fluctuating internals (including possible changes to the zome module structure)
- stable GraphQL API
That should be ready before December but it’s also hard to guage, given that I am putting new developers through the process of getting comfortable with the architecture by having them implement the “specification” DNA.
The idea behind releasing an MIP instead of waiting for a more secure MVP is that the above features should not play too much into most third-party integrations; and while HoloREA continues to work towards MVP there is no reason that others can’t be working through integration with their own projects. It is also possible that the above features could be implemented in a third-party DNA around HoloREA for those with timelines ahead of ours.
Second release: MVP
Following MIP, focus will be on addressing the above limitations and on testing; basically to get to a production-capable MVP. A lot of that work is already logged but other things may come up as MIP progresses.
Future release: code polish
Beyond a functional MVP, we want a polished MVP before going too much further. At this stage we are not planning on developing any backend modules besides observation, planning & specification until existing code has been audited, cleaned up and abstracted as needed. This is particularly a case of getting a code review from various core and hApps team members on our graph record architecture and exploring alternatives. It is also about reducing boilerplate and wrapping up common functionality to make authoring further modules easier.
Future release: improved multi-DNA support
The other thing we require to really build what was envisaged is better support for complicated bridging configurations. A lot of this won’t be achievable until certain restrictions and underlying capabilities are delivered by Holochain core. This milestone might end up taking a back seat for a while, we’ll see.
Other workstream: ValueFlows UI project
There is also the matter of a VF-compatible UI project. This isn’t part of HoloREA as it has scope beyond Holochain, but is still a part of the overall project. There is a lot of groundwork to lay before really making a proper start of this, because a custom build pipeline needs to be configured to publish WebComponents that are compatible with React, Angular and any other web UI frameworks of choice; as well as working well with GraphQL.
In the meantime we might make prototype interfaces or play with old UI kits (eg. Hylo’s); but doing this is essentially making plans to throw away (or adapt) work because forcing React on people isn’t going to cut it for our long-term needs.
Your input?
Beyond MIP and MVP, none of the order we’re approaching things has been decided. There are various projects circling that may be worthwhile engaging with more deeply in the new year; with requirements such as generating GS1 and SEEA data from REA events. I see such standards integration works as being of high priority in embedding REA systems in institutional and other contexts that will help to push broader adoption. But that’s just me- I’m a protocol & interoperability geek, and my mission right now is propagating REA.
But my time is also limited, our capacity is really very limited, and it will probably end up being some combination of “first come, first served” and “what features are the most use-cases clamouring for?” If you have needs that you think should influence our roadmap, please let us know in another thread or file a new issue as a user story!
Devs needed
On the “capacity is really very limited” thing, another experienced Rust developer would really add a lot of value to us right now and would free me up to do devops / scaffolding for the VF-UI project.
If you’re salaried and your company wants to help contribute to HoloREA development, we consider your time a paid investment and your company would be thanked for financial support in our contributors list 
If you’re unsalaried, it’s been a goal of ours to set up a https://www.comakery.com/ instance for a while to handle ad-hoc payments for delivering work. The goal is to expand those requests and bounties into design work, writing and research in future. In the short term it will just be a case of posting any efforts you’re seeking reimbursement for on CoMakery, and our team reviewing the work & making crypto payments (currently we plan on using USDT for this). You can also just ping me (same username) on Github issues if you’re interested in taking them on.
When I eventually find the bandwidth to set the payments stuff up, further info will be posted in the main project channel.