holochain-open-dev / social-triangulation

A social triangulation zome for hApps with small communities with ties between its participants
9 stars 4 forks source link

Update option for num_vouches #2

Open pospi opened 4 years ago

pospi commented 4 years ago

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?

guillemcordoba commented 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?

pospi commented 4 years ago

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.

guillemcordoba commented 4 years ago

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.

pospi commented 4 years ago

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.

guillemcordoba commented 4 years ago

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...

pospi commented 4 years ago

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