I came upon this post (Pollen Automation đ”) a few days ago. I discovered the problem and attempted to explain it here. It all comes down to AUTOMATION. Thatâs odd, I know. But bear with me as I explain. While I am in favor of that proposal, I am concerned about procedures that are meant to be routine.
Notice that we are in the genesis stage and we should be concerned about the future. Plz, pay attention to the special factor that has made 1hive unique in the crypto space. What has been making the 1hive community as a complex social system unique? IMO the most crucial element is to respond to these two queries. WHEN DOES VALUE FIRST SHOW UP? WHERE DOES THE VALUE IN HNYâS CREATING COME FROM? To create value, the bulk of projects rely on capital. When money is invested in a project, it is assumed that value is created, allowing the project to supply more tokens. These concerns recur in every discussion of bonding curves.
Regardless of what others perspective, we regard money to be a sort of organizing. When bees come together as a swarm, to meet a need or share an idea, they can contribute to the circulating honey in a transparent and collaborative process. 1hive is a self-contained entity with its own organization and funding. Important building blocks of theory of âmoney as organizationâ are the interplay between the individual and the social dimension. That is, as individuals become onboarding and the organization grows, 1Hive becomes more valuable. We should adhere to this principle, basically in the debate over HNYâs supply. Based on this principle, HNYâs supply is not pre-determined and limited, and there is no bonding curves based on time, marketcap or even price. Everything is left to the community. IMO âthere is no core teamâ means âthe future and Everything is left to the communityâ.
I recognize that we are at the start of the journey. But If all these arguments are true, we should pay more attention to growing the community as a complex system. A self-organized adaptive system with a indeterminate emerging future. Therefore, more attention should be paid to cases where the discussion is about the process of community growth. You know?! Basically, the fewer pre-defined rules and procedures, the better. I know we are on beginning of road, we should move forward and avoid fussing. But we have to worry about the solutions that will shape the future as procedures that will remain in the community.
If a problem can be solved locally by swarms of bees, it should not be tackled with codes that involve the entire community. Basically, the people I encounter and connect with are more important to me than the programs. I prefer distributed voting and disputes. The Celecte project illustrates what I consider to be an optimal approach. As a result, AUTOMATION and coding should not be used as a universal strategy to address 1hiveâs difficulties.
Do you have any ideas on how to grow or otherwise improve community engagement?
Overall automation and trustless protocols are a core feature of cryptoeconomic/cryptogovernance systems. But yes, our local swarms are described as you say, with their own preferred internal structure. This funding also is determined through the conviction voting system which is surprisingly local for being a general purpose funding system.
I guess we can agree on the overall premise of the importance of the community but I donât see where automation isnât benefitial.
This doesnât mean that every single thing we do should be done by hand if we have the tools to automate the processes, that way stuff is done in a more cost efficient way and our community can further expand and explore another concepts and ideas.
What really concernes me is the transparency and flow of information within our community (not saying that weâre donig a bad job, but I think is an issue thatâs going to be more prominent as the community grows); but seems like no one else feels the same way.
mate⊠that was a good write up, but I have to say that I do not agree with the âNo Automationâ approach. I mean the whole premise of smart contracts and âcode is lawâ is so that we do not bring human emotion into decisions. I mean things such as emissions, source cred and pollen distribution being automated will make this 1Hive machine work much more efficiently. What is the use of someone doing unproductive work when this can be automated? I agree that automation is not the answer for everything as I do believe there is times when you need the human interaction as demoed by Celeste.
Youâre right⊠And I didnât tell No Automation approach⊠As crypto enthusiasts, we know that automation is essential to the crypto world. âCode is lawâ thatâs correct⊠I say: as a general approach, Automation should not be used. the law is required. But the less and the simplest, the better. for example, in $ALVIN caseâŠ
Thereâs no problem if weâre going to back Alvin. Letâs do it. But just donât start making it into a 1Hive protocol. There is no consensus on whether the idea is eternally necessary. Then why should we extend it into a community-wide process? In the future, it will be essential to react and apply settings that are adapted to the new unknown conditions in each case. It is preferable not to figure it out at the level of the 1Hive problem. If assistance is required, it should be provided on a case-by-case basis, similar to the Agave, or made into a project alongside other ventures. A DeFi, for example, can be insured in exchange for some interest. If this idea fails and a large number of losses are incurred in the future, 1Hive will not be harmed. On the other side, if we make this service a protocol, we risk jeopardizing the communityâs integration. Which of the following projects must be submitted as a qualified project? The most important things are synergy and empathy.
Ah I see what you mean now, but not sure if i can connect it to automation. From what i read, you are concerned about projects that either spawn from 1Hive or spawn elsewhere and seek 1Hive as a platform to launch themselves (similar to Alvin) may provide a bad rep to 1Hive if they fail or get hacked and it may reflect negatively on 1Hive as a whole? I agree with what you say there and hence there needs to be some sort of vetting of any future projects that seek to use 1Hive as a platform. There is some discussion also on how to develop guidelines to try and mitigate from similar issues in the future. But like I said unsure if I am able to make the connection between this issue and automation.