Acceptable management of family member’s PoH account

Proof of Humanity
1

Hi all,

Following the community discussion on “Acceptable management of family member’s PoH account”, which aims for the registry to remain inclusive on all ages, some afterthoughts led to thinking that perhaps it’s simpler and better to not allow small children and make it explicit in the registration rules.

To briefly summarise the discussion in the community call, family members can be separated in three categories: adult, small children and old persons/parents.

  • An adult can only manage up to 2 small children and 2 old person accounts (voting on behalf of not allowed).
  • Adolescents will be treated the same as an adult account in being fully responsible for his/her PoH account but are not allowed to handle a small child or old person’s account.

Assuming each adult having equal ‘managed’ profiles where for every 5 accounts there’s only one unique human behind, then it undeniably compromises the integrity of PoH and becomes less desirable for integrations. Even at the minimum of one-adult-one-child which translates to 50% of the human identities being duplicates (with regard to wallet ownership) of the other 50%.

Now of course PoH relies on social validation through vouching which implicitly relates one human identity to another as either family, friends, acquaintances, and so on.
Naturally, a human registering will share PoH and vouch for close ties first and the simplicity in registration makes it easy for someone to do it on behalf of others. As of the prevailing process, we can only assume good faith in all submitters unless proven otherwise by community curators.

Moreover, the inclusivity nature of UBI and minimum requirements in the policy for eligible submissions, the community consequently allowed small children to be registered despite the risk of it acting as a duplicate account of the parent/guardian.

Loose enforcement of unique human behind each PoH identity led to permitting (unofficially) a person to handle more family members’ accounts until controversial disputes (Kleros · Court Kleros · Court) arose exposing the extent of the unofficial permission’s reach. Prior to that we had a case of profile farming in children (Proof of Humanity, a sybil-proof list of humans. Proof of Humanity, a sybil-proof list of humans.) which can possibly reoccur from another school or village unless specified in the rules as forbidden.

Nevertheless, the topic is very relevant and a fairly common query on community chats.

Screenshot_3
Screenshot_1
Screenshot_4

Either we move forward with the intention of creating an HIP out of it or create an HIP towards a different direction - restricting PoH to adults.

3 Likes
2

The post doesn’t forbid anyone to help onboard family and friends - that’s unlikely.

We must, however, let them be in control of the wallet keys and just offer help in using it - not taking over ownership. Hence, won’t be applicable for children in the registry.

3 Likes
3

Hi @NingFid! Because of my poor english, I don’t get if the purpose of this post is to describe a closed definition or a kickstart for discussion. Can you explain to me? Thanks

4

Hi @herniadlf yes no worries. It’s a kickstart for discussion on whether we should continue doing HIP about managing family members’ accounts - the goal of the previous community call - or lean towards actively educating family members on wallet management instead (after considering possible unfavorable repercussions to the dapp’s use case) and maybe enforce stricter guidelines for children’s registration that will reflect on the registration policy.

But @clesaege sees other possible use for managed accounts like that of children
image
so we might not need to forbid small children’s inclusion in PoH for now.

1 Like
5

A thought, could we allow a “UBI profile” for dependents, but not a “PoH profile”?

So idea is that we tighten up the requirement for a full “PoH profile” (no audio aids, no prompts behind the camera).
Then we may allow a “UBI profile” with a lower requirement and a PoH profile must claim it as a dependant.
This may avoid introducing loopholes in PoH security while still allowing UBI to go to those in need.

1 Like
6

My first thought is that we shouldn’t stop any humans from registering (nor children not old people). Otherwise we should rename ourselves to Proof Of Adulthood. I think @clesaege idea, coupled with @Mads, makes more sense. I’m not sure if it’s best for each PoH use case to have a specification of what type of registry it requires, otherwise we’d end up building something very specific to each need.

Therefore, my idea is to build something like PoH Levels (similar to KYC levels). Just as some sites have different levels of KYC depending on some challenges, PoH could have something similar. Then, each integrator or use case defines which of them corresponds to use:

  • High level → Strict registration (do not allow any failure in the submission).
  • Medium → Semi-strict registration (more permissive policy. Yes, that could open the door to sybils but It may be admissible in some projects that seek greater inclusion ie UBI)
  • Low → Permissive registration (can’t find current use case :stuck_out_tongue: )

None of these levels stop being sybil resistant, otherwise we would go against POH. The idea is that the cost of being flexible is paid by the integrator, and not by the reputation of the registry.

This idea is totally inapplicable with existing contracts (I don’t know if we are on time in POH v2).

Therefore, I think that for now we can only adjust the policy. My proposal is to make explicit that it is not allowed to register other people nor control their accounts for personal benefit in any project that is linked to POH (ie UBI). Then, I would mention that in exceptional cases you can help with the registration, but that any subsequent action linked between accounts is a reason for removal (example, I vouch and help someone to register, and then we detect dao votes in the same minute, or we see transfer of funds to the voucher)

7

Not really.
PoH Levels could be an app built around poh, where one actilvely declares management of other accounts, that are within ta legal framework.
With this, the POH policy could be updated saying that a profile that manages other accounts is challengeable as long as they have not declared themselves as account managers on PoH Levels, or if evidence that the decllaration is false and is actually farming.

of course, a new Policy around PoH levels should be defined in order to agree uopon what makes it a valid use of management and what makes it invalid/illegal.
I like the idea!

1 Like
8

Agreed. An explicit rule against those is a better direction. Not an absolute solution to sybils but can discourage attempts if submitters are made aware of penalization of such action. Maybe a mix in here [Phase 1] HIP-55: Explicit Sybil Resistance

But with regard to transfers, that’s a harder one to mandate because among family or friends, transferring funds or tokens to swap is a practical method to reduce txn costs.
If it helps, take for example these cases below
https://court.kleros.io/cases/1233
https://court.kleros.io/cases/1235
https://court.kleros.io/cases/1236
https://court.kleros.io/cases/1237

1 Like
9

Oh yes, the Aconcagua challenges… You’re right, maybe that transfer constraint is not the best. I will share this thoughts in HIP55 :+1:

10

I’d like to continue this idea here. Besides it needs a HIP itself, I’ve been talking with juanu and I’d like to read what the community thinks about it. @juanu correct me if there is something wrong:

  • Build a contract that stores “management declarations” like: 0x1 manages [0x2, 0x3, …] accounts and such. This could have a limit (max of 10 managed accounts, for example). This ‘declaration’ requires an extra on-chain tx.
  • Include management in the policy, allowing 0x2 to say something like “my account will be managed by 0x1”. The challengers could check in the management contract if it’s true, or else challenge the submission as duplicates/sybil (like @green proposal). Also, Juanu suggest that it could be “declared” after the submission to avoid Removal Request of declared managements.
  • This seeks transparency. People will continue managing family accounts, but integrators could use this new contract to check if it’s a managed human account or not. Also, a more strict policy with non-declared managements can lead to challenges as sybil/duplicates and keep the security of the registry.
  • We can also use this contract for others segmentations of human accounts, as I mentioned with PoH Levels. I just need to think more about it.
1 Like
11

I like where this is going. A declaration could be a good middle ground for declared sybil accounts (managed).
Protocols that require proof of personhood can opt to check on this registry and only allow accounts not managed.

Any account found to be managed that is not declared, would be challengeable

1 Like