Cloudmos Funding Proposal

[baktun14]

Akash Network - Cloudmos Funding Proposal

Summary

Hello Akash community! We are excited to present our proposal for funding of 300k USD in $AKT from the community pool as a partial retroactive of our past efforts and going forward, to continue developing and building new tools that will facilitate the adoption of the Akash Network. Ideally, while 400K would give us increased runway and flexibility, we believe given current market conditions, we can accomplish the same deliverables with 300K in funding. Although we previously requested funding for a similar amount nearly a year ago, our proposal was denied due to unfavorable market conditions. Despite this setback, we have remained committed to our mission and continued to develop our free products, which have already been instrumental in supporting the growth and adoption of the Akash Network. We were fortunate to receive a small grant worth ~60k USD a few months later, but we believe that this amount is insufficient to cover our expenses and to fully realize our vision. We’re passionate about enhancing the user experience of blockchain and decentralized cloud technologies. With your support, we’re confident that we can take our work to the next level and significantly impact the Akash ecosystem. Thank you for your consideration!

Achievements and Past Contributions

Over the past two years, our team has made significant contributions to the Akash Network, including the development of Cloudmos Deploy, the top GUI deployment tool, Cloudmos Explorer, the primary analytics hub for real-time Akash adoption metrics, and Cloudmos Alerts, a customizable alerts system for deployment balance monitoring and other custom alerts. Additionally, we created SDL Builder, which enables easy custom SDL creation and saving, as well as a price comparison tool for comparing Akash's cost savings vs. legacy platforms like AWS, GCP, Azure, etc. Our efforts have facilitated onboarding for many new users on the network, with impressive results:

From January 2022 to today:

• Deployments
  • 29.5k Leases (50.2k total created on the network so ~58% of all leases on the Akash network were created using Cloudmos Deploy)
  • 5k Users
  • 144k Transactions
  • 42.4k Deployments
  • 3.1k Wallets created
• Explorer
  • 18k Users
  • 180k Views

Our team's deep understanding of the challenges facing the Akash Network, coupled with our development of critical tools and technologies for cloud parity, positions us perfectly to execute this proposal. We're confident that our past contributions and expertise makes us the ideal team to lead the way forward. With the rise of GPUs and AI, now is the perfect time to invest in the right tools to support future adoption. Our record speaks for itself.

Problems and Proposed Solutions

Here’s a list of issues we’ve identified and solutions we’re proposing to implement:

• Trust. It’s difficult to trust providers without sufficient information of their operations and reputation.

  Solutions

• To be able to obtain cloud parity and to build trust towards developers, Akash needs to have active monitoring of providers and a platform to provide that information to users

• A reputation system with provider reviews

• Provider profiles

  • What is their hardware?
  • What Akash features do they support? (Persistent storage, IP leases, GPU, etc)
  • Logo
  • Company
  • What is your hardware best for? Gaming? Mining? Etc.
  • Terms of services and Service-Level agreements

  Remarks

• With our custom built indexer and infrastructure, we already keep track of providers but only have minimal information. It will be easy for us to extend that functionality to track more information on the providers and provide an API for others to consume.

• With our user accounts, we can make it possible for providers to create a custom profile and have that information displayed throughout the deployment process and be used to automate some processes based on their reputation. We can also make a user review process with those same user accounts.

• With these systems in place, we believe that users deploying on the Akash providers will have a better sense of trust when choosing providers to run their workload and also other clients who want to use our API will benefit from this system.

• There are no systems like this currently available.

---

• No SLA. There is no SLA or uptime system to make sure your deployments stay online 24/7. Currently, if your provider suddenly goes offline, your lease dies and the user has to make sure to keep track and re-deploy when that happens. Most users don’t want to take care of this themselves. Comparatively speaking, when people deploy on web2 platforms like DigitalOcean, AWS, GCP, and Azure, they are paying for the SLA, and the reassurance of stability. We intend to bring this feature to the Akash Network.

  Solutions

• Implementing various automatisation tools using Authz

  • Auto redeploy when provider is down
    • The balancer could also auto-scale based on demand
  • Auto re-negotiation redeploy on providers when a better lease is available for the current AKT price, before a solution is implemented with the proposal Akash economics 2.0
  • Auto refill when deployment balance is low

• Help build tools for the community to address common issues with deployments

  • Automated backup solutions
  • HTTPS tooling (Let's Encrypt)

• Alerts

  • Provider uptime monitoring alerts
  • Deployment status alerts

  Remarks

• There are some limitations when automatically redeploying a container in terms of state transfer. It could be very useful for stateless applications like web app frontends. There may be some solutions to explore to counter the limitations.

• There are no systems like this currently available.

---

• Lack of technical knowledge. Akash currently has many technical walls. The SDL is complex to learn for new users. Docker is amazing but if you’re not familiar with it, it can be challenging to learn and to get started with. Crypto is easy once you get the hang of it, but it’s a very steep learning curve. As Alani Kuye always says “You can’t scale what you can’t simplify”. We intend to lower the cognitive load, thereby lowering the barrier to entry for both crypto natives and non crypto native users.

  Solutions

• Template marketplace

  • User generated and curated template marketplace
  • We have already made some progress in that solution, with our user accounts, users can already save templates. However, there’s no marketplace and we believe this will greatly reduce some of the friction for new users if they can rely on pre-made templates and solutions made from the community.

• SDL abstraction with SDL Builder baked in the deployment process

  • The SDL is great and flexible, but the users shouldn’t have to learn how it works to deploy simple or complex workloads on the network.

• Docker abstraction

  • We want to explore implementing an easy to use solution to deploy simple web apps or servers without needing any docker experience.

• Integrate token on-ramp solutions like Kado Money in Cloudmos

  • One of the solutions to reduce the friction to acquire AKT is to integrate solutions on ramp apps like Kado or Transak (used by Osmosis)

• Faucet (Free trial)

  • We plan on building an AuthZ manager to provide an interface to manage authorizations to deploy on other wallets, reducing the need for new users wanting to try out Akash to acquire tokens.

• Vercel like deployment experience

  • One click deploy to abstract the SDL process and bid selection

• Create simplified educational content for easier user onboarding with a focus on;

  • Deployments
  • Templates
  • Payments
  • And more

---

• Lack of business features. There are currently no platforms that offer features that would support usual business needs, like knowing how much you’ve spent over a period of time or managing team members. One of the biggest advantages of using Akash is the cost reduction and it’s a shame that businesses are not taking advantage of it.

  Solutions

• Billing module. Like all the other cloud providers out there, businesses/users need to get a better understanding of their costs and savings on cloud resources. Spending on cloud resources counts as a business expense and is technically deductible from your business income

  • Monthly expense reports
  • Forecasting
  • Export to excel or csv

• Team manager

  • With the AuthZ manager, it will enable a single wallet to authorize or revoke access to other team members to deploy without sharing a single private key.

---

• Analytics. Akash needs more analytics as stated in the sig-analytics meeting and we have the tech to do it.

  Solutions

• Implement tracking of all the stats mentioned in this pr https://github.com/akash-network/community/pull/67/files and add more if it’s needed.

• Add more functionality to our charts

  • Zoom in-out
  • Precision up to per block
  • Custom date range
  • Embedded widget for external websites

Overall, the proposed solutions aim to improve Akash's transparency, reliability, user-friendliness, and functionality to attract and retain more users.

Milestones and Projects

The problems and solutions mentioned above wouldn’t necessarily be implemented in the order that they’re mentioned. We plan to execute this plan in roughly 12 months. Here’s the roadmap of how we plan on building and releasing:

Q2 2023

• Add more analytics on providers, since data about provider resources and uptime status isn’t on chain, it’s important to start monitoring as soon as possible
• Merge Cloudmos Explorer with Cloudmos Deploy to provide a single platform with user accounts
  • A re-design of the application and user experience is also in the plans and we want to include Design DAO as part of the proposal to help do so.
• Organize and open source our private repositories that contain the indexer, explorer and deploy interfaces.
• Implement provider profiles and reputation system
• AuthZ manager to enable faucet management

Q3 2023

• Template marketplace where users can publish templates with guides
  • One click deploy existing applications
  • Publish your own templates
  • Rating system to easily find the best template for the job
• Improve the deployment experience by integrating our SDL builder
• Add more on-chain analytics based on the sig-analytics documents
• Live shell

Q4 2023

• Implement improved uptime solutions

  • Auto-redeploy when provider is down
  • Auto-refill leases when escrow is low
  • Auto-renegociation of leases

• Integrate Kado Money

• Implement billing module

  • Monthly expense reports
  • Forecasting
  • Export to excel or csv

Q1 2024

• Develop custom solutions to be published on the marketplace
• Improve UX of our tools based on community feedback
• Team manager
• Implement public API for all of our on-chain analytics

While we work on these projects, we will continuously support the community and adapt our tools to support new features released on the network such as GPUs. The exact roadmap will change and adapt to the network needs to maximize adoption.

We will provide regular updates of our progress in the respective special interest groups and working groups.

Use of funds

Most of the funds will be used to pay salaries, operating expenses, infrastructure, contracting design work with Design DAO, attending live events, marketing and miscellaneous expenses of running a business. We’re currently 2 full time software engineers. Design DAO were the ones who made our branding and helped in the past for various design activities.

While we do have plans to monetize our products in the future to ensure sustainable growth, our immediate priority is to increase the adoption of the Akash Network. To achieve this, we plan to make our products free and easily accessible. This will allow us to reach a wider user base and demonstrate the value of our products, which we believe will ultimately benefit both our users and the Akash ecosystem as a whole.

Conclusion

In conclusion, we are confident that our proposal will provide the Akash Network with the necessary tools and resources to achieve its goals. With our experience and expertise, we are uniquely positioned to deliver a high-quality solution that will not only improve the chances of success but also enhance the overall user experience. We believe in the vision of the Akash Network and are committed to supporting its growth and development. Thank you for your time and consideration.

This proposal will be on-chain on March 1st 2023 to give 1 week of discussions and feedback from the community.

---

Link to our previously rejected grant proposal:

https://forum.akash.network/t/akashlytics-developer-grant-v2/4513

[cloud-j-luna]

Thank you for this, as this proposal stands I have a couple of issues.

1. With the new open model for Akash Network I think such a large amount should be directed towards open tools and projects.

Our team’s deep understanding of the challenges facing the Akash Network, coupled with our development of critical tools and technologies for cloud parity, positions us perfectly to execute this proposal

To note that different teams, Overclock, Cloudmos, Praetor & Quasarch are all working towards cloud parity in what is the vision for the Akash Network.

2. Although you point out different problems and possible solutions, I truly believe $300k on a single (2 person) team wouldn't be able to address efficiently all of those. On top of that there are teams already working on those specific problems or are strategically better placed to solve them.

Auto redeploy when provider is down
The balancer could also auto-scale based on demand
Auto re-negotiation redeploy on providers when a better lease is available for the current AKT price, before a solution is implemented with the proposal Akash economics 2.0
Auto refill when deployment balance is low

This is part of our effort with the new under development client libraries.

HTTPS tooling (Let’s Encrypt)

I recently made a PR that adds support for any issuer (including Let's Encrypt) on Akash Providers.

We want to explore implementing an easy to use solution to deploy simple web apps or servers without needing any docker experience.

Spheron is doing this, from what I have seen, perfectly.

Trust. It’s difficult to trust providers without sufficient information of their operations and reputation.

Praetor has a very rich provider database that is currently integrated with by other systems, including the Akash Terraform Provider.

Create simplified educational content for easier user onboarding with a focus on;
Deployments
Templates
Payments
And more

Quasarch and Overclock Labs are currently revamping the new Doc 2.0 as part of the SIG Documentation.

3. Currently $300k amounts to more than 30% of the community pool which might put a strain on it if taken in 1 go. I do believe the funding is deserved although I would propose a phased funding based on major milestones.

4. As a community we should better organize as to not waste resources/effort/time implementing and solving the same problems. The beauty of a full open system is that we can achieve a great degree of efficiency across the ecosystem. We should also focus on strengthening the core product (Akash Network) and build features such as Metrics/Security/Observability. Third party tools, at this stage, should enhance the UX of the network and not add network features outside of the network as this will highly impact its openness. We should strive for an open framework for Akash Network interoperability.

Conclusion
I'm a big supporter of you and your work. I do share concerns on the efficiency, openness and cost of this proposal. As a team which 95% of its work is Akash Network, we at Quasarch, relate to your struggles. I'm open to discuss alternatives.

[alijnmerchant21]

I somewhat agree with the 3rd point made by @cloud-j-luna. Can we split the payment into 2 or 3 different proposals to ease pressure on the community pool and have more accountability? Just an opinion.

[baktun14]

Hey thanks for your feedback @cloud-j-luna. I believe most of your concerns revolve around 1. the amount being too high and 2. the overlapping efforts.

We're open to receiving that amount in several payments based on milestones. Based on the feedback received until now, I believe that we would need to change or remove some of these milestones in order to receive full support, so TBD. As for the amount, we strongly believe it is justified and that we need this at a minimum.

[cloud-j-luna]

Small correction. I don't think the amount is not justified, I just think its too much to take in one single instance and that it accounts for overlapping work. These points have already been discussed in meetings 👍🏻

[alijnmerchant21]

IMO this is a great proposal and should be funded. I totally support this. That said, I'm just curious, how will the AKT be distributed over the course of time? Will it be sold over 12 months in installments to ease sell pressure?

[baktun14]

Hey Ali, I appreciate your support. We would actually prefer to receive the payments in batches as we indeed have to sell a good portion of this and don't want to affect the market as much as possible.

[collinlowenburg]

This is a solid proposal from a solid team. The Cloudmos team was one of the first recipients of funding from the community pool, and they delivered a product that is popular and important to the community. The way I see it, this $300k of funding must be spent by the community on community-led projects, and this is one of the top projects in the community. It seems obvious to me that $100k should be a "yes". Praetor and Quasarch should perhaps also get $100-300k, if they were to justify it in a detailed proposal to the community.

I do think it's important that development aligns with the development work by Overclock Labs. Perhaps there is a need for better collaboration / alignment between teams. The roadmap of the development work by Cloudmos should be decided with input and influence from Overclock Labs (Greg, Adam, Boz, et al.) as well as Praetor and Quasarch.

I would vote yes on this proposal.

[baktun14]

Hey Colin! Good to see you and thank you for your support.

[anilmurty]

Amazing proposal - thanks for writing it up and sharing, Max. To echo what's been said here as well as during the steering committee discussion about this proposal - breaking this into smaller milestones and open sourcing the code (like everything else the community is building, is) is the main request. Thanks for all the work you guys do!

[baktun14]

Thanks Anil, yes as mentioned in the Q2 milestones, it will be open sourced.

Organize and open source our private repositories that contain the indexer, explorer and deploy interfaces.

[baktun14]

Akash Network - Cloudmos Funding Proposal

Summary

After receiving feedback on the proposal, we have decided to split it into two separate proposals. The first proposal will cover the period of Q1 to Q3 2023, while the second proposal will cover Q4 2023 to Q1 2024. For the first proposal, we are requesting 150k USD in $AKT, which is half of the original proposed amount. For the second proposal, it will be reviewed and submitted shortly before or after completing the first one.

Use of funds

Most of the funds will be used to pay salaries, operating expenses, infrastructure, contracting design work, attending live events, marketing and miscellaneous expenses of running a business. We’re currently 2 full time software engineers.

While we do have plans to monetize our products in the future to ensure sustainable growth, our immediate priority is to increase the adoption of the Akash Network. To achieve this, we plan to make our products free and easily accessible. This will allow us to reach a wider user base and demonstrate the value of our products, which we believe will ultimately benefit both our users and the Akash ecosystem as a whole.

Note: We will have to sell some tokens for our business expenses and we plan on selling these tokens with the least impact possible on the market. We're very aware of the liquidity issues AKT would face if we were to sell all the tokens at once in the open markets.

Achievements and Past Contributions

Over the past two years, our team has made significant contributions to the Akash Network, including the development of:

• Cloudmos Deploy, the number one open source deploy GUI with over 100 stars on github
  • https://github.com/maxmaxlabs/cloudmos-deploy
  • Now improved and in the browser under https://deploy.cloudmos.io/
• Cloudmos Explorer, the primary analytics hub for real-time Akash adoption metrics as well as being a fully functional and real time block explorer powered by our custom made indexer.
  • https://cloudmos.io/akash/dashboard
  • https://cloudmos.io/akash/blocks
  • https://cloudmos.io/akash/transactions
• Cloudmos Alerts, a customizable alerts system for deployment balance monitoring and other custom alerts
  • https://cloudmos.io/alerts
• SDL Builder, a simple and easy interface to create and edit custom SDL, making it easier to utilize more complex features such as persistent storage and lease ip.
  • https://cloudmos.io/sdl-builder
• Cloud price comparison tool for comparing Akash's cost savings vs. legacy platforms like AWS, GCP and Azure.
  • https://cloudmos.io/price-compare

Since January 2022, our efforts have successfully facilitated the onboarding of numerous new users onto the network, resulting in impressive outcomes such as the creation of 52.6k leases, with 30.8k of those leases being specifically deployed using Cloudmos Deploy, accounting for approximately 58% of all leases created on the Akash network.

Our team's deep understanding of the challenges facing the Akash Network, coupled with our development of critical tools and technologies for cloud parity, positions us perfectly to execute this proposal. We're confident that our past contributions and expertise makes us the ideal team to lead the way forward. With the rise of GPUs and AI, now is the perfect time to invest in the right tools to support future adoption. Our record speaks for itself.

Problems and Proposed Solutions

Here’s a list of issues we’ve identified and solutions we’re proposing to implement:

• Trust. It’s difficult to trust providers without sufficient information of their operations and reputation.

  Solutions

  • To be able to obtain cloud parity and to build trust towards developers, Akash needs to have active monitoring of providers and a platform to provide that information to users
  • A reputation system with provider reviews
  • Provider profiles
    • What is their hardware?
    • What Akash features do they support? (Persistent storage, IP leases, gpu, etc)
    • Logo
    • Company
    • What is your hardware best for? Gaming? Mining? Etc.
    • Terms of services and Service-Level agreements

  Remarks

  • With our custom built indexer and infrastructure, we already keep track of providers but only have minimal information. It will be easy for us to extend that functionality to track more information on the providers and provide an API for others to consume.
  • With our user accounts, we can make it possible for providers to create a custom profile and have that information displayed throughout the deployment process and be used to automate some processes based on their reputation. We can also make a user review process with those same user accounts.
  • With these systems in place, we believe that users deploying on the Akash providers will have a better sense of trust when choosing providers to run their workload and also other clients who want to use our API will benefit from this system.
  • There are no systems like this currently available.

• No SLA. There is no SLA or uptime system to make sure your deployments stay online 24/7. Currently, if your provider suddenly goes offline, your lease dies and the user has to make sure to keep track and re-deploy when that happens. Most users don’t want to take care of this themselves. Comparatively speaking, when people deploy on web2 platforms like DigitalOcean, AWS, GCP, and Azure, they are paying for the SLA, and the reassurance of stability. We intend to bring this feature to the Akash Network.

  Solutions

  • Implementing various automatisation tools using Authz
    • Auto redeploy when provider is down
      • The balancer could also auto-scale based on demand
    • Auto re-negotiation redeploy on providers when a better lease is available for the current AKT price, before a solution is implemented with the proposal Akash economics 2.0
    • Auto refill when deployment balance is low
  • Help build tools for the community to address common issues with deployments
    • Automated backup solutions
  • Alerts
    • Provider uptime monitoring alerts
    • Deployment status alerts

  Remarks

  • There are some limitations when automatically redeploying a container in terms of state transfer. It could be very useful for stateless applications like web app frontends. There may be some solutions to explore to counter the limitations.
  • There are no systems like this currently available.

• Lack of technical knowledge. Akash currently has many technical walls. The SDL is complex to learn for new users. Docker is amazing but if you’re not familiar with it, it can be challenging to learn and to get started with. Crypto is easy once you get the hang of it, but it’s a very steep learning curve. We intend to lower the cognitive load, thereby lowering the barrier to entry for both crypto natives and non crypto native users.

  Solutions

  • Template marketplace
    • User generated and curated template marketplace
    • We have already made some progress in that solution, with our user accounts, users can already save templates. However, there’s no marketplace and we believe this will greatly reduce some of the friction for new users if they can rely on pre-made templates and solutions made from the community.
  • SDL abstraction with SDL Builder baked in the deployment process
    • The SDL is great and flexible, but the users shouldn’t have to learn how it works to deploy simple or complex workloads on the network.
  • Docker abstraction
    • We want to explore implementing an easy to use solution to deploy simple web apps or servers without needing any docker experience.
  • Integrate token on-ramp solutions like Kado Money in Cloudmos
    • One of the solutions to reduce the friction to acquire AKT is to integrate solutions on ramp apps like Kado or Transak (used by Osmosis)
  • Faucet (Free trial)
    • We plan on building an AuthZ manager to provide an interface to manage authorizations to deploy on other wallets, reducing the need for new users wanting to try out Akash to acquire tokens.
  • Vercel like deployment experience
    • One click deploy to abstract the SDL process and bid selection
  • Create simplified educational content for easier user onboarding with a focus on;
    • Deployments
    • Templates
    • Payments
    • And more

• Lack of business features. There are currently no platforms that offer features that would support usual business needs, like knowing how much you’ve spent over a period of time or managing team members. One of the biggest advantages of using Akash is the cost reduction and it’s a shame that businesses are not taking advantage of it.

  Solutions

  • Billing module. Like all the other cloud providers out there, businesses/users need to get a better understanding of their costs and savings on cloud resources. Spending on cloud resources counts as a business expense and is technically deductible from your business income
    • Monthly expense reports
    • Forecasting
    • Export to excel or csv
  • Team manager
    • With the AuthZ manager, it will enable a single wallet to authorize or revoke access to other team members to deploy without sharing a single private key.

• Analytics. Akash needs more analytics as stated in the sig-analytics meeting and we have the tech to do it.

  Solutions

  • Implement tracking of all the stats mentioned in this pr https://github.com/akash-network/community/pull/67/files and add more if it’s needed.
  • Add more functionality to our charts
    • Zoom in-out
    • Precision up to per block
    • Custom date range
    • Embedded widget for external websites

Overall, the proposed solutions aim to improve Akash's transparency, reliability, user-friendliness, and functionality to attract and retain more users.

Milestones and Projects

The problems and solutions mentioned above wouldn’t necessarily be implemented in the order that they’re mentioned. We plan to execute this plan in roughly 16 months with this proposal focused on the next 8 months.

Here’s the roadmap of how we plan on building and releasing:

Q1 2023

• Migrate desktop app to browser ✅
• Redesign of Cloudmos Deploy front end ✅
• Live shell ✅
• Work in progress
  • New provider stats dashboard and monitoring https://deploy.cloudmos.io/providers
  • Started monitoring provider resource snapshots to have historical data on provider stats

Q2 2023

• Add more analytics on providers, since data about provider resources and uptime status isn’t on chain. This is vital.
  • The work to support historical data for providers is currently being worked on.
  • Implement work on deploy side with direction from sig-analytics
• Merge Cloudmos Explorer with Cloudmos Deploy to provide a single platform with user accounts
  • Improve Cloudmos Deploy application interfaces and user experience.
• Implement provider profiles and reputation system (Q2->Q3)
  • With Cloudmos user accounts, users will be able to create reviews for providers to comment on their experience and rate it with a star rating.
    • Improve our uptime tracking of providers and track further the interactions with the providers, like monitoring if send manifest fails, logs fail, etc.
    • Allow providers to reply to reviews
  • Provider profiles:
    • Build an interface for providers to edit their standardized attributes based on this PRD https://github.com/akash-network/community/tree/main/wg-provider-attributes
    • Extend our interfaces to display these attributes throughout the deployment process.
    • Improve the display of audited attributes
    • Extend provider profiles with custom fields with our database to improve the UX in Cloudmos
    • Improve tracking of supported features for providers like ip leases, persistent storage, etc.
    • Collaborate with Praetor to improve alerting to users when providers plan to have maintenance.
• Improve AuthZ manager
  • Cloudmos currently supports authorizing another address to spend on deployments on your behalf, but the user experience is not optimal.
  • Implement a user interface to manage your authorizations. List, add and revoke.
  • For users who are authorized to deploy, display the amount of AKT they’re authorized for in their dashboard and an easy list of addresses to select when selecting for the depositor when creating a deployment.
  • These feature will enable free trials or faucet management
  • AuthZ manager will enable a single wallet to authorize or revoke access to other team members to deploy without sharing a single private key.
• Integrate the SDL builder in the deployment process
  • Develop multiple versions of the SDL builder to support super simple and advanced use cases

Q3 2023

• Template marketplace where users can publish templates with guides.
  • One click deploy existing applications
  • Publish your own templates
  • Rating system to easily find the best template for the job
  • User public profiles
  • Curating process for template publishing
  • Analytics on the usage
  • Donation system for template creators
  • Reporting system for failing or illegal templates
• Work with sig-analytics to add more on-chain analytics to our indexer.
  • https://github.com/akash-network/community/blob/main/sig-analytics/prd.md
• Implement billing module
  • Monthly expense reports
    • Highlight cost saving compared to big cloud providers
  • Historical charts to monitor costs
• Open source Cloudmos Deploy and give access to our data through an API
  • This will allow all teams to leverage the data collected and used by the Cloudmos team.

---

Proposal 2

(This second proposal is subject to change with the feedback we get after completing the first proposal)

Q4 2023

• Implement improved uptime solutions
  • Auto-redeploy when provider is down
  • Auto-refill leases when escrow is low
  • Auto-renegociation of leases
• Integrate token on-ramp solutions like Kado Money
• Improve billing module
  • Forecasting
  • Export to excel, csv or PDF
  • Budgets & alerts
• Open source Cloudmos indexer and explorer

Q1 2024

• Develop custom “managed” solutions to be published on the marketplace
  • Improve UX of our tools based on community feedback
• Organization manager
  • Create and manage teams to share deployments, reports and everything related to the deployment environment.
• Implement public API for all of our on-chain analytics
  • Versioned and documented API for anyone who want to use the data to build custom dashboards or use in their applications

While we work on these projects, we will continuously support the community and adapt our tools to support new features released on the network such as GPUs. The exact roadmap will change and adapt to the network needs to maximize adoption.

Cloudmos will provide regular updates of our progress in the respective special interest groups and working groups. These solutions will continue to push the Akash Network forward with better user experience and increased functionality.

Conclusion

In conclusion, we are confident that our proposal will provide the Akash Network with the necessary tools and resources to achieve its goals. With our experience and expertise, we are uniquely positioned to deliver a high-quality solution that will not only improve the chances of success but also enhance the overall user experience. We believe in the vision of the Akash Network and are committed to supporting its growth and development. Thank you for your time and consideration.

Voting Outcomes

• If this proposal passes, X AKT will be transferred to Cloudmos to sponsor their work. Cloudmos pledges to use the funds to make a best effort attempt to complete the roadmap provided above.
• If this proposal is rejected, Cloudmos will have to find other funding sources and will need to drastically reduce the pace of development. We will also have to re-prioritize our focus as a business

Voting Choices

• If you vote yes you signal your desire to compensate Cloudmos via the Akash Network community pool in order to continue delivering value to the Akash network.
• If you vote no you signal your dissent against compensating Cloudmos via the Akash Network community pool.
• If you veto this proposal you deem it harmful to the network and wish to burn the proposer's AKT.
• If you abstain you signal your desire to contribute to quorum without a preference toward whether the proposal passes or fails.

[izrake]

Many things listed above are supported by Spheron now, and as we move forward, we will also bring many such things. If team cloudmos is interested, we can extend a lot of functionality of Spheron to them, and they don't have to build it anymore.

Building all these things takes a lot of time and resources and needs monetary support to achieve the same thing.

We have not yet raised a proposal for all the integration and support provided to the Akash ecosystem. We also might raise the proposal to fund us to keep building and onboarding new use cases over Akash.

Things that are already in Spheron and can be extended:

• Heroku/Vercel-like deployment experience
• Deployment Alerts
• HTTPS is enabled
• Custom Domain connections are enabled
• Health Check Alert
• Awesome!! Template Marketplace
• Docker & SDL abstraction
• Auto-Refill is automated with notifications
• Starter free plan (Auto provided to new users using faucet model)
• Deployment from different chains
• Educational and hackathon (ongoing)
• Role Based team management system
• SLA (We are working on it and most likely will be done within a few months down the line)
• Onramp (It's easy to add but legal we are figuring it out )
• Heroku-like CLI (is on the way and most likely will be live by q2)

As far as I can see, we have built most of the required things listed above with the very small AKT we initially received from the team ($1000)

Again, if cloudmos wants, we can collaborate and get the community grant to build everything in collab rather than in individuals.

After seeing the proposal, we think we are better placed to claim 150K to drive the adoption rather than building at the moment.

[baktun14]

Hi Prashant, thanks for your "feedback".

If team cloud moss is interested

First of all, the name is Cloudmos, not cloud moss..

We have not yet raised a proposal for all the integration and support provided to the Akash ecosystem. We also might raise the proposal to fund us to keep building and onboarding new use cases over Akash.

Akash is permissionless, if you think you deserve to get funded by the community pool for your efforts, then simply put up a proposal and we will happily support you if the proposal makes sense.

After seeing the proposal, we think we are better placed to claim 150K to drive the adoption rather than building at the moment.

I don't think this is how we're supposed to support each other as builders on the Akash Network. There will always be overlap in features implemented to drive adoption, but as long as the adoption hasn't reached a critical point, there's no point on favoring a product over another.

[izrake]

Apologies, it was spelling corrector which added wrong name

[izrake]

As mentioned above, we would love to support you wherever possible. Also, there are a few things that we as a community should also drive the collaborations for driving the adoption.
My ask is not built, my ask is if we can collab and help you to build the product faster by extending our functionality which is composable that will not just save time but also money. We can use the same cost to drive the adoption than just building the product.

And your proposal completely makes sense to me because we have spent more than that to build what we have built so far, and I can completely understand without monetary support it won't be possible to build the features that are supposed to be built.

[alijnmerchant21]

Thanks, @baktun14 for putting together the revised version of the proposal. There could definately some collab done with Overclock Labs & Spheron. That said the comment made by @izrake just feels a bit harsh. I suggest, if you'd like 150k from community pool, please put a seperate proposal.

[baktun14]

Hey Ali, thanks for your support and I agree with you on your suggestion.

[izrake]

Hey, @alijnmerchant21, I did not intend to make it look harsh, just put the things forward that we have done so far and wanted to extend the collaboration.

Again huge respect for @baktun14 and the team for building cloudmos.

[tacolopo]

Hey @baktun14, Taco from Moultrie here. I support you guys as you and Praetor have obviously spearheaded Akash community adoption. It would be really cool to get a budget breakdown if you have it to show how the tokens will be offloaded, whether it's scheduled or not, etc. I like the rest of the prop!

[baktun14]

Hey Taco, thanks for your support! We will most likely receive the whole grant in 2 payments,

[tacolopo]

Hey, sorry my question probably wasn't clear. I meant how do you plan to sell them, it's obviously a lot of tokens that would hit the market.

[baktun14]

With the least impact on the market as possible.

[figurestudios]

From my reply on the original post where now some numbers have changed but I still hold my opinion that the proposal is asking for too much:

$300k is a lot and I think it’d be better spent elsewhere. Cloudmos - while a great project - has received plenty of grants and rewards already, and I believe that the community fund should be utilized for other projects instead. Furthermore, Cloudmos recently introduced a 3% fee on all deployments meaning that a business strategy is already implemented. Maybe the strategy is not successful yet, but as this post shows, there is a big userbase that is growing with the ecosystem.

[CaptainSplince]

Hey Max! Thanks for the proposal and all the hard work you put into Cloudmos. True GOAT.

Maybe not feedback on this proposal per se, but just a general question.

Have you thought about creating a tiered service? Meaning a free version and a paid version of Cloudmos? That way you wouldn't have to rely on grants, community pool resources alone for supporting Cloudmos?

Thanks!

[baktun14]

Hey Adam, thanks for the kind words!

Yes, we do have plans to monetize our products in the future, with a tiered service and other ways.

We definitely don't want to be entirely reliant on the community pool or grants in the future, but to get to the point where Akash is capable of hitting critical mass adoption, we need help from the community.

I hope this makes sense.

[bmenzalji]

Hey Max,

This is a great proposal overall. The following are opinions/thoughts and not related to the steering committee as I'm not on it.

1. I'm not dismissing the cost of deliverables for this request, as it is quite a lot to deliver, but I'd love to better understand this in quarterly increments to reduce community fund risks.

• Could you outline what your path is for sustainability and what your business model will be?
• Are there pro-forma models or projections you could share with us that would be help the community gain confidence in your plan?
• If the community is funding the development of Cloudmos, which benefits the community, will Cloudmos also be charging the community at some point or will Cloudmos remain free to use for the community? If there are gated features for use in the future, will those be funded by the community funds as well? Or will those monetized features fund back the community fund?

Having been in startups over 15-years, both as an entrepreneur, and investor, it's a plan to fund product development for enhancements, and features. I'd point to funding requests to any builder with these statements; I dont have a clear understanding of what impact these features lead to in terms of monetization, growth, and increased adoption. Have you conducted product surveys for the market/community? Could product development be developed in the open, ie, we conducted a survey, 600 people responded saying that they want X for Y. We are building X, it's going to cost $16K (200 hours at $80/hr).

2. One thing that's missing here is the total hours per feature, and how you arrived at $150K. For example, for Q2 items, can each item be broken down in how many hours it will take it scope, build, test, what the rate of development is, to measure and account for the request? Echoing the above example, here's another; we are pursuing A feature for this market, it will take 200 hours at $100/hr, and we project this costing $20,000, and will be delivered by this date.

3. General opinion - I don't think community should be funding multi-quarter plans as the community fund is geared for grants, and not setup as an accelerator. FWIW, I'm happy to work with you on different monetization plans. This is for a few reasons:

• Macro conditions, both economic and state-related, may impact the market to reduce the value of tokens significantly. This will then position Cloudmos to request more funding given lower rates. This leads to risks for community fund overall, and all builders and future initiatives
• Funding multi-quarterly efforts isn't a good idea; it should be based on milestones. Would you be open to detailing the cost of what Q2 deliverables are, what they cost, the hours for each to understand how the value was arrived at, etc?

Could you outline which markets you are pursuing, monetization strategies for those markets, models for business sustainability? Will there be a plan for pursuing a venture-backed effort to scale efforts post this round? If so, what is it?

[baktun14]

Hey Boz, I will take the time to answer your questions tomorrow. However, I would've appreciated if you would've posted this before the proposal is on chain. You had plenty of time to do so.

[baktun14]

Could you outline what your path is for sustainability and what your business model will be?
Are there pro-forma models or projections you could share with us that would be help the community gain confidence in your plan?
If the community is funding the development of Cloudmos, which benefits the community, will Cloudmos also be charging the community at some point or will Cloudmos remain free to use for the community? If there are gated features for use in the future, will those be funded by the community funds as well? Or will those monetized features fund back the community fund?

We currently already have the infrastructure to support tiered service and this is one of the path that we will pursue in the future to sustain our activities. There will always be a free tier for community members and we're exploring ways to reward early users so they keep the benefits while we gradually switch to monetize some of the more advanced features. Here's a live example of what we have for our other products: https://cloudmos.io/pricing

As for the projections, I could give some fabricated numbers, but given the current unique tech stack, value proposition and situation Akash is in currently, simply seeing the number of AKT spent and active leases growing on a YOY or MOM basis would be a huge win for the community and ecosystem in general. As you probably know very well, right now the adoption has been pretty flat for the past year and a half and our proposal's entire focus is to attack this problem. https://cloudmos.io/graph/active-deployment

Having been in startups over 15-years, both as an entrepreneur, and investor, it's a plan to fund product development for enhancements, and features. I'd point to funding requests to any builder with these statements; I dont have a clear understanding of what impact these features lead to in terms of monetization, growth, and increased adoption. Have you conducted product surveys for the market/community? Could product development be developed in the open, ie, we conducted a survey, 600 people responded saying that they want X for Y. We are building X, it's going to cost $16K (200 hours at $80/hr).

Like I mentioned in the steering committee meeting, I've been on the forefront of the user adoption for the past 2 years, talking with new users and developers, helping them understand the concepts of the Akash Network, guiding them when they face issues, using our products and Akash very extensively ourselves, interacting with all the community members and with all of the experiences gathered, this is the detailed plan we came up with.

One thing that's missing here is the total hours per feature, and how you arrived at $150K.

As the seasoned entrepreneur and investor that you are, you probably know that 150k doesn't get very far in product development, especially in the very niche and techy blockchain industry. As for the amount we're asking, it's a very simple math. Compared to most of the partners, we work on these projects full time(and more) and we simply calculated our yearly salary + cost of operating our business. To be frank, for what we've built so far and what we promise on delivering, 150k for 9 months of work and R&D is a bargain.

I don't think community should be funding multi-quarter plans as the community fund is geared for grants, and not setup as an accelerator.

I respect your opinion, however, as I mentioned in the steering committee meeting, I don't think it's very efficient to "un-bundle" the current proposal into smaller ones and to compare with what the Praetor team has proposed, they've been approved to work on their proposal which spans 2 quarters.

Could you outline which markets you are pursuing, monetization strategies for those markets, models for business sustainability?

We're going to pursue first crypto native developers in the cosmos ecosystem, then crypto-wide and then non-crypto developers in various ecosystems. The monetization strategy and business model stays the same, pay per usage and paid tiers with free tier.

Will there be a plan for pursuing a venture-backed effort to scale efforts post this round?

Not at the moment, but I don't discard this optionality.

[bmenzalji]

I would love to see the gov proposal updated, along with the request based on the steering committees guidance, and have Max/Cloudmos lead the way for all projects, as it has done so historically, in establishing well defined precedents, to continue its efforts in growing the network.

The gov proposal, as is, to me, doesn't make sense after today's discussion. My no vote is not a representation of no against Cloudmos/Max, but how the gov proposal is structured based on today's call and direction.

I'm in support of Max/Cloudmos/his team's contribution and leadership to Akash's community and look forward to an update and discussion here.

[baktun14]

I understand your position. However, I stand by what I said in the other comment, it's very disrespectful to us to give all of this feedback a few hours after the proposal is on chain knowing this discussion has been on for over a month.

[bmenzalji]

I sincerely apologize, and will do better to respond sooner. It was by no means intentional.

This highlights more requirements to detail standards for funding requests, so to avoid these things. Once again, sincere apologies on my end Max.

[bmenzalji]

Following up, will this proposal be updated? Specifically, divided into smaller project-based deliverables and follow the advice of steering committees feedback from our conversation?

Will you be open to taking up Adam B's invite to constructively work on a JWT PRD, or other things that Cloudmos is perfectly positioned to solve for, and deliver on those features, like open-sourcing Cloudmos' indexer? We'd like work together by following the processes we're standardizing.