High level feedback: I think there is too much included in this proposal to fully understand what is actually being proposed for the 6 month period. It’s hard to determine if it’s an Aragon app development effort, or a Native app development effort.
Due to how much Native and NTV is referenced in the proposal, there may be a conflict of interest in some manner as far as which ecosystem the team would be focused on growing, and whether the relationship can be indeed be complimentary.
Native could have been leveraging the Aragon technology stack for over a year – why now? That’s not to say that only teams that have previously built on Aragon should apply for Flock funding (or maybe that would make more sense…), but you may be better off applying for a Nest grant requesting a smaller amount of funding first and/or developing a proof of concept of one of the apps proposed.
Just offering my opinions here. There are more detailed questions below.
I01 - Network Economic Model
Can you please describe in more detail with how you plan to roll this out in the context of Aragon apps.
What changes would be needed to the existing tech (such as the vault)?
What new apps would be created?
Will the token be a minime token?
As part of this initiative do you indeed intend to integrate with Uniswap, Bancor, and 0x within 6 months? How do you see these integrations working in the context of Aragon?
Any revenue that is earned can be split between the reserve and community fund at the organization’s chosen split ratio.
Can you describe how you intend to accomplish this within the context of Aragon?
Leveraging a chosen base token for a subset of organizations’ tokens creates a network effect, so that when one community grows, the value held in reserve by the other communities also increases. This could apply to ANT, and the arApp would enable any token to be used as a base.
I’m a bit confused by what you are describing here, is it smart contract logic or something more general?
I02 - Staking for Membership
In addition to these components, a registry can provide member-specific content (either for organizers or the public) and the ability to connect with members (who have chosen to be public).
Can you explain what you mean by “ability to connect with members”. How would that be accomplished in the context of Aragon?
A whitelist function within a registry enables anyone to own tokens, but still limits who is actually able to participate in governance decisions and who can complete tasks/bounties.
This is already possible with Aragon’s permission system.
Blacklists enable organizations to kick someone out of the governance and operational aspects of an organization but let them keep their tokens to be used as currency.
Assuming one has created an Aragon DAO with two tokens, this is already possible with Aragon’s permission system.
Access scripts allow for communities’ native applications or web content to only be accessible if a user is a member of the organization and/or holds a minimum number of tokens (ultimately leading to tiered access within organizations).
This can unlock entire web pages, download links, discount coupons, text content, and more. The only thing that would be required is for a developer to inject a few lines of web3 code into their website or mobile application and for the user to be browsing on a web3 browser.
Is this proposed development work for https://nativeproject.one/ ?
I03 - Community Templates
Templates will be created for various community verticals (examples: music festival, event, lifestyle organization, etc.) and make it simple for anyone to deploy a DAO that effectively meets their needs.
Can you give an example of how a lifestyle organization’s DAO template would differ from a music festival? Which apps would they launch with, and what would the initial governance parameters be?
I04 - Community Action Recipes
Community growth recipes are a series of projects and tasks/bounties that are deployable within an organization to achieve a new level of growth. They can be general or vertical-specific.
For example, there could be a “gain members from Facebook” recipe that has tasks getting members to invite friends on Facebook into the organization and a project to run a social media marketing campaign (also on FB in this case).
Over time, each recipe has a success metric, and the most effective will rise to the top and be implemented across many communities/organizations.
Can you describe how you would accomplish this within the context of Aragon? How many applications would be needed? Which existing ones would you be leveraging?
I05 - Organization Healthgrades and Valuations
This initiative is to more clearly understand the activity levels of each organization and how that activity correlates to its valuation.
In a world where 40% (and increasing) of internet traffic is “fake,” it is important to have insight into the underlying KPIs of an organization to determine whether or not they are creating a false image of success.
I don’t think this initiative will provide any near-term value. We need more active organizations in Aragon first and foremost.
I06 - Member Experience Research and Reporting
This initiative is to contribute (and collect) as much in-person education (and feedback) as possible via the flourishing crypto community in Denver, as well as to organize our digital feedback and ultimately leverage a TCR for member-driven prioritization of development goals.
What do you mean by “member-driven” - who are the members here?
Why do you think in person feedback from one crypto community (Denver) is more valuable than expanding the research area globally, to organizations more likely to use Aragon-- and interviewing with video calls?
How many meetups a month do you plan on organizing?
A TCR would be implemented to prioritize and align development efforts (see District0x for TCR implementation), as determined by NTV and ANT holders. Ultimately, the TCR could trigger capital allocations directly to specific projects, developers, contractors, etc. and make the outcomes binding.
So you are proposing developing a TCR app just for the purpose of NTV and ANT voters prioritizing development?
I07 - Member Benefits Packages and Physical World Connections
The physical world connection of these benefits primarily relates to how they are accessed and utilized. QR codes and NFC are the clear frontrunners of interaction between planes. Native will be the first to implement and optimize these functions over time as we gather opt-in feedback from users.
I’m having a hard time understanding what you plan on actually building (development-wise) as part of this initiative.
I08 - “That Planning Suite” Reputation Modularity
I have to admit, this section is a bit over my head in ways. What is the MVP that you intend to accomplish in this initiative in 6 months?
E.g. can you describe the relationship between TPS and colony?
If i am earning reputation in colony, how often do I have to swap my rep in Aragon?
Would the tasks in TPS be the same as the ones in colony?
I09 - Gamification
I don’t think this initiative will solve near-term adoption of Aragon.
I10 - Connect API
In the not too distant roadmap we’d be contributing a Services arApp to provide permissioned endpoints for interacting (i.e., voting) with any DAO using any front end interface (i.e., Native) and utilizing authentication via any web3 provider (i.e., frame.sh).
I’m not sure about how needed The Graph work is (especially as there are a few community funding DAO proposals related to analytics), but external Voting widgets sound useful assuming they will indeed work with “any front end”.