Preliminary Technical Research

Making sure the concept can be delivered. Re-considering solutions that affect Season 2 scope.

BanklessDAO Mobile App v1.0 Functionality

User experiences and the technology behind them.

Discord connection

 

• The app would use the DiscordAPI allowing the user to authorize access to their profile and activity information.
Discord OAuth docs: https://discord.com/developers/docs/topics/oauth2.
 

$BANK balance and recent transactions

 

• For the purposes of security, it's recommended to hold from implementing Web3 wallet connection in the app for Season 2 scope. It's technically possible to do, and R&D in that direction will be going on in the #mobile-platform project, but at this stage there are many security and complexity considerations on mobile platforms.

• The proposed Season 2 implementation is to:
1. Allow users provide their public wallet address and pull their on-chain $BANK balance using a public Ethereum gateway, such as Infura.
• Infura service: https://infura.io.
2. Integrate the app with Collab.Land service used in the Discord to tip contributors. The service has an API that accepts user's Discord API auth token, which works nicely in our case.
• Collab.Land API docs for Balance and Transaction History:
https://docs.collab.land/api/#operation/AccountController.getBalances
https://docs.collab.land/api/#operation/NearIndexerController.getTransactionHistoryForAccount
 

POAP tokens

 

• POAP tokens for a given public address can be accessed using POAP or Ethereum network's public gateways.
There is a subgraph running for POAP: https://thegraph.com/legacy-explorer/subgraph/amxx/poap.
POAP's FAQ states that they welcome custom development and are open to any discussions.

 

DAO Achievement tokens

 

• It would be productive and beneficial for the future features to implement these as POAPs.
A quest completion would trigger a dynamic POAP creation that's unique for the user and the quest, which can then be collected.

• Alternatively, these can be stored in a traditional cloud storage, which is of course less preferred.

• In any case, this shouldn't be a great challenge.

 

Streak rewards

 

• This would require storing non-personal information about the user engagement.
One part of this can be the analytics service integration that they app will have anyway.
Another part would likely be the mobile platform web service that tracks the streaks and issues rewards correspondingly.

• To issue the rewards, the platform web service would work with Collab.Land and/or POAP network APIs.
Collab.Land transfer API: https://docs.collab.land/api/#operation/AccountController.transferTo.
 

Everything DAO in one timeline

 

• The data will come from aggregation of the individual data sources that the DAO or LLC stores its various content in, including but not limited to:
Bankless Newsletter;
BanklessDAO Weekly Rollups;
Twitter and Other Social Media;
Bankless Academy;
Bounty Board;
[ Quests fall under interactive content, see below in the document ];

• It is proposed to invest in the first implementation of the DAO content aggregation web service, which would include the following execution items:
Work with all the potential content provider projects - such as Bankless Academy, Bounty Board, Newsletter and Weekly Rollups - to pull their content using an API.
Create a web service to integrate and request the APIs mentioned above, aggregate the content items and store them together.
Create a BanklessDAO Content API that returns the aggregated content items mentioned above, for the mobile app to rely on.

• The pilot integration of all the content providers will focus on delivering the proof-of-concept in the form of the mobile product, and leave most of the scalability concerns for a future season. However, the desired scalable architecture has been designed and will be kept in mind during the Season 2 implementation.

• For the sake of simplicity and reducing risks in Season 2, it is proposed to limit the user experience of viewing the content items to simply navigating to their existing web presentations (frontends) by default.
Creating mobile presentations for the different content types will be a bonus objective in the season, and is totally possible to achieve. But we have to mark some things optional to manage expectations.
 

Interactive Content

 

• Delivering this kind of experience requires the following components in place:
A schema design describing the data structure of a typical multi-step interaction.
For example: One quest containing four steps; each step has a title, a description, a set of media links, an action link, and a certain score.
A data storage to host the interactive content with API access.
A way to track the state/progress of each interactive content piece for every community member.
A functionality to trigger a reward upon completion of a particular interactive content piece.

• In the spirit of multiplying value of the existing DAO projects without interfering in their development process too much, the proposed Season 2 solution is to:
Create a dedicated web-service implementing the functionality described above;
Create a front-end for manual entry where authorized DAO members can create simple interactive scenarios such as First Quest (on the picture above), and assign rewards triggered upon their completion;
It can be a Discord bot which fits nicely into the current DAO practices.
Leave an option to integrate any data source for automatic interactive content piece creation.
For example, the First Quest project implements their own website and/or Discord bot flow for their quests. In this case, the #mobile-platform team would be able to integrate with it, so that every efforts on the First Quest project's side is multiplied by having the mobile experience exposure.

 

Projects and Bounties

 

• The interface would present two separate sources of data:
Currently registered DAO projects that have at least 1 open role to fulfill.
Currently open bounties to claim.

• The proposed bounty list integration would require the following executable items that fall under the aggregate content scope discussed earlier in the document:
1. Coordinate with the Bounty Board project team to get their public data exposed with an API.
2. Integrate the API with the mobile platform aggregated content web service.

• The proposed project list integration would require coming up with a solution from scratch, but hopefully relying on the existing infrastructure.
One way to do it is to use the currently maintained projects page in the DAO's Notion, and pull the data using the Notion API.
Relevant Notion API docs: https://developers.notion.com/reference/retrieve-a-page.
This, however, would require some sort of validation of the data entered by humans.
Another possible approach is to create a Discord bot that manages team requirements for project teams, and then expose that bot's data via another API.

 

Team-up Wizard

 

• This feature is considered a stretch goal for Season 2, and it's a bit out there compared to most other ideas. But it can be relatively easy to implement.

• In order to be matched, the DAO members would have to provide their profile info similar to how Tinder does it.
There is an immediate privacy concern, so it's important to make this feature respect the anonymity and communicate its purpose clearly.

• The profile info can be stored in a dedicated web service, or on IPFS for the user to own it.

• The proposed matching algorithm for Season 2 would potentially fit on the app side with no need to host it remotely. Thus, the app would be able to tell the matches immediately after getting the profile info.
Again, this approach would mean the profiles are stored publicly (e.g. IPFS), so the privacy concern is still there. However, there are many possible creative ways to introduce more privacy without a ton of extra development resources.

• Upon matching, the user would be able to connect with other users on Discord, given their previous consent.
Should Legal guild be involved in this in some way?