For the record, with @hedayat we implemented a similar pattern here, without the hashing privacy mechanism.
I don’t think it would be wise to mix both codes since they mainly fill the same role: they are a “membrane zome” that only cares about who is allowed to enter the network. And their behaviour seems pretty exclusive: either you have a list of valid members, or the membrane can be dinamically extended by those already inside it.
It does seem worth it to develop as a standalone mixin though. Right now I don’t have much time to develop it but I think we’ll need it in different projects in the near future, I’ll try to set it up nicely so that others can reuse it (or if anyone wants to chim in and build it, that’d be great as well!).
I’ll probably stub it out in the Holo-REA codebase over the next few days, but happy to pull git history of that folder out into its own repository at some point. Maybe we could do a comparison of various implementations and decide on an ideal solution?
All of the work going into this line of thinking is really great. I poked around social-triangulation and it’s remarkably clean and simple.
I am wondering, have others done any inter-zome calling recently, I have noticed a pattern of most people tending towards putting all code into one zome, since as I recall, there were some inconveniences/oddities to zome<>zome calls?
Yeah I figure that might be best, since it’s so simple and little that you may not get much benefit reusing the code.
My policy here in the code I’m developing up until now is to develop the standalone zome, to make sure it’s reusable by others without mixing any functionality that’s not needed in other cases. Right now I can’t give a lot of examples of cross zome calling except for MailBook, but this isn’t quite finished yet. Maybe @pospi can give a lot more examples.
I found also holochain_roles from the EYSS team, I want to have a think about stacking that functionality on top of some of the other primitives here too, which then bleeds into group agents…
I still haven’t seen anyone documenting how to share zome binaries between codebases in a proper publish workflow. For now I have to use a metarepo where all my dependencies are cloned alongside each other, so that I can link them using relative paths. @pauldaoust is this covered in any existing or new docs that I might have missed?
Also to note that I started on this in this Github repo but all I got time for today was stubbing out dependencies. Will pick it back up next week.
Currently there are two DNAs configured in the repo- one is public and (eventually) will simply register anybody who joins. The other imports @guillemcordoba’s “social triangulation” zome to create a permissioned registration membrane, but the build command only works if the other repository is cloned adjacent to this one. We need ways of packaging and referencing precompiled zome WASM bundles in .hcbuild files so they can be easily referenced between projects.
I’m not sure who the best point of contact for the Holochain core publish workflow is (@thedavidmeister?) but we also need to fix the crate versioning so that >= version constraints work and the maintenance burden of version change churn is lifted from app devs. I’m relatively certain that all that is needed is to change 0.0.44-alpha3 to 0.0.44-alpha.3 and the sorting will work as expected. Any chance we can try changing this in the first 0.0.45 release?
This seems to indicate a need for a common interface – could be as simple as a trait (zome trait, not Rust trait) that defines an is_valid_member function that takes an agent ID as an address. Then both the social triangulation zome and the preapproved members list zome could satisfy that trait.
I’m even thinking that membership could be seen as a certain type of role, and what we really want is a roles trait with a can_do function that takes an agent ID and a role. Then membership looks like can_do(alice, "join")… Although maybe that’s over-abstraction.
(@pospi note that the agent ID already gets published to the DHT on startup, and then the agent is considered ‘joined’ if it’s validated by peers. As for ‘registering’, though, that’d probably look like linking from a global anchor to the agent ID inside the init() function, then anyone who wants the full members list can just query the links on that anchor.)
@pospi I’ve asked the core dev team if there’s some hidden tooling for packaging precompiled zomes, cuz I know that you’ve been looking for this for a while. In the meantime, Git submodules feel like a good interim step.
I’m even thinking that membership could be seen as a certain type of role
@pauldaoust that is how the ValueFlows agent model works. We have run into lots of requirements for all kinds of roles, even just between “members” and a group. Including different kinds of membership in one group.
RE versioning, I think the main issue is that it forces app devs to maintain forks or updates in parallel- because when one zome’s crates depend on a slightly different version of the HDK (even 1 release) they are incompatible. Looking at tilde versions I wonder if anyone has had success with those?
I also suspect that people designing their own tooling around regexes might be as a result of the existing versioning format not operating as expected with Cargo natively.
RE zome interfaces, I agree! Those would probably be good abstractions. I’m not sure role-based access control fits into these low-level primitives, though. We may be conflating “network participation” (which is a technical thing) with “group membership” (which is a social thing).
As a result, I was planning on building role-based abstractions on top of the network membership API. Once there are some common interfaces to describe whether agents are members of networks, then we can add layers to describe whether they are members of groups within those networks. Maybe… at this stage it’s hard to say if those are necessary, or if sub-groups would just be more networks. We’ll see what happens when I add an extension to allow “group agent” DNAs to register with “agent registry” DNAs.
FWIW there is already a roles implementation out there, but it treats roles differently to how ValueFlows treats them and thus illustrates how this is a higher-order abstraction with some ideological choices within it.
Oh, and thanks on the agent registration stuff, I had been thinking that. You use %agent_id instead of an entry type name when you refer to those in entry defs, correct?
(Aside: why aren’t zome traits and Rust traits the same thing? Surely there is a way to use proc macros and the type system to iterate and describe native trait objects for exporting over RPC…?)
That could also work, and then you could shift to semver i.e. starting at 0.1.0 for the next release and then bumping minor/patch according to the presence of breaking API changes or not. For me that makes sense, I consider anything below 1.0.0 to be a beta. But possibly that also sends a mixed signal that the next version is a substantial update (could save switching to semver for the next substantial update?)
If we’re going to do it, seems sensible to change to standard semver so that it’s predictable and provides reliable expectation of breaking changes. The decision to bump minor versions vs -alphaX versions feels like it’s been fairly arbitrary so far, but maybe I’m just not encountering the breaking changes myself.
Just to mention that I also was thinking about this topic while a go then I implemented this sub-contract-prototype based on digital contract which requires counter-party signature entry. there is no UI you can just read and run the test
