MetaGame App Implementation

I wanted to create a separate thread for discussing the implemetation side of the upcoming MetaGame App. Currently, we have a dummy web template that’s connected with 3Box and a backend by @METADREAMER and @pacobacpac. But in order to work towards the app we want, we need to design what we want. And I see the app’s frontend in two different separate phases,

  • Before signing in.
  • After signing in.

So here comes the questions,

Before signing in phase

  • What do we need to have before a player signs in? Like, other metagame player profiles or anything that doesn’t need a player to be signed in.
  • What can be done in this phase by a player? Like, is he gonna have some dynamic interaction? or are we gonna just display something for the player to see?

After signing in phase

Currently, we have integrated 3Box for signing in a player. But this is subjective to changes.

  • What do we need the player to do after he is signed in or what do we wanna render?
  • What actions can a player do within his profile?

And those were some of the questions I had in my mind. Feel free to ask your own questions too. A solid foundation is needed to build on top of it.

@Polycarp And I are going to be meeting on Tuesday at 11:30 AM PST to scope some of this stuff out. Lemme know if you wanna join I will add you to the cal invite!

Great! But am not sure if I can make it. Maybe post a brief summary of anything important discussed in the call later for everyone to check :slight_smile:

Will take notes and record the session :slight_smile:

1 Like

Metagame Profiles App

Notes on 13/05/2020 meeting

So I think the conclusion for the meeting is that we went too fast defining the data models, and we need to step back a little bit, start with less things, and adding more features over time when we know exactly what we want.

On frontend

We need to redefine what data will be displayed on the frontend and then have a call with Saimano and the designer friend of Peth to align the specs.
Then, start creating design on figma, eventually re-iterate.
Once this is done, we can start lay down the base of our UI component system, implement the interface with mock data and finally integrate with the exiting app with real data.

On data architecture

Our main concern is: where should live our data. We have our own database, we have profile information from 3box, XP and quests from sourcecred, membership from DAOs…
At the begining we planned to store all of that in our database, but that poses problem of data synchonization/replication and adds a “trustful” layer, not necessarly required.
By keeping the data where it is now (blockchain/IPFS/github), it ensures it is always up-to-date, and “trustable”, but makes us lack some powerful features such as searching, filtering etc that we are used to with “real” databases.

First iteration proposition

I will describe here what I propose as a first iteration we could deploy

On quests

Quest are things that people can achieve. For now, it is the “initiatives” stored as json in sourcecred repository. So we can leave this out of our DB right now.
Eventually add a lambda function or remote schema that returns extracted data from github (via graphql mesh)

On guilds

We don’t have now exactly a definition of what is a Guild. Some ideas out of the wild are: a DAO, a project on Everest, or something that we can just create/manage on the app.

The main problem here is that there must be a way of how the guild member are managed. For a DAO, that’s straightforward with token holders. For not DAOs, there must be some kind of permission system with roles, defining who can add member to a guild or not, for the least.

We leave also this out of the DB for now. Eventually use a remote schema that return membership information from Moloch DAOs from TheGraph.

On accounts

“Accounts” refers to user’s account out of metagame, such as github, discord etc…
As it will be mandatory for our users to login with a web3 wallet, they will all have an ethereum address so I suggest we put it in the “Player” model instead of inside an other table, and leave all the other profiles on the “Account” table, for convenience purposes.

On XP

I think that’s important to keep at least the totalXP and rank in our database, and have a CRON job that regularly update them from sourcecred. Eventually a function/remote schema that fetches the history from github to display the graph.

On profile

For general purpose profile informations (name, description…), I think it is better to leave this in 3Box, and let the user go to edit their profile on the 3Box official app, so that data is universal to all apps.

For metagame custom info (why do you like metagame, what’s your meme and other metaphysicial stuff), we can either store it in a specific 3box space, or in our database. Storing in our database have great advantages in term of performance, and also allows to makes people be able to “look for all the growth hackers in Lisbon” for instance.

On sourcecred identities

So we have identities in our DB, and identities in profiles.json in sourcecred’s github.
I believe one source of truth would be better. Having to make pull request to add players or update accounts in sourcecred is not really convenient.
So I think using our DB with Profile{id, ethAddress} => Accounts{ type, identifer} would be better.
I suggest that, when sourcecred CRON task starts, it fetches all this data from our DB and write it in the profiles.json, then calculate the scores.
We could keep a copy of the profiles we have now and once all the users have created an account on metagame app, we just put back the accounts they had (discourse, discord…)

2 Likes