Skip to content

Commit

Permalink
Create meeting notes for Sig-Clients #12 (#468)
Browse files Browse the repository at this point in the history
create meeting notes for Sig-lients

Signed-off-by: George Appiah <[email protected]>
  • Loading branch information
iamGeorgePro authored Jan 28, 2024
1 parent 0c8be66 commit 8c96bd5
Showing 1 changed file with 157 additions and 0 deletions.
157 changes: 157 additions & 0 deletions sig-clients/meetings/012-2024-01-17.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,157 @@
# Akash Network - Clients Special Interest Group (SIG) - Meeting #12

## Agenda
- Quick follow up from sig-clients monthly meeting #11.
- Artur Troian update and discussions on Akash API.
- Update on specific Akash clients from representatives present at the meeting.

## Meeting Details

- Date: Wednesday, January 17th, 2024
- Time: 08:30 AM PT (Pacific Time)
- [Recording]()
- [Transcript](#transcript)

## Participants
- Alani Kuye
- Anil Murty
- Artur Troian
- B S
- Cheng Wang
- Deval Patel
- Greg Osuri
- Jigar Patel
- Joao Luna
- Julia Holden
- Max
- Prashant Maurya
- Rodrigo Rochin
- Scott Carruthers
- Taiwo Omoyeni
- Tyler Wright

## Meetings notes
#### Tyler Wright:
- Emphasized the goal of alignment among teams building on Akash, discussing tools and solutions for common problems.
- Acknowledged the decision to move the meeting to an earlier time to allow broader participation.
- Mentioned discussions with the Spheron team and the decision to adjust the meeting time.
- The objective is to facilitate participation from different time zones.
- Highlighted updates from the last meeting, including progress reports from teams such as Spheron, Cloudmos, and others.
- Discussed Cloudmos' open-source efforts, particularly the Cloudmos API, and its adoption by teams like Praetor.
- Shared the project board link for Cloudmos' open-source efforts in the chat for reference.
- Teased upcoming discussions, including Artur Troian's insights on Akash API and Joseph's involvement in supporting Akash JS.
- Spheron is planning to share statistics over the last 17 days of January, highlighting their recent work and active leases.
- Tyler emphasized the importance of understanding how people are utilizing Spheron built on top of Akash.
- Commitment to making these statistics available to the community.
- Mentioned a conversation about NodeOps seeking support from Cloudmos.
- The support is specifically related to deployment, not indexing.
- Expressing the hope that NodeOps could join future calls to discuss their needs and receive assistance.

### Max's Updates on Cloudmos:
- Max shared progress updates from the Cosmos team, focusing on rebranding Cloudmos into the Akash console.
- Announced the completion of rebranding the analytics side, with the launch of the new analytics app imminent.
- Work is underway to make the API more accessible and well-documented to facilitate usage by other teams, with a release planned soon.
- Addressing bugs and issues related to the customers kit, with support added for additional wallets like Leap, Cosmostation, and Kepler mobile.
- Max highlighted ongoing efforts to enhance the user experience for both new and existing users on Akash, with a focus on mainstream adoption.
- Tyler commended Max and the Cloudmos team for their proactive updates, which are regularly shared on the [public-facing and open-source project board](https://github.com/orgs/akash-network/projects/5).
### Discussion on Cloudmos API:
- Tyler inquired about Praetor team's experience with Cloudmos API, seeking confirmation that they obtained everything they needed.
- Jigar Patel from the Praetor team confirmed that they received all the required support from Cloudmos, enabling them to successfully launch the lease transport quickly.
- Expressed gratitude to Max and the Cloudmos team for their assistance.
- Rodrigo Rochin sought clarification from Max regarding the upcoming API key feature, inquiring about potential limits and whether it would be free for users.
- Max and Greg Osuri clarified that while there might be some rate limiting, the use of the API will be free for all users.
- Additionally, the possibility of running one's own API server using the open-source suite was mentioned.
- Max acknowledged the need for improved documentation, especially for users interested in running the services themselves.
- He expressed a willingness to contribute more effort to documentation based on community needs.
### Update from Joao Luna on Client Libraries and Quasarch Platform:
- Luna shared that the client libraries are close to launching and will be open-sourced soon.
- Mentioned that certain logic within the libraries was initially coupled to their platform but is now being made open-source ready.
- The client libraries will be a part of their platform, which is closed source, but Luna expressed the intention to open-source the client libraries for community use.
- Luna highlighted that the client libraries have undergone intense testing and form a core component of their platform.
The libraries, responsible for various functionalities, have shown stability, with a focus on logging-related testing remaining.
#### Quasarch Platform Overview:
- Luna provided a brief overview of the Quasarch platform, targeting web2 developers familiar with services like Google Cloud Platform and AWS.
- Described the platform as a decentralized cloud platform, with the first protocol integration into Akash.
- Luna mentioned the potential for expanding services beyond compute to include storage, identity, and more.
#### Self-Custodial Experience and Crypto Abstraction:
- Responding to Greg Osuri's question, Luna clarified that the user experience is self-custodial, and the platform handles all crypto-related complexities in the backend.
- Emphasized the goal of abstracting crypto complexities for users, providing the benefits of decentralization without burdening users with crypto intricacies.
- Greg Osuri expressed fascination with the platform and suggested the possibility of a more private session to delve deeper into its details.
- Luna acknowledged that while the discussion around funding and open-sourcing had been ongoing, it wasn't a top priority.
- However, they now plan to open-source the client libraries to give back to the community.
- Greg advised Luna on the importance of open-sourcing the libraries to receive valuable feedback before seeking funding.
- Greg emphasized the challenge of assessing the library's quality without the ability to use it and suggested building credibility through open sourcing.
- Luna inquired about a repo called "node API" in the Akash Network organization and asked if it might be a tentative client library.
- Greg was not familiar with the repo but suggested following up offline or potentially involving Artur for more insights.

### Discussion on AKT Requirement for Deployments
- Tyler welcomed Prashant from the Spheron team and highlighted the issue they encountered regarding the AKT required for each deployment.
- Prashant provided a high-level overview of the issue faced by Spheron as they scaled their activities on the network.
- Noted that with around 550 active providers, they faced challenges related to liquidity and locking up funds for creating leases.
- Shared that Spheron is working on launching providers with zero AKT as a solution to mitigate the problem.
- Plans to announce and test this approach, considering its potential effectiveness for addressing the liquidity and scalability issues.
#### Greg Osuri's Response and Offer of Support
- Greg acknowledged the challenges faced by Spheron and suggested a stopgap solution, offering to provide some AKT as a loan from the core team.
- Raised the idea of reconsidering the five AKT parameter, suggesting a potential reduction during a network upgrade.
- Prashant acknowledged the offer of support from the core team and reiterated the challenge faced by projects in terms of liquidity.
- Discussed the impact on projects as they drive adoption, emphasizing the need for a solution to avoid potential problems for projects.

#### Artur Troian's Clarification:
- Artur differentiated between two types of deposits: deployment deposit and big deposit, confirming the focus on the deployment deposit.
- Explained that the value of the deployment deposit is under review internally to determine the optimal parameter.
- Greg proposed initiating a governance proposal to change the deployment deposit parameter to one AKT, considering the current value of AKT.
- Prashant questioned the necessity of the deposit, prompting Artur to suggest moving the discussion to GitHub for further elaboration.
- Tyler directed Prashant to create a GitHub discussion specifying the deployment deposit issue for community involvement.
- Encouraged prompt action from Prashant to initiate the discussion on GitHub
- Prashant committed to initiating the GitHub discussion promptly and informed the community within the week.

### Additional Discussion on Deployment Deposit:
- Greg Osuri recalled that the deposit was initially required because the escrow needed some AKT to get started, preventing misuse.
- Artur clarified two reasons for the deposit:
- Preventing providers from creating deployments without a deposit, exhausting resources quickly.
- Ensuring providers remain active; without a deposit, providers might become inactive.
- Max suggested using USDT for the deposit, and Artur acknowledged the potential, but mentioned concerns about the availability of providers accepting USDT
- Prashant explained that Spheron had its own providers to address bidding cost concerns and liquidity challenges associated with using USDT.
- Prashant proposed reducing the deposit to zero, arguing that maintaining liquidity and capital for USDT could be burdensome for clients.
- Artur clarified that setting the deposit to zero would break the deployment and bid processes,
- Emphasizing the necessity of a deposit for the SQL account to work.
- Artur suggested lowering the deposit rather than setting it to zero, acknowledging the need for a deposit but discussing the value.
### Artur's Presentation on Akash API
- Artur is working on the Akash API and shared insights on solving issues related to changing API versions.
- The challenge discussed was the lack of visibility on the client side regarding the supported Akash API version on the RPC node.
- Artur proposed extending the RPC endpoint to serve version information. This feature will be available in the upcoming partial version.
- There will be proper examples and guidelines for implementing this feature in different languages.
- The clients' discovery checks the supported Akash API version and generates clients accordingly.
- Documentation for providers, including information on types and API requests, is being generated for better human readability.
- Feature Discovery will be available for both provider and node sides.
- Tyler encouraged Artur to initiate GitHub discussions and share information with the community.

### Additional Points from Artur on Akash API
- The primary goal of the Akash API is to simplify documentation and enhance external user access to products.
- Aim to separate it completely from the Converse, considering them as distinct entities with different purposes.
- Using protobuf for types description from providers like jpcloud to streamline generation.
- Instead of generating protobuf every time, supply already generated protobuf things, ensuring compatibility.
- Focus on making it easy for developers to start interacting with the blockchain.
- The Akash API is still in progress, with upcoming additions to the [repository]( https://github.com/akash-network/akash-api).
- Plans to release it as a mainstream version in the next few months for broader implementation and understanding.
### Discussion on Moderation API and CRDs
- Deval Patel raises a question about whether the Moderation API, which is being developed to expose the CRD (Custom Resource Definition) for white listing and block listing, should be exposed through the Akash API or the Provider Service API.
- Artur suggests keeping it in the provider repository for now.
- Artur clarifies that the CRD itself is not an API but rather a behavioral description of how certain things operate within Kubernetes.
- It is decided to keep the CRD inside the provider repository for the time being.
- Artur informs Deval that the PR review for this matter will be held until some releases related to feature discovery and deploy operator are completed, as these changes affect the deployment process.
- Deval explains that the reason for exposing the API through Provider Services is to provide a UI where users can view the list of filters and update them.
### Closing remarks
- Tyler highlights Luna's upcoming discussion on the Provider schema for next week's meeting.
- Tyler encourages participants to engage in GitHub discussions related to Provider schema and upgrades.
- Prashant's question on provider upgrades to be addressed as a topic in the next meeting.
- Alani Kuye expresses interest in Luna's discussion on the provider schema for its relevance to provider reviews.
### Action Items
- Tyler will ensure that information regarding the upcoming API improvements and documentation release is communicated to the broader community.
- Tyler will ensure the sharing of Spheron's network statistics in the SIG Clients channel for community awareness.
- Tyler will follow up offline, potentially involving Artur, to provide insights into the "node API" repo.
- The core team will work with Spheron to provide some AKT as a loan to address the immediate liquidity challenge.
- The possibility of reconsidering the five AKT parameter will be explored, with potential discussions on adjustments during a network upgrade.
- Prashant will create a GitHub discussion to address the deployment deposit value issue
- Continue development on Akash API; release mainstream version in the next few months.
- Joao Luna to provide Alani Kuye with details on the provider schema offline

0 comments on commit 8c96bd5

Please sign in to comment.