Open pospi opened 4 years ago
Hum this is a big change, since it can automatically render a lot of agents that have already been validated in the network invalid... I don't see a clear way to do this, other than cloning the happ and creating a new one with a new num_vouches
value.
Do you see a way to change that value without changing the validate_agent
execution?
Yeah actually I am thinking about some potential polymorphism in managing updates to the value- you probably want it to be pluggable, since the needs of each group would differ.
We could code it so that this module just looks for an anchor to read a value from the DHT, and if it finds one then it will use the stored value instead of the seed value in the zome config. Then we could make companion zomes which include different logic for managing updates to that value.
Hum okey, it's still unclear to me how updating the value is going to work in any case, because of how agent validation works...
And about covering different needs, isn't having the value as a configurable property in the DNA the right way to go? You will always be able to clone the DNA with a different property and this will change the behavior of the zome without modifying the code.
because of how agent validation works
Not sure I see that. validate_agent
only runs when joining the network, right? So if someone has already been validated and joined, they wouldn't be made invalid by changes to the value. It would apply to people pending validation, sure, but to me that feels like expected behaviour- if the number of vouches increases and you haven't joined yet, you now need more vouches to join.
The problem with a configurable property is that it's not dynamic, if I understand correctly. I am thinking that the repercussions of cloning the DNA into a new one would be fairly far-reaching, and perhaps require updates in related zomes to deal with it. Any other zomes in the same DNA would have to be cloned and migrated as well, wouldn't they? And foreign DNAs would probably be verifying the hash of the social triangulation zome to ensure users don't swap it out for different authentication in order to get around the auth.
Actually validate_agent
runs every time that an agent tries to establish connection with a new node. Imagine network partitions - when the partitions join, nodes from one partition will run validate_agent
all over the place. And actually when one node drops and some nodes need to discover new neighbors, they also run it. So we need to treat validate_agent
like an actual validation rule - deterministic and cannot ever change or result.
I agree that cloning adds some friction, but right now I don't see any other way with the tools holochain provides...
Are you sure about "cannot ever change"? I would have thought of that as a non-critical issue- if it returns false and an agent is rejected from a connection, couldn't they just resolve any dependent data that their participation may have been dependent upon and then retry joining the network? Or are the repercussions of failing validation more serious than that? (ie. issuing of warrants)
On Mon, 23 Mar 2020 at 22:15, Guillem Córdoba notifications@github.com wrote:
Actually validate_agent runs every time that an agent tries to establish connection with a new node. Imagine network partitions - when the partitions join, nodes from one partition will run validate_agent all over the place. And actually when one node drops and some nodes need to discover new neighbors, they also run it. So we need to treat validate_agent like an actual validation rule - deterministic and cannot ever change or result.
I agree that cloning adds some friction, but right now I don't see any other way with the tools holochain provides...
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/holochain-open-dev/social-triangulation/issues/2#issuecomment-602555134, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADK2JHTCS3W35D3J27DBXTRI5HF7ANCNFSM4LGF64QQ .
-- writings http://pospi.spadgos.com/ | twitter https://twitter.com/pospigos | github https://github.com/pospi ← where to find me ValueFlows https://www.valueflo.ws/ | Holo-REA https://github.com/holo-rea/ ← things I'm working on
As a network grows, it's likely that members will want to update this number. We should allow it to be updated if
num_vouches
agents change it to a new value?