Community

This page aims to clarify the community flow.

Overview

The DistributedTown communities are assigned to a Vault with 96 000 DiTo credits. Each community can have between 3 and 24 members in order to be active. Before the 3rd member enters the community, the community is considered inactive. The members can't create gigs or projects. Each community member receives between 2006 and 2720 DiTo credits, depending on their skills and skill levels. These credits can be used inside the community only after the user has their skills validated. This happens by completing 5 gigs for each of their skills.

Technical overview

The DistributedTown's communities are implemented from multiple components - smart contracts and backend server (nodeJS), off-chain storage - ThreadDB, community intercommunication - Textile's MailboxAPI.

Off-chain data

Every community has its own thread in the threadDB, which ensures the privacy of the community data. The gigs and projects collections live inside the community thread, which is protected via a public-private key pair.

On-chain data

Community.sol

Every community has 96 000 DiTo credits in total, which can be transferred from and to members of the community thanks to the whitelist. When a user joins a certain community, they get whitelisted and therefore allowed to transfer credits. When a user leaves the community, the tokens of that user get transferred to the community vault and the user gets removed from the whitelist. This way we ensure that there will be no community with more or less than 96 000 DiTo credits.

CommunityRegistry.sol

Factory and Registry of Communities

The community registry is responsible for creating a new community on-chain and creating an address for it.

GigRegistry.sol

Factory and Registry of Gigs

The gig registry is responsible for creating and completing gigs on-chain. When a gig is created it gets stored both off-chain and on-chain. The gig details - title, description, skills required, gig unique hash, etc are stored in the GigsCollection of the community thread. We generate a unique hash for the gig, which we use for verifying that there has been no data manipulation off-chain. This hash is also stored on-chain. After every meaningful part of the flow of the gigs, we check if the off-chain and on-chain hashes match. We do that using an Oracle - Chainlink. For more information about the gig flow, please refer to the gig management flow: https://app.gitbook.com/@distributedtown/s/distributed-town/~/drafts/-MUChXKMPzWPPzH1Hj4X/developers/wip-gig-management.

DiToToken.sol

Implementation of the SkillWallet token for the DistributedTown project. It's an ERC20 token.

Scarcity Score

When the 3rd community member joins, the community automatically gets activated and fully functional and its scarcity score gets calculated.

A scarcity score is a value that aims to evaluate how self-sustainable a community is. The bigger variety of skills, the higher the scarcity score is. If the scarcity score of a community falls under 48, the community is considered inefficient and it requires new members.

Calculation

The scarcity score of a community is calculated as follows:

scarcityScore=VC100scarcityScore = VC * 100

where VC (variety coefficient) is:

uniqueSkills: the number of unique skills inside the community. Each community category has 12 skills. UniqueSkills value can be between 1 and 12.

totalSkills: All skills in the community, including duplications. There are between 3 and 24 community members, and each member has between 1 and 3 skills. Therefore totalSkills is an integer between 3 (3 members, 1 skill each) and 72 (24 members, 3 skills each).

filledSlots: The community members count. Between 3 and 24.

The minimum possible value of the scarcity score is when there are 3 members with a single duplicating skill.

VC=1/33/6=1/6=0.166VC = 1/3 * 3/6 = 1/6 = 0.166

SS=16.6SS = 16.6

The maximum possible value of the scarcity score is when there are 24 members, 1 skill each, all different

VC=12/2424/6=2VC = 12/24 * 24/6 = 2

SS=200SS = 200

Therefore the scarcity score can be a value between 16.6 and 200.

Signal

If a community hits a minimum scarcity score of 48, the community is no longer self-sustainable. In this case, the platform automatically sends a cross-community signal to the closest by skillset communities.

How it works?

The signals are implemented via the MailboxAPI by Textile. In terms of DistributedTown, every community has a "user identity" in the textile world. All of those identities have their own pub-private key pair. The Hub user APIs provide tools for sending and receiving messages between Hub users. User Mailboxes provide an encrypted endpoint where encrypted messages can be left for users while they're offline. User mailboxes are designed to be used with private key based identities where each user will privately encrypt messages for recipients based on the recipient's public key.

When a community is created, the backend generates an identity, a thread for this identity, and a mailbox.

When the scarcity score drops below 48 points the system automatically publishes a message in the mailbox of the "closest" communities. All users of this community can see these messages in the notifications section and decide whether to switch to a new community by one-click action or not.

Flow

When a community receives a signal it propagates this message to all the members inside the community as a notification. The message is simply an invitation to join the community in need. If the user clicks on the invitation, the user automatically leaves their current community and joins the one in need.

Update triggers

The scarcity score gets recalculated in the following cases:

  1. User's skill gets adjusted after validation

  2. A user hits 3840 DiTos

  3. Quadratic distribution

  4. A new user joins the community

  5. The user modifies their skills

Community creation

IPO

Aleeex :)

The flow of community creation

The community creation depends on both off-chain and on-chain requests, which can be best showcased by a diagram.

Currently, all of those requests are done in the FE. What we should do moving forward is to implement the entire flow with an Oracle, such as Chainlink.