requests-and-offers, a peer-to-peer bulletin board for the Holochain community where creators, developers, and organizations post requests and offers for services, skills, and resources, has an open pull request from @AlchemicalSpiralizer that mirrors listings and exchanges into hREA, the Holochain implementation of the ValueFlows vocabulary. Opened on 11 September 2026, the change is proposed, not yet merged, and the project remains in alpha with breaking changes expected.
For people using requests-and-offers, the mirror means a listing can appear as a proposal with 2 reciprocal intents, an accepted exchange as an agreement with commitments, and each party's mark-done as an economic event. The author verified the flow live on 2 peers and with the full Sweettest suite.
The mirror links two DHTs by chain roots
The author says the root defect behind the mirror's history of silent failures was the absence of a shared identity model between the two DHTs. This pull request implements one: chain roots are the cross-DHT join key. References carry true Create-action hashes, resolved by the requests-and-offers DHT itself, never chosen client-side. Link anchors are normalized at receipt in the zomes, because approval mints entry updates and unresolved references would scatter links off-root. A regression test encodes the rule, failing against the old code and passing with this change.
The author also patched a dependency, vf-graphql-holochain through 0.600.0-rc.0, because its
create_rea_economic_event returns an envelope the generic createEntry helper reads as a bare record, crashing every createEconomicEvent. The fix uses Bun patchedDependencies, with an upstream issue to follow.What a builder has to change
Builders integrating hREA 0.4.0-beta must send an empty list for
ProposalCreateParams.publishes at create and link intents after. The zomes reject client-supplied created, due, and hasPointInTime fields; hREA stamps receipt, and requests-and-offers' own times live in its DHT via note references. Measures need real Unit record ids, seeded at initialise, with a label registry backing structured measures and prose-in-note degradation for unregistered labels.The author flags known deviations: the store helper stack predates this branch and does not use the withLoadingState/EntityCacheService stack, there is no composables layer, and the zomes do not know hREA exists, so the integration is UI-layer only. Deleting the handler wiring in
hrea.store removes the mirror entirely. The zome changes for link normalization are general identity correctness for the requests-and-offers DHT.Verification: the full Sweettest suite runs 17 files and 58 tests, all green; svelte-check reports 0 errors; vitest passes 606 of 606 tests; and the flow ran live on 2 peers twice. A reconcile-at-boot change is queued as its own pull request, with a named hazard: the mapping maps are RAM-only, so retroactive creation before note-derived mappings would mint duplicate proposals into an append-only ledger.