Token Request App

[lkngtn]

Would enable anyone to create a vote to mint tokens for themselves.

• Should allow users to include a payment (eth or tokens) that is returned to them if they are rejected, and put in a vault the organization if the request is approved.
• Should allow organization to configure a minimum payment required.

[yeqbfgxjiq]

What was the intention/goal for this app?

So there's a stake required to make requests to the DAO, and if that request is granted then a fee as well?

• would it make sense to add that if the request is identified as spam or clearly not aligning with the goals of the DAO then the stake will be burned? (but the stake should not be taken in the case of spam filtering because then there's an incentive to turn down requests to steal cash)

[lkngtn]

I was thinking of it as a way to formalize the membership process into the organization itself in a way that would generalize well to other organizations.

would it make sense to add that if the request is identified as spam or clearly not aligning with the goals of the DAO then the stake will be burned? (but the stake should not be taken in the case of spam filtering because then there's an incentive to turn down requests to steal cash)

I'm not sure its necessary, as I think just having to put up a deposit even if its returned if not accepted is probably sufficient spam deterrent.

[yeqbfgxjiq]

The BEE-HONEY V2 model kind of addresses this where anyone who holds HONEY can create a vote or vote on current things. Do you think that's enough, or would it be wise to go the extra step and add a deposit/staking feature?

[lkngtn]

I see this primarily as basic fundraising mechanism, that is simpler and more permissioned/manual then something like apiary.

[yeqbfgxjiq]

Ok cool. So maybe this would be a good app to create next before launching an MVP?

Also, how would price discovery work. Would the hive set a flat rate of HONEY / BASE_TOKEN that we would accept before there's a dynamic mechanism like a bonding curve?

[yeqbfgxjiq]

Starging to plan ahead on how to best curate open Issues on the website, dao, and communication repos to move us towards shipping the MVP on mainnet. I think it makes sense to prioritize the Token Request App ASAP so that we can accept payments from donors, grants, and/or projects that want to engage with BEEs to get stuff done. Since the Redemptions app is starting to move into testing stages, I think it makes sense to move the Token Request App into development. Created a repo for that here.

If you guys disagree or think there's something else that should be a priority though please let me know! :)
Otherwise I'd say let's close this Issue and move our attention to the Token Request App repo

[lkngtn]

I think the token request app is an interesting idea that might make sense to pursue next... but tend to feel like we should focus on Redemptions right now before pushing forwards into other development projects. iron out the kinks in our process there, and then consider what comes next.

I think we have a number of possible directions we could go, and and I think I would have liked to see us flesh out some of these idea a bit more before moving to a repo. Perhaps we could use the issue curation feature of the projects app to help prioritize ideas as a group?

[yeqbfgxjiq]

I think the token request app is an interesting idea that might make sense to pursue next... but tend to feel like we should focus on Redemptions right now before pushing forwards into other development projects. iron out the kinks in our process there, and then consider what comes next.

I think we should always be pushing to the next thing so that anyone who wants to dive in and get involved has a clear idea of how they can contribute. Perfection is the enemy of good and shipping/building things makes the MVP possible and will also inspire people to learn about the project and get involved.

I think we have a number of possible directions we could go, and and I think I would have liked to see us flesh out some of these idea a bit more before moving to a repo. Perhaps we could use the issue curation feature of the projects app to help prioritize ideas as a group?

As is the Token Request App said that it was a simple mechanism that would allow us to receive donations and formalize the onboarding process for the MVP. Then we could upgrade to a bonding curve in V2 like we started discussing in the ideas repo. What are the other options you see?

Also, issue curation via the Projects app would be great, but it's not working atm. Also, in the handbook that was kind of assigned to the Curator role. I agree that it makes sense to have a more collaborative community driven process, but we should be clear about how it relates to current roles/responsibilities and/or if we want to change those roles/responsibilities.

I think that for the MVP it makes sense to create the model outlined in the handbook, then ship it and get real world feedback/data, then build a better model for V2. Otherwise if we change stuff around for every decision it's going to add exponential cognitive overhead for everyone to keep up, which will slow progress and knee-cap moral. As is I think we need a basic app that allows us to get real funds in the vault and distribute them to BEEs for doing real work that solves problems in the real world. The Token Request App does that, and from the description it seems like a simple model that we can build and ship now without any addition R&D. Also, it would greatly help with the Grants Workflow Issue by allowing us to take in funds, and then transparently allocate them to specific projects/issues.

[lkngtn]

I think we should always be pushing to the next thing so that anyone who wants to dive in and get involved has a clear idea of how they can contribute. Perfection is the enemy of good and shipping/building things makes the MVP possible and will also inspire people to learn about the project and get involved.

Do you feel like we are going slow? 😅 I feel like we are making lots of progress.

The first version of Redemptions contracts hasn't really been tested or had tests written yet, we don't have a mock-up for the UI, or documentation/instructions for how it could be used without a UI.

It feels like we should be creating issues and figuring out what needs to be done to ship redemptions before trying to start a completely new app.

As is the Token Request App said that it was a simple mechanism that would allow us to receive donations and formalize the onboarding process for the MVP.

I'm not sure that the Token Request App is required at all for "MVP" or what consensus on what MVP is?

Also, issue curation via the Projects app would be great, but it's not working atm. Also, in the handbook that was kind of assigned to the Curator role. I agree that it makes sense to have a more collaborative community driven process, but we should be clear about how it relates to current roles/responsibilities and/or if we want to change those roles/responsibilities.

I think additional clarity is good, but in https://1hive.org/docs/contribute/projects-tasks.html#expectations-of-curators I think the idea is that while curators are ultimately making the decision to fund specific issues, the idea is that they are seeking consensus among the group to prioritize efforts, ensure that issues are adequately scoped, and working with devs to get good estimates before funding.

I think that for the MVP it makes sense to create the model outlined in the handbook, then ship it and get real world feedback/data, then build a better model for V2. Otherwise if we change stuff around for every decision it's going to add exponential cognitive overhead for everyone to keep up, which will slow progress and knee-cap moral.

I disagree, I think in many ways we have already shipped an "MVP", the dao is live on rinkeby, and we are using it to coordinate our activites, we are actively using it and learning from that experience as we go. While I agree it is important to focus, reach a milestone, evaluate, and iterate. We should not hesistate to make adjustments to the process as we encounter issues, that is what rapid iteration looks like.

As is I think we need a basic app that allows us to get real funds in the vault and distribute them to BEEs for doing real work that solves problems in the real world.

If anything the additional requirement of another application feels like scope creep and shifting goal posts. Many open source projects are run completely by volunteers, while I think that is a shame and I would like to see more funding for open source development, I think its also important that we have a system which works even when funding is scarce or non-existent, and simply works better when funding is introduced.

The Token Request App does that, and from the description it seems like a simple model that we can build and ship now without any addition R&D. Also, it would greatly help with the Grants Workflow Issue by allowing us to take in funds, and then transparently allocate them to specific projects/issues.

I think the Token Request App is useful, but not essential to what we are doing right now, especially if we plan to experiment with Apiary. And while my understanding of it is that is should be pretty simple to implement, it feels like you are trivializing the effort that is required to actually develop and ship an application.

[yeqbfgxjiq]

Do you feel like we are going slow? 😅 I feel like we are making lots of progress.

I think we're doing great :) It doesn't hurt to have the next thing lined up though if anyone wants to work on it.

The first version of Redemptions contracts hasn't really been tested or had tests written yet, we don't have a mock-up for the UI, or documentation/instructions for how it could be used without a UI. It feels like we should be creating issues and figuring out what needs to be done to ship redemptions before trying to start a completely new app.

My thinking is that creating a front end UI is separate from solidity dev/testing, so having multiple projects with varying requirements would allow people to work on whatever they want. We added 3 new people this week, and if we do the same next week we'll need things for people to work on.

As is the Token Request App said that it was a simple mechanism that would allow us to receive donations and formalize the onboarding process for the MVP.

I'm not sure that the Token Request App is required at all for "MVP" or what consensus on what MVP is?

Sorry for the confusion. I just mean the minimum viable prototype we need to ship a model that allows for sustainable open source development. Right now we're running on altruism and curiosity, which is great, but not the mission of the project.
EDIT: as per your suggestion on Keybase, going to start saying "mainnet" rather than MVP or V0 or whatever else

Also, issue curation via the Projects app would be great, but it's not working atm. Also, in the handbook that was kind of assigned to the Curator role. I agree that it makes sense to have a more collaborative community driven process, but we should be clear about how it relates to current roles/responsibilities and/or if we want to change those roles/responsibilities.

I think additional clarity is good, but in https://1hive.org/docs/contribute/projects-tasks.html#expectations-of-curators I think the idea is that while curators are ultimately making the decision to fund specific issues, the idea is that they are seeking consensus among the group to prioritize efforts, ensure that issues are adequately scoped, and working with devs to get good estimates before funding.

That's awesome. I support that 100%. We should make that more specific in the website/handbook though so that everyone is on the same page :)

I think that for the MVP it makes sense to create the model outlined in the handbook, then ship it and get real world feedback/data, then build a better model for V2. Otherwise if we change stuff around for every decision it's going to add exponential cognitive overhead for everyone to keep up, which will slow progress and knee-cap moral.

I disagree, I think in many ways we have already shipped an "MVP", the dao is live on rinkeby, and we are using it to coordinate our activites, we are actively using it and learning from that experience as we go. While I agree it is important to focus, reach a milestone, evaluate, and iterate. We should not hesistate to make adjustments to the process as we encounter issues, that is what rapid iteration looks like.

The DAO is kind of on Rinkeby, but the Projects app is broken, we don't have an Allocations Admin, we don't have Payroll, we aren't minting HONEY, and we don't have a way for people to support the project or acquire HONEY to signal priorities for the community. This is not the model that is described in the handbook, and it's certainly not sustainable open source development. We're doing great and making a lot of progress, but we're not there yet.

As is I think we need a basic app that allows us to get real funds in the vault and distribute them to BEEs for doing real work that solves problems in the real world. If anything the additional requirement of another application feels like scope creep and shifting goal posts. Many open source projects are run completely by volunteers, while I think that is a shame and I would like to see more funding for open source development, I think its also important that we have a system which works even when funding is scarce or non-existent, and simply works better when funding is introduced.

How is it shifting goal posts if it's fulfilling the spec outlined in the handbook? We need a way to get assets into the vault for BEEs to exchange HONEY for. We can't do that yet.

The goal is to make open source development of the commons sustainable. Any DAO allows a community to collectively make decisions. Our value add is that we make it sustainable so that the commons aren't guided by corporate interests or pure altruism. That's what makes this exciting... for the first time that's actually possible and we could empower millions of people who are currently choosing between paying rent and doing things they love and care about. This could change the way people think about and build software forever.

The Token Request App does that, and from the description it seems like a simple model that we can build and ship now without any addition R&D. Also, it would greatly help with the Grants Workflow Issue by allowing us to take in funds, and then transparently allocate them to specific projects/issues.

I think the Token Request App is useful, but not essential to what we are doing right now, especially if we plan to experiment with Apiary. And while my understanding of it is that is should be pretty simple to implement, it feels like you are trivializing the effort that is required to actually develop and ship an application.

I can't speak to the effort required, but I do know that building a bonding curve is going to be harder than building a token request app. Also, Aragon Black is already working on that. Also, the token request app could serve the broader DAO community by fulfilling a niche that is currently not served. It seems useful, achievable, and like something that would help us make 1Hive a sustainable DAO sooner than later.

[lkngtn]

How is it shifting goal posts if it's fulfilling the spec outlined in the handbook? We need a way to get assets into the vault for BEEs to exchange HONEY for. We can't do that yet.

Putting funds in the vault is as easy as convincing someone to make that transfer, there isn't anything in the handbook that specifies exactly how that would happen (and it generally depends on what the organization decides to do or prioritize). As has been pointed out, a lot of the work we are doing provides tremendous value for the Aragon ecosystem, so we could approach them through one of the multiple grant programs they offer (CFDAO, Nest, Flock) to sponsor the organization. We could focus on our processes and test apiary prior to their anticipated July launch, and make Apiary are primary source of long term funding. We could also create a github grants page.

Alternatively/Additionaly we could decide to prioritize efforts which would allow us to support organizations we onboard with services resulting in a long term sustainable business model--eg offering a subscription service that adds push notifications, a github bounty bot, state caching, etc).

The point I'm trying to make is that the flow in the handbook doesn't actually have any specific assumptions about the source of funding, and for many open source projects there may not be an immediately obvious source of funding or business model. But by using the process and rewarding contributors with governance tokens, you at a minimum are rewarding them with voice in the projects future direction, and have a fair wait to distribute revenue if a path towards funding is identified.

I don't think there is a magic panacea for sustainable open source development, if you don't have a defensible business model you are still fundamentally dependent on donations/grants/patronage of some sort. What we can do is help establish transparency, accountability, and improve "equity" for contributors.

[yeqbfgxjiq]

As has been pointed out, a lot of the work we are doing provides tremendous value for the Aragon ecosystem, so we could approach them through one of the multiple grant programs they offer (CFDAO, Nest, Flock) to sponsor the organization.

I support that. If there's an equal exchange I'm happy to contribute to work that benefits 1Hive and Aragon. We would first need to launch to mainnet first to actually be able to accept funds. The Token Request App would make that process smoother, but if we can just accept funds without it then let's do that first.

We could focus on our processes and test apiary prior to their anticipated July launch, and make Apiary are primary source of long term funding. We could also create a github grants page.

I like the idea of Apiary a lot. I think it makes the most sense of all the models we've explored. If you think we can test that out before July, then I'm happy to move in that direction :) I just didn't want to get in a situation where we're stuck waiting and can't move forward.

Alternatively/Additionaly we could decide to prioritize efforts which would allow us to support organizations we onboard with services resulting in a long term sustainable business model--eg offering a subscription service that adds push notifications, a github bounty bot, state caching, etc).

I imagined the HCL fulfilling that purpose where if projects use the apps we ship, they kick back some love. Initially this would only work with blockchain native/crypto applications, but in the future it could be expanded. We've also designed several token models that can bootstrap and sustainably support organizations, the best of which being the bonding curve model. I'd say let's focus on those first before trying to become a SASS business. While it is important to have funds coming in, I think the real exciting thing about 1Hive is we design (and ship) cryptoeconomic models that create new opportunities. I think we should focus on that and being the go-to place for anyone who wants to learn about that. It'll help differentiate the project from others and it's just more fun and interesting :)

The point I'm trying to make is that the flow in the handbook doesn't actually have any specific assumptions about the source of funding, and for many open source projects there may not be an immediately obvious source of funding or business model. But by using the process and rewarding contributors with governance tokens, you at a minimum are rewarding them with voice in the projects future direction, and have a fair wait to distribute revenue if a path towards funding is identified. I don't think there is a magic panacea for sustainable open source development, if you don't have a defensible business model you are still fundamentally dependent on donations/grants/patronage of some sort. What we can do is help establish transparency, accountability, and improve "equity" for contributors.

Recognition and a voice is super important. I think we would be wise to highlight that and create lots of information and applications to improve that for communities. It's really the engine that drives growth and engagement.

That being said, funding is the engine drives sustainability. While there's no magic panacea for sustainable open source development, I think we can create several models/frameworks that can be very helpful for various usecases. 1 size doesn't fit all, but we can have a library of different models and resources to make them happen, and even templates that communities can quickly deploy to try them out. Transparency, accountability, and "equity" are improved by default just by using Aragon. Our value add is creating token models and apps that make the whole thing sustainable. At least that's how I see it.

[lkngtn]

The Token Request App would make that process smoother

How? If anything it would complicate things as none of the grants programs offered by Aragon expect any tokens in return for the grant?

I like the idea of Apiary a lot. I think it makes the most sense of all the models we've explored. If you think we can test that out before July, then I'm happy to move in that direction :) I just didn't want to get in a situation where we're stuck waiting and can't move forward.

I don't think we will be able to test it on mainnet before july, but I expect we can definitely test it before then on testnet.

I imagined the HCL fulfilling that purpose where if projects use the apps we ship, they kick back some love. Initially this would only work with blockchain native/crypto applications, but in the future it could be expanded.

I don't think that funding will be very significant from the HCL for a long time, particularly if the only applications that are licensed under it are our applications because there isn't really any reason for someone to create proprietary derivative work, and therefore no reason for them to have to pay a tax back to the commons.

I think what you are describing may be more of a subscription fee for installing and using the application (which is totally doable with or without a license), but if it was done with a license it wouldn't really be a FLOSS license, it would be more like a proprietary license with public source code.

We've also designed several token models that can bootstrap and sustainably support organizations, the best of which being the bonding curve model. I'd say let's focus on those first before trying to become a SASS business. While it is important to have funds coming in, I think the real exciting thing about 1Hive is we design (and ship) cryptoeconomic models that create new opportunities. I think we should focus on that and being the go-to place for anyone who wants to learn about that. It'll help differentiate the project from others and it's just more fun and interesting :)

Based on your description of the HCL, it sounds a lot like a SAAS business, perhaps we can move that discussion to the HCL repo, but im curious to understand your interpretation of how the license works?

Transparency, accountability, and "equity" are improved by default just by using Aragon. Our value add is creating token models and apps that make the whole thing sustainable. At least that's how I see it.

I don't really think the token model really makes things more sustainable if there isn't inherently a sustainable source of funding. The goal of apiary (atleast in the context of 1hive), is to connect patrons (who want to financially support a project and perhaps speculate on project popularity among other patrons--benefiting from curation/tastemaking) and projects themselves. Hopefully by making this connection there will be more financial support for projects then there otherwise would be, but ultimately this is still essentially a donation model.

The HCL approach is fundamentally more self-sustainable in that it defines the commons and creates rules for how the resources are used and maintained. If successful it would create a source of funding which could be directed to projects that not neither a grant, nor revenue/profit, but something closer to a subsidy derived from tax revenue (but without a government).

[yeqbfgxjiq]

If you don't think the Token Request App would be helpful atm and we can do without it then let's do that. I thought it would be helpful, but if it's more work than it saves let's just keep it in the ideas repo. If you agree, I'll just port the README from the token-request-app repo to the ideas repo issue and then it can live there?

Also, it sounds like we're imagining a different model for 1Hive. I see it as an organization of BEEs who have useful skills that are centered around a specific focus (for 1Hive that's DAOs, token models, and Aragon apps). BEEs can contribute to the organization's direction by voting with their BEE token. BEEs can also earn HONEY to be rewarded for their work. HONEY can be used to give people influence in the org or can be cashed out against the DAO vault and/or a bonding curve. The "business model" is that if people want BEEs to work on stuff, or want to influence the direction of the hive, they can purchase HONEY to make that happen. The more useful/reputable the hive is, and the better work they do, the more incentive there is for people to purchase HONEY in order to get BEEs to help them build/do stuff. The purchase of HONEY rewards BEEs for doing work by allowing them to exchange HONEY for other tokens they can turn into cash. The whole thing is community driven because BEEs and HONEY holders vote on how the org operates and drive it's direction. HONEY holders can also exchange HONEY for cash. Thus, it's community driven and sustainable. Do you also see this, or do you imagine something different?

And yeah you're right my interpretation of the HCL does sound like a SASS model lol. It's been a min since I read all the HCL posts, and I read them all together so various iterations of the idea blended together in my head. The way you described it sounds cooler than what I was thinking though, so I'd like to better understand what you're imagining. What's the latest/best doc to reference that aligns with your current thinking on the HCL?

[lkngtn]

Also, it sounds like we're imagining a different model for 1Hive. I see it as an organization of BEEs who have useful skills that are centered around a specific focus (for 1Hive that's DAOs, token models, and Aragon apps). BEEs can contribute to the organization's direction by voting with their BEE token. BEEs can also earn HONEY to be rewarded for their work. HONEY can be used to give people influence in the org or can be cashed out against the DAO vault and/or a bonding curve. The "business model" is that if people want BEEs to work on stuff, or want to influence the direction of the hive, they can purchase HONEY to make that happen. The more useful/reputable the hive is, and the better work they do, the more incentive there is for people to purchase HONEY in order to get BEEs to help them build/do stuff. The purchase of HONEY rewards BEEs for doing work by allowing them to exchange HONEY for other tokens they can turn into cash. The whole thing is community driven because BEEs and HONEY holders vote on how the org operates and drive it's direction. HONEY holders can also exchange HONEY for cash. Thus, it's community driven and sustainable. Do you also see this, or do you imagine something different?

I think we are on the same page here for the most part.

I guess the main difference is I see Bee token as sort of maintainers/caretakers/culture-setters of the organization. The role may change a bit if we adopt a different economic model (eg we associate Honey with an Apairy bonding curve), but currently it is roughly based on worker cooperative governance, where the root authority in the organization is based on 1 member 1 vote. There currently isn't a business model, and there isn't currently a specific proposal for how to get funding, though I think there are many paths for us on that front. But given the basic model I wouldn't necessarily expect to grant governance rights of any sort in exchange funding, I see it more as a service arrangement than an investment.

Using the token request app, you could create a dao like moloch, where you are basically granting decision making authority based on capital contributions (or work contributions). But this feels like a very different model then what we have been documenting. I think it is super useful and would love to see us build the token request app, but I don't see it as a critical path.

And yeah you're right my interpretation of the HCL does sound like a SASS model lol. It's been a min since I read all the HCL posts, and I read them all together so various iterations of the idea blended together in my head. The way you described it sounds cooler than what I was thinking though, so I'd like to better understand what you're imagining. What's the latest/best doc to reference that aligns with your current thinking on the HCL?

I think the harberger taxation and open source post is the best resource right now, but looking forward to brainstorm with more people. I think the main thing not covered in there is that I think that CLR matching mechanism is probably ideal for allocating the funds, where in the post I suggest a few different possibilities.

https://1hive.org/blog/2018/08/14/harberger-taxation-and-open-source.html

[yeqbfgxjiq]

I too see the BEE token holders as maintainers/caretakers/culture-setters of the organization. It's the core team.

Also, I see HONEY as a hybrid between moloch and a pure donation. HONEY holders can stake honey to Issues they want BEEs to work on, but no BEE has to do anything. It's all opt in. Furthermore, some votes will be determined by BEEs and some by HONEY, so there are checks and balances and one group can't dominate the hive.

Regarding a business model, it's simple: anyone can purchase HONEY to support the hive as a donation, signal preferences to the hive, or to stake rewards on specific tasks (docs, apps, etc). If you want to engage with the hive and have the attention of BEEs, you buy HONEY. You're not "hiring" bees and you're not just "donating" either. It's in between, and that's what makes it magic.

[yeqbfgxjiq]

Building on that, if the skills and attention of BEEs are highly valued and in demand, and are priced appropriately (on a bonding curve), this could be a viable alternative to traditional freelancing. It can also be applied to open source communities that develop skills/expertise around a niche app/thing. If you use the software that an open source community maintains, you could buy their native token to actively support the development of features you request or to guide attention to the Issues you open. Of course the open source community is free to pay attention to or ignore these stakes/requests, but it makes the entire process more dynamic and rewards the open source community for their time/effort.

The HCL could even extend this further with recurring revenue for the open source community. I'm sure there's even more mechanisms that would be helpful, and I'd love to see 1Hive explore, document, and build them all so that open source commons/communities can thrive :)