specify social-encounter pallet

[brenzi]

https://forum.encointer.org/t/scaling-encointer-fast-and-globally-through-staked-social-vouches/95

How could we do this onchain simple? data model, rough sketch of dispatchables

Stakeholders

• reputables: people with a valid proof-of-personhood (recent proof of attendance at Encointer cycles of any community on Encointer mainnet). They are expectred to have an interest to spread the word and help Encointer grow, because this protects and strengthens their benefits within their local community
• endorsables: people who are local to an existing community but have no valid proof-of-personhood (not yet, or lost it due to inactivity or noshow). We also call them newbies but in this context, this is ambiguous. They have an interest to join their local community and reputables can help them join by endorsing them and securing their assignment for the next cycle
• encounters People encountered by one or many reputables (witnesses) who can testify on having encountered someone (receiver) virtually or physically and may even add a trust score of they know the person. Encounters are people that may not find an Encointer community nearby (or are not interested in the community currency) but still want to participate in the encointer ecosystem for various reasons:
  • to prepare for starting their own community currency
  • enjoy other Encointer products than community currency, like weak sybil resilience for CAPTCHAs, social media status badges or others
  • enjoy external benefits like DASH dividend, should they be offered by a third party.
• encounters of Nth degree encounters of encounters can be classified by their degree: How many hops they are away from a reputable. encounter of 1st degree is a direct contact to a reputable (see above)

TODO:

• encounter can be the person (social graph node) or the event of two person meeting (edge of graph) which is testified. Needs clarification and more specific vocab

Requirements

1. There may be no other requirement to become/receive an encounter than owning an Encointer Account (i.e. by installing the encointer-wallet mobile app and creating a keypair) and being witnessed by a reputable or other person with encounter status. No fee may be charged on the receiving side of an "encounter" testimonial
2. Encounters of 1st degree should have a value. Because of the requirement above, the value shouldn't be expected from the receiving side, so we need to expect it from the giving side.
3. people with no encounters nor reputation can witness encounters by locking KSM (disconnected social graphs are allowed)
4. Encounters of Nth degree should be as inclusive as possible, so we may want to avoid limitations of above requirement
5. (TBD?) Requirement (2) should not give financial incentive to testify encounters. If staking is required, there should be no return on staking nor demurrage relief (or should there be?)
6. (non-requirement?) we may want to support faucets which only require the status "encounter of Nth degree". This implies that no fees can be charged for dripping the faucet because encounter may have neither KSM nor community currency. As this provides very weak sybil-resilience, we may refrain from this requirement
7. the process to endorse someone should be treated as an encounter of 1st degree as well. But not vice-versa (it doesn't make sense to endorse a person from Hongkong for a community in Brisbane such that it could register for cycles, just because a reputable from Brisbane met someone from Hongkong at a virtual meeting online)

technicalities

1. the encounter registry is permanent
2. revocation by witness is possible but should persist in the registry. Lazy recursive revocation of witnesses of the revoked encounter possible by anyone, with fees returned if successful
3. the date of an encounter is registered, so the age of an encounter can be derived easily
4. encounters can be refreshed to reduce their age
5. encounters can be up-/downgraded with respect to a trust score (meeting someone physically after previous virtual encounter / change of trust in honesty)
6. the data model of the encounters registry allows to incrementally follow an encounter's trace back to all reputables involved by following the tree of witnesses. No requirement on termination as the graph can be cyclic
7. the data model includes the community cid of the reputation used for witnessing an encounter (it could be that this cid is consideren untrustworthy at a later time)

out of scope

1. we do not attempt to do graph analysis onchain due to computational complexity

[brenzi]

A fundamental question here is: do we really need to keep the encounter registry onchain or can we just let encounters collect proofs which are verifiable onchain on demand?
Maybe it is enough to register revocations onchain?

Zero Knowledge could possibly do that, but revocation as well as lazy garbage collection may not be possible that easy

Alternative: The privacy-preserving social-encointer-sidechain

• build the thing as specified above as a substrate pallet with its encounter registry
• deploy not on L1 but on L2.
• only staking would need to be on L1. therefore, staking/reserving should be another pallet and should be designed as a separate step
• combine with personhood-oracle (will need to do graph-analysis as well to derive badge attributes)

[pifragile]

people with no encounters nor reputation can witness encounters by locking KSM (disconnected social graphs are allowed)

can you clarify this @brenzi ?

[pifragile]

Encounters of 1st degree should have a value

what does that mean? a balance? @brenzi

[brenzi]

Encounters of 1st degree should have a value

what does that mean? a balance? @brenzi

sorry, I wanted to say "is valuable" in the sense of desirable

this task is on hold as we first want to experiment with using endorsements for this:
https://forum.encointer.org/t/endorsement-badges/105