Pomelo Season 3

Published in

Cambiatus

6 min readJan 12, 2023

Following our first participation on Pomelo on July 2022, https://pomelo.io/grants/cambiatus. We like to provide some feedback about our progress so far.

We applied for Pomelo for building this feature, but it was something we were already working on. We were delighted to see that initiative and finally felt that the EOSIO/Antelope ecosystem could help us grow. In fact, some of the strategies used by Pomelo related to avoiding Sybil attacks could be complementary to our Roles and Permissions feature.

Motivation

🎯 This feature was envisioned a long time ago, our first mention of it publicly can be seen on our Github was 24th November 2021, when we started implementing it.

https://github.com/orgs/cambiatus/discussions/669

A lot of our communities had problems with bad actors creating multiple accounts to harvest invitation rewards, inactive users with not products that didn’t exist on the shop and spamming of claims, sometimes violating the terms of a claim.

We initially thought about banning those users and having regular restrictive punishments, but what if we did the other way around?

📖 What if our app could open up to users as they engage with their community?

Roles was the first step into making this happening. By awarding roles more possibilities open to those engaged users. This also means that accounts would need to build a reputation or a history inside the community to be able to do any damage. Reward users for good behavior instead of punishing them with bans or blocks.

It would also allow to create segment of users within a community.

This is only natural when you think about it, on communities not everyone engages or participate in the same way. For example, one of our communities, Play4Change, some users focus on education, others on playing games, others on internal and organizational process. For each of those groups there are different paths, actions and contexts that they can participate and grow within.

Our plan go both ways:

- In one side we can provide technologies for users to add context to their journey and participation within a community.

- On another side we will be able to experiment with different communities how to grow and foster autonomous organizations, with different roles.

Pomelo was the first investment we got from the community to build those basic building blocks. Before our next application on ENF we deployed and validated those simple entities into a production environment. Now we plan to give it to the users in UI and automation tools.

Research phase

We did a lot of meetings and conversation groups to reach our idealized version about how roles should work. We used collaborative tools like Miro to build boards exploring the possibilities.

Exploratory user journey

Following the idea of the community opening up as the user interacted, we experimented with our members how would we use this feature, creating roles for each area of our organization and assigning permissions when needed. This helped us to envision how one could grow in their respective area and who was able to validate that journey

https://miro.com/app/board/o9J_lpG97AM=/?share_link_id=545002704879

Click the image to enlarge, here you can see how “Hide the Pain Harold” would earn roles from their participation

Mental map of screens

After experimenting with the idea we began the work to actually start designing how our users could interact with roles. It was a complete sight: from admin only actions, to user interactions, we turned out with a very big map connecting screens, actions and some references that will be used for implementation later:

https://miro.com/app/board/uXjVOBYRrXc=/?share_link_id=400351670631

It is important to inform that this mental map was built during several meetings with a multidisciplinary group of people who are part of the Cambiatus team.

Click to enlarge. First versions usually are very simplistic just to give us an idea of the form. Later they start to look prettier

Building screens

After all the exploration, dynamics, mind maps and outlining, we finally are ready to start designing screens. Here we work using Figma to build screens. During this phase we do a lot of back and forth polishing details, validating screens and experimenting with models. We also use wireframes as a step before we get to the visual detail that the UI, where we will add illustrations, texts, colors and shapes. Before that, we defined some structures and behaviors that we expect to happen during user interaction. Having this help us have a clear view of what we are going to build during our ENF Grant.

https://www.figma.com/file/IYaSqUD58quAZMIhqdi7WA/Roles-%26-Permissions?node-id=551%3A5279&t=tGe1WSApR3AHgbLA-1

Working on Code

As a lot of features, it starts with the smart contract and propagate changes on all systems, like our backend and frontend.

Our work started with an issue and two PRs on contracts:

Then we propagate the changes to make sure its compatible with the rest of the system:

— -

Those changes mainly allowed us to create new entities to be used on the contract and the rest of the system:

TABLE member 
{
  eosio::name name;
  eosio::name inviter;
  std::string user_type;
  std::vector<eosio::name> roles;

  std::uint64_t primary_key() const { return name.value; }
  
  EOSLIB_SERIALIZE(member,(name)(inviter)(user_type)(roles));
};

TABLE role
{
  eosio::name name;
  std::vector<std::string> permissions;
  std::uint64_t primary_key() const { return name.value; }

  EOSLIB_SERIALIZE(role, (name)(permissions));
};

Those entities interact with a bunch of other ACTIONs on the contract, mainly using convenience methods like:

// Convinience methods
bool is_member(eosio::symbol community_id, eosio::name user);
bool has_permission(eosio::symbol community_id, eosio::name user, permission e_permission);
std::string permission_to_string(permission e_permission);

Going further

This is only the tip of the iceberg. Having those entities is only part of the story. It allows us to attach metadata to our users’ membership in a community, and validate if they have the necessary permissions to do certain things. But this only makes sense if we have an actual screen to interact with it.

This is a very important step for us. Most of our users are not experts using phones, wallets and other digital devices. In some blockchain apps, UX is bad and that’s no problem, since the most important part is the functional and safe smart contract. Its even common that an interface is actually optional to interact with the contract; in EOSIO/Antelope, some wallets like SimplEOS even provide an interface for you to interact directly with the contract. Since our user base is so different from the regular EOSIO/Antelope user, its important to build easy and accessible interfaces, and that’s the reason why we put so much effort into parts that require no code.

Finally that’s when the ENF application enter! With those resources we are able to implement everything we’ve been preparing for this feature, with a polished and carefully crafted interface for our users.

ENF Grant

With this put and published to our production env, we are now able to start working on user facing changes, that have been included as next steps into our into our ENF Grant Application:

https://github.com/eosnetworkfoundation/grant-framework/pull/110

On this final phase is where we will be able to do most of the changes, like screens for creating, updating and assigning roles, public exploration of the paths to earn roles and a more granular permissions inside the system.

This will include backend work to provide quick, open and accessible APIs using GraphQL, an exception free frontend (thanks Elm!) for our users to interact with and all the background processing work necessary, including automation and blockchain synchronization with our servers.