FIO Groups

Owned by Luke Stokes
Last updated: May 07, 2021
8 min read

Introduction

Humans are a tribal species which inevitably congregate into groups of people with some minimal sense of shared identity, often based on geography or shared values and goals. As the world becomes more digital, online group membership will increasingly define someone’s reputation and network. As the value of these group relationships increase, the need to govern them and prove membership will also increase.

Private FIO Domains are a powerful way to cryptographically demonstrate group membership. Related to Re: FIO Identity | Comment and Verified FIO Address , an address on a private FIO Domain can only be obtained if the owner of the domain allows it. This raises some important questions:

  • Who owns the domain?

  • How does that ownership change over time?

  • How is it managed?

Tools for managing groups can be implemented as core system contracts on FIO, all connected to and defined by a multisignature ownership of a private FIO Domain. This could also be called a “DAC” (Decentralized Autonomous Community) or “DAO” (Decentralized Autonomous Organization).

For more information on why DACs are valuable see http://eosdac.io/why-launch/.

For some example DACs, see:

Who is the Customer?

Group owners and members of a group. Groups can be anything from a neighborhood, a city, a crypto trading group, a club, or any number of people with a shared goal or identifying characteristic.

What problem of the customer are we trying to solve?

On-chain cryptographic proof of membership in an exclusive group that has no single point of failure. Built in, on-chain governance for the members to elect group admins on a multisig to own a private FIO domain and enforce the verification process for membership in the group and on-going validation of active membership.

Why is it important this problem is solved?

There is currently no easy way for groups to identify their members with an on-chain mechanism that is blockchain-agnostic and provides value to the members (as FIO Addresses do). Private FIO Domains can do this well, but it creates other challenges around how that domain is managed, how ownership of that domain over time can change, and how the group members decide who will act as admins for the group. Without a mechanism to do this, the trust in the private FIO Domain and the exclusive value it creates for the group member identification is diminished.

Note: Please also see the additional benefits section at the end of this document. The Foundation Board has need of very similar features.

How will this product/initiative solve this problem?

By providing group tools for group members to elect admins who, via a set voting period, are added to the multisig control of the account which owns the private FIO Domain, groups can coordinate more effectively, clarify their membership criteria on an ongoing renewal basis, and remove single points of failure for the group. This model includes:

  • application for membership

  • member application for admin candidate

  • member voting for admin candidates

  • vote processing for admin election

  • multisig permission adjustment on the domain owner account

  • a nice interface to represent it all

What KPIs will you track to determine if you are solving this problem?

  • Number of groups using private FIO Domains to define group membership

  • Number of FIO group members within a FIO group

  • In addition (for FIO’s benefit):

    • Number of FIO Domains registered through this program

    • Number of FIO Addresses registered through this program

Examples:

Local Neighborhood

I live in El Valle en Los Prados and have the @elvallelosprados private FIO Domain. If we had a mechanism to verify residency (maybe in partnership with the HOA), we could assign a FIO Address to the residents at the neighborhood domain. This could be a real name like lukestokes@elvallelosprados or a pseudo anonymous name like skywalker@elvallelosprados or somethign random like 12345ABCDEF@elvallelosprados. Upon some agreed upon schedule (annual HOA dues?) residency could be verified. Membership to the DAO would be based on that validation process. “Active” FIO addresses on a private domain managed by a DAO would only be true if they had a current, active membership to the DAO. If someone moves out of the neighborhood, they would still own their self-sovereign NFT FIO Address, but it would be considered “inactive” and only demonstrate they once were a resident of the neighborhood.

Online Community

I’m a member of the QuakerDAO, a crypto group for UPENN alumnus. We could create a DAC for this group and assign their quakerdao domain to them. I could then have lukestokes@quakerdao to prove I’m a member of the group. I could register as a custodian candidate or vote for existing candidates who would then be elected to manage the account that owns the quakerdao via multisig. If there are any community projects or dues that are needed, the multisig DAO can manage those funds using FIO Requests. Having a FIO Ad @quakerdao

Gaming Guild

Many gaming communities have very strongly connected players who form guilds and have their own online meeting places, websites, membership dues, and more. Introducing them to crypto currency through the use of a FIO Group might be a successful business development strategy for FIO while providing a useful mechanism for them to keep track of their membership.

Additional Benefits

The Foundation for Interwallet Operability Board already has needs for a voting system as described here https://fioprotocol.atlassian.net/wiki/spaces/~268441363/pages/15368275 and here FIO Board . If we build this for everyone’s use and not just the Foundation, it can have far more value for the network. Though other solutions may be simpler in the near term for Foundation voting (offchain candidate registration, vote tally from sending funds to specific addresses created for each candidate, etc), they won’t create any additional potential value for the network. Due to the time constraints of the first election, there may not be time to build this FIO Group functionality for the first vote in April.

Front End

The front end interface could start out simply and follow a similar UI/UX design and onboarding path to what is already being designed for the Dashboard Old . If we decide to move forward with this idea, we can flesh out the front end more to better understand the complexities involved.

Technical Implementation

 

Tables

Groups (groups)

  • group_fio_public_key

    • FIO Public Key of the account which owns the domain.

    • Used for historical purposes once account becomes an msig.

  • domain

  • member_application_fee

    • in SUFs

  • date_created

Pending Members (pendingmembr)

  • member_name_requested

    • FIO address at domain

  • domain

  • account

  • bio

    • limited to 255 characters

  • application_date

Members (members)

  • member_name

  • domain

  • account

  • bio

    • limited to 255 characters

  • date_added

  • last_verified_date

    • Date the member was added to the group and then later updated each time membership is verified.

  • is_admin

    • set to true for groups creator or if elected as an admin of the group)

Admin Candidates (admincandids)

  • domain

  • candidate_account

Votes (votes)

  • domain

  • epoch

    • integer that increases with each election

  • voter_account

  • candidate_account

  • rank

    • use ranked choice voting

    • If a member votes for 5 candidates, they would rank each vote 1 through 5.

Vote Results (voteresults)

  • id

    • auto generated incrementing integer

  • domain

  • epoch

    • integer that increases with each election

  • candidate_account

  • rank

    • The resulting rank for this candidate after the vote is complete

  • votes

    • Total number of votes received by this candidate

Elections (elections)

  • domain

  • epoch

  • vote_time

  • number_of_admins

    • Integer for the number of admins that are being elected.

    • This will be the number of accounts on the msig that owns the domain.

  • vote_threshold

    • Integer for the number of admin votes need to approve any action requiring permissions of the group account.

  • votes_per_member

    • Number of votes each member gets for this election.

    • For example, if doing approval voting like EOS, you might allow for 30 votes to fill 21 spots. Or you could use the eosDAC model of 5 votes to elect 12 positions.

  • is_complete

    • Marks if this election is completed.

    • Note: this field may not be needed if we just want to use “date_certified is not null” to accomplish the same thing.

  • date_certified

    • The date this election was marked as complete.

Actions

Create Group (creategroup)

  • Parameters:

    • fio_public_key

    • domain

    • member_application_fee

  • Results and Notes:

    • Registers the domain (if available) to the public key provided.

    • If an account already exists for the public key, throw an error, otherwise adjust owner and active permissions on the newly created account to be that of the calling actor.

    • Adds one and only one record per domain to the groups table.

    • Adds a record to the members table using the actor and sets is_admin to 1.

Delete Group (deletegroup)

  • Parameters:

    • domain

  • Results and Notes:

    • Can only be called by the account which owns the domain.

    • Removes all domain related records from all group tables.

Apply for Membership (memberapply)

  • Parameters:

    • domain

    • requested_member_address

      • FIO address the member would like to register at the group domain

    • bio

      • Optional

      • Limit to 255 charachters

    • <FIO token payment>

      • This action will require a payment of FIO in the amount of the member_application_fee defined in the groups table record for this domain)

    • <actor = account>

      • Use the actor calling this method as the account value for the pendingmembr table.

  • Results and Notes:

    • domain must exist in groups table.

    • Call includes payment in FIO tokens which is used to create the FIO address.

    • Adds one and only one record per domain / account pair to the pending members table.

Approve Member Application (approvemembr)

  • Parameters:

    • domain

    • account

  • Results and Notes:

    • Only callable by the group owner.

    • Uses data from pending members table to add an entry to the members table (is_admin false).

    • Registers FIO address for member and assigns to them.

    • Last verified is set to now.

    • Removes entry from pended members table.

Reject Member Application (rejectmemapp)

  • Parameters:

    • domain

    • account

  • Results and Notes:

    • Only callable by the group owner or the actor for account.

    • Removes entry from pending members table

Update Member Bio (updatemembio)

  • Parameters:

    • domain

    • account

    • bio

      • 255 character limit

      • Can be set to an empty string to clear out the bio

  • Results and Notes:

    • Only callable by actor of account unless called by group owner, in which case bio is cleared.

Remove Member (removemembr)

  • Parameters:

    • domain

    • account

  • Results and Notes:

    • Only callable by group owner or actor of account.

    • Throw error if is_admin is true.

      • We may want to change this to allow an admin to leave the group entirely, but it might introduce other complexities.

Verify Member (verifymember)

  • Parameters:

    • domain

    • account

  • Results and Notes:

    • Only callable by group owner.

    • Update last_verified_date for this member.

Register as Candidate (regcandidate)

  • Parameters:

    • domain

    • candidate_account

  • Results and Notes:

    • must already be in the members table for this domain

    • adds one and only one record per domain / account pair to the admin candidate table.

Remove Candidate Registration (remcandreg)

  • Parameters:

    • domain

    • candidate_account

  • Results and Notes:

    • Callable by group owner or actor of candidate_account

    • Remove record from admincandids

Create Election (createlectin)

  • Parameters:

    • domain

    • number_of_admins

      • Example, for a 3 of 5 multisig, enter 5.

    • vote_threshold

      • Example: for a 3 of 5 multisig, enter 3.

    • votes_per_member

      • During the election, how many candidates can a member vote for?

  • Results and Notes:

    • Adds record to elections table.

    • Can only be called by an admin (member with is_admin set to true)

    • epoch is a sequential number, obtained by adding 1 to previously highest epoch for this domain or defaulting to 1.

Vote (vote)

  • Parameters:

    • domain

    • candidate_account

    • rank

      • use ranked choice voting

  • Results and Notes:

    • Adds a record to the votes table.

    • Use actor for voter_account.

    • Must exist in members table for domain.

    • epoch obtained by querying elections table for domain, obtaining greatest epoch and adding 1.

Record Vote Result (recrdvterslt)

  • Parameters:

    • domain

    • candidate_account

    • rank

      • The resulting rank for this election for this candidate based on the number of votes they got

    • votes

      • the sum total of all votes for this candidate for this election epoch

  • Results and Notes:

    • Can only be called by group owner account.

    • epoch is derived from most recent election where time of vote < now.

    • Can only be called for an election where is_complete is false

      • or should we just use date certified is null

    • Adds a record to the voteresults table.

Remove Vote Result (remvtresult)

  • Parameters:

    • id

      • may change based on design

  • Results and Notes:

    • Only callable by group owner account.

    • Only valid for an election result that isn’t complete or for election results that are older than some threshold (2 years?).

    • Used to fix errors and remove stale data.

Certify Election (certelection)

  • Parameters:

    • domain

  • Results and Notes:

    • Gets a completed active election (time of vote < now, latest epoch)

    • Verifies number of custodians voted on was met

    • Sets date certified to now.

    • Sets all is_admin to false.

    • Sets top ranked by vote candidates is_admin as true in members table.

    • Creates msig for the group owner account to sign with permission change for the account based on the election.

    • Remove records in admin candidates table.