@guillemcordoba this has been a fascinating read & thought experiment, thanks for sharing!
First off I completely agree with you on generic zomes that don’t need to interface with any particular kind of entry. You’re foregoing referential integrity of those links in doing things this way, but until we have more advanced cross-zome messaging traits I can’t see us achieving that. Eventually though there will be a need to solve for “you can’t create a comment that points to something that doesn’t exist”, and I expect zomes will need to use URI resolution to determine that the things they’re referencing really do exist. For use-cases like the economic ones we’re solving for, these constraints really matter— someone adding an orphaned record could really throw some calculations out in a way that has serious consequences.
Here are some other places where we have needed to use bridging so far:
- Cross-DNA index replication (see fulfillment as an example). In these cases we have “links with context” that need to exist on both sides of the network boundary, since participants may be isolated to only 1 of the collaboration spaces. This is essentially data replication, and you need bridging to achieve it with any degree of robustness. Note that
lib_origin manages search indexes for the
Commitment side of the relationship, and triggers API calls in
lib_destination that manage search indexes for
EconomicEvent. The identical
Fulfillment entry is stored in both zomes. This allows participants who only have access to the events to follow references to the fulfilled commitment, and vice versa.
- When the attributes of a record (such as satisfaction) reference records in other DNAs, and the behaviour to take depends on which type of record they are.
There are also some use-cases coming up that we will need it for:
- We will need to lock down a zome so that it must be bridged to a particular foreign zome, and code it so that it can only use identifiers from the records kept in that zome. The use case is for networks that have a particular restricted set of available resource types- they need to verify with the configuration zome that they provided parameters check out. So it’s actually a stricter kind of “does this hash exist” check.
Group agents. The only way I can see for this to work and to be architected sanely is to define a set of well-known zome traits that group agents should respond to, and then to bridge group agent configuration DNAs in to all the networks that group wishes to participate in. For these cases, the group-compatible zomes would have to be coded to perform access checks etc against the group agent DNA.
I imagine there will probably be a lot more things being implemented with this type of pattern as community members continue to experiment with pluggable modular behaviours… basically anything which requires robust business logic needs to be done within the DNA layer.
It just feels weird to build on holochain, and only really works when you add Holo to the equation
I’d push back on that… for our needs, HOLO is the least interesting thing in the equation. We want locally installed productivity tools that run inside the HC conductor, and we also want to default to agent-centric shared data sovereignty. HOLO has some minor utility for being able to put a project progress dashboard on our website, but little else.
I think your perspective here depends on how you envisage people using the technology down the line. The stuff you’re talking about is web tech, so naturally it’s built to talk to other web tech. But web tech is also a calamity of errors, soooo… is this kind of arbitrarily-linked, poorly-permissioned, non-sovereign, corporate-owned environment where you see people doing their daily work 5-10 years from now?
I don’t really have an answer but my hope is “no”. I’d hope to be integrating with data more directly, pulling more of it down onto my machine and running it through local analysis tools that make such tasks easy. I see it more as “distributed tech needs to replace the web” than “the web needs to become re-decentralised”. HOLO to me is just a way to make Holochain data accessible to people still working in the old paradigm- a compatibility measure.
I’m planning on running a code deep-dive on Holo-REA fairly soon. The
_Prtcl project looks really interesting and I’d love for a session on that to be run next. I can see echoes of some of the work @wollum did early on in trying to create generic GraphQL interfaces into zomes in order to define entire apps declaratively, and I’m particularly interested in exploring whether your frontend libs could generate a lot of the boilerplate Holo-REA has been doing manually. I can see the project being very useful in creating generic UIs that span multiple apps / platforms.
The biggest question I have with the framework is: how many safety guarantees are you giving up? What I have with GraphQL now reduces the possibility of error quite dramatically… I’m not sure it would be possible to protect against invalid types / field names / data structures and to bind the frontend & backend together as tightly as I am able to…
You might be interested in connecting with one of the groups who has been posting in the OAE lately. Kendraio are building a schema-based UI / API interface that allows them to plug many services together arbitrarily. Their system seems to be evolving from JSON-schema and other DSLs into fractally composable grammars, so it’s quite interesting. May benefit a lot from
FWIW @pauldaoust there is a proposed URI scheme for Holochain at the bottom of this document which has some legs. But what you’re saying about an RPC-based URI scheme might be more sensible given the way things are addressed. Or maybe we need to standardise traits for content-addressable addressing?
not publicly accessible from the internet
I think we’d need to translate the protocol scheme at the app UI layer, huh. So basically if you’re running a HOLO app you could show http(s) URIs that wrap the actual underlying Holochain entry data. Those pages could even expose RDF data. Would that work?
Conscious this is getting a bit long, and possibly going off topic. Feel free to split to new threads if you think it’s appropriate (;