Has anyone implemented this already? Seems like a simple foundational building block, actually (eg. you could build group agents on top of this).
I propose:
app.json, to allow for private groups@guillemcordoba these could potentially be components to build on top of https://github.com/holochain-open-dev/social-triangulation?
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.
@pospi i donāt really care how the versioning is setup, actually itās already non-standard and most of the crates just have a simple 0.0.X system
the thing is that changing it breaks lots of things in lots of places as people design their own tooling around regexes etc.
personally iām happy to make the change but it would need to be organised carefully
ping @zippy
@thedavidmeister is it also true that the version pinning for serde has been relaxed for the upcoming v0.0.45?
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ā¦?)
sure, i mean i care if itās causing people problems 
@pospi would it help to just drop the -alphaY suffix completely?
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