Temperature Check: Building a Talent Hub for Cosmos

Conversation AADAO
1

Context:

It’s widely recognized in the Cosmos Ecosystem that there are certain coordination challenges. These are inherently linked to the decentralized nature of the system, which is a feature, not a flaw. However, these issues should be addressed to alleviate the problems they create, potentially hindering adoption. One such challenge concerns the absence of a centralized entity to effectively guide and unite talent within the ecosystem.

Analysis:

To further analyse the situation, we also found that there was an enormous reliance on trust assumptions regarding credibility of actors. More often than not, subjective judgement prevails instead of quantitative and qualitative analysis. If left unaddressed, this issue will result in ‘cartelization’ and reputation systems that prioritize connections over merit-based and accountable approaches as the system scales.

Secondly, we have identified an overemphasis on development, which unintentionally discourages the involvement of other skill sets, such as marketing, business development, and traditional finance. We have also observed a significant growth in the developer cohort, leading to increased specialization. To prevent fragmentation, a clear categorization of sub-specialties is required.

Additionally, the absence of accountability threatens the long-term sustainability of the workforce and its capacity to attract top talent, favoring historical contributors with potentially outdated merit and past reputations, some of whom have not contributed for an extended period or have been involved in public controversies.

Beyond these obstacles, we believe there is an even more significant challenge to overcome: the difficulty in recruiting independently. We have determined that this is a result of the multiple tasks assigned to the InterChain Foundation (ICF), which has historically coordinated recruitment efforts. This system faces communication overhead as it scales, and we recommend a collaborative public-good initiative between the Hub and the ICF to address this issue. This system should offer a trust-less platform that enables confidential communication between recruiters and candidates, with a spam-protected system that can scale effectively.

To summarize, here are he problems we think should be addressed:

  • the lack of a one-stop-shop to list all talents in Cosmos.
  • the reliance on a fragmented set of people (the historical leaders).
  • a subjective reputation based system for recruitment.
  • the absence of non-developer talent recognition in the ecosystem.
  • the need to categorize developer cohorts by their specialties.
  • an unworthy system favoring historical actors without accountability.
  • the difficulty to scale communications between recruiters and candidates.

Proposition:

Before going any further, we would like to emphasize that this is just the result of our internal brainstorming within the PRO Delegators’ team. We are eager to gather community feedback and improve on our ideas.

To present a detailed plan for the project, we suggest proceeding in a series of sequential steps:

  1. Community debate: First we would like to query the general sentiment see if we are in the right direction. We provide our initial design right below and we welcome community feedback on improvements and potential technical challenges this could pose for the specifications & development phases.

  2. Specifications: We think this program should follow a regular process, which counts for a thorough governance debate right here in the forum, followed by a specification phase similar to the CHIPs process. The goal is to clearly define the technicalities to define an estimated cost of operation to build it. This specification phase is essential to define Key Performance Indicators (KPIs).

  3. Funding: Due to the public good nature that extends way beyond the Cosmos Hub into the entire Cosmos Ecosystem, this should be a joint-funded program which financial details should be debated between the ICF’s @crainbf and @Youssef from the AADAO.

  4. Tokenomics: To our humble opinion, this system does not need a separate token. The community is invited to share their feedback on this if they have relevant alternate options. The close alignment to the Hub’s neutrality is perfectly suited for this public-good task. Our initial design has not accounted for a specific governance module inside the chain itself, therefore depending from the Hub’s governance. Of course this could change depending on community feedback.

  5. Building: A competent team of developers should be tasked to scaffold the chain itself using the Cosmos SDK and tailor the specific modules required for the operations defined in the specification phase. A second team should work in parallel to build the application front-end itself. It seems evident that the two teams should have direct communication between the whole process but should have separate KPIs (Key Performance Indicators) to release their respective funding. This further improve resilience and isolate the risks to avoid past mistakes.

  6. Infrastructure: The core idea resides on a trustless execution, therefore the Hub should be the provider chain for the security, this seems like a no-brainer to us. Due to the public-good nature of this system, it should consider a Partial-Set-Security (PSS) deployment and the “top-N” model seems the most appropriate to limit the infrastructure costs. The minimum 50% top-N should be more than enough considering the low profitability margin of public-goods operations. We also propose that gas fees collected should be equally distributed to the participating validators, not only the bloc proposers to better balance the revenue distribution.

Prototype:

To clarify our proposal, we have outlined our thoughts on the desired architecture of the chain, including the modules and sub-categories we believe should be considered. We remain open to community feedback on this matter.

Talent Hub
Talent Hub1920×1200 157 KB

The core features we envision to define the specifications:

  • ONE-STOP-SHOP (HR meets talents & developers in the Cosmos)
  • FOSTER BUSINESS IN THE AEZ (Removes all the friction, both from the recruiter and the recruitee sides, emoving trust and adding on-chain accountability)
  • AUTHENTIFIED ACCOUNT OWNERSHIP (registering as a user on the platform requires a one-time stATOM deposit, refunded after 21d on account’s closure. Users can connect to their web2 accounts to prove ownership on-chain)
  • EASY INTEGRATION WITH WEB2 TRUSTED SOURCES (bring your achievements, badges etc… on-chain, validators connect via API & websocket to verify authenticity)
  • PROVABLE USER CONTRIBUTIONS (validators commit stake and the block producer will be slashed if relevant misbehave is brought to governance)
  • SPAM-FREE MESSAGING SERVICE (Each account can define a minimum fee to receive messages, natively preventing spam)
  • AUCTION SYSTEM FOR TALENT QUERY & CONTACT (the recruiter defines its criterias, the Dapp calculates the relative cost to reach those users. The cost is transparent and trustless. Once deposited, the app casts the relevant transactions containing the encrypted message sent to the users. Opening the message sends a proof to the recruiter)
  • DENTRALIZED PAYCHECK SERVICE (allowing KPIs release & vested payments in any whitelisted token thanks to the fee abstraction module)

Functionality Overview:

For those who are less familiar with the Cosmos SDK and blockchain architecture we want to share a high-level overview of the application that we envision from the users’ and validators prospective.

  • Candidates: A unified platform for job seekers to submit applications to a transparent talent ledger. To proceed, create an account and make a sizable minimum deposit to prevent spam and misconduct. We suggest using stATOM for compounding staking rewards over time, which will be returned to you (x) days after closing your account, provided you haven’t been flagged on-chain. Following deposit, link your accounts on trusted web2 platforms, such as GitHub, Node-Guadians, LinkedIn, etc. You can choose which data you want to be attested on-chain, while your public profiles remain off-chain. Misconduct or duplicate claims will result in deposit slashing on both accounts. Additionally, select keywords from a list to describe your skills and set hourly salary, availability, notification preferences, and the fee for contacting you.

  • Recruiters & HR managers: They also need to set an account and deposit a refundable fee to discourage spam and inappropriate behavior. To start a recruitment campaign, users define candidate criteria, and the app identifies eligible users along with their connection fees (with higher fees for highly skilled users, attracting serious recruiters). After choosing candidates and campaign duration, the app calculates the total cost and directs users to send the escrow contract amount on the bank module for later execution. Eligible users receive a private email notification to connect, prompting them to accept or reject the connection via the app. Any answer posted on-chain releases the full fee from escrow to the user’s account. If no response is given by the campaign end, the fee is returned to the recruiter. If approved on-chain, a secure, on-chain, end-to-end encrypted message channel is established between the candidate and recruiter, open for the campaign duration and closing automatically if not extended by both parties. Each side can also cast a transaction to close the channel irrevocably.

  • Validators: Confidential information is stored in a web2 application database with a restricted API, accessible only to active validators. These validators collaborate to verify and submit on-chain attestations concerning the validity of users’ achievements, while keeping web2 profiles private. Over time, validators can broaden the scope of private data attestations, providing additional filtering options for recruiters.

  • Attestors: Additionally, reputable developers and talented individuals can participate in decentralized KPI reviews for open-source projects, pledging their deposit and reputation. Their votes, cast on-chain, determine KPI-based payments, creating a decentralized market for responsible and credible reviewers with verifiable evidence of their skills and accomplishments.

F.A.Q.

Question: why not simply a website?
Answer: as we highlighted in our analysis, there is a huge reliance on trust assumptions and a lack of accountability today. Having on-chain attestation is a perfect solution to these problems. The verification is performed by (x) independent validators risking ATOM slashing if they misbehave. Another crucial problem is the reliance on a few individuals to connect projects and developers with a communication overhead issue preventing scaling. A blockchain marketplace with proper financial incentive and spam deterring features offer near infinite scaling with no third party reliance. Finally, as the system involves collateral deposits and payment incentives, a blockchain offers unparalleled security and transparency to execute these critical pieces.

Question: private data and blockchain, isn’t that conflicting ?
Answer: Some data has to be publicly viewable to remove trust assumptions and false claims. Nonetheless, anonymity preservation is key to a worthy on-chain system. To prevent user identification recruiters will have limited numbers of searches to the website. We also want to ensure that the engine will prevent from performing “narrow searches” only resulting in a few candidates, which would allow them to be identified more easily.

Question: how can this system accrue value ?
Answer: it is not designed to be profitable, we designed it with a public-good vision (community feedback can demonstrate disagreement and propose changes to the tokenomics). We expected to charge a cost-based gas fee to cover for validator execution. As we expect to run on a minimal setup, we estimate that overall gas cost should still be affordable for users (few cents).

Question: how does it benefit ATOM holders ?
Answer: firstly, some supply will be removed from circulation to provide collateral and prevent spam. We also propose to use @Stride stATOM to increase the overall security with this capital. A more indirect effect is that the overall constraint the current system poses to the general ecosystem growth shall benefit to everyone’s experience. Less friction in the recruitment system and a more equitable access the workforce participation can only benefit every cosmonaut. Finally, this system is designed to run autonomously and scale, ultimately doing a better job than creating a specific DAO with individuals and monthly salaries to pay for their contributions.

Closing thoughts:

To wrap up, we would like to express our gratitude to everyone taking part in this conversation. We welcome all viewpoints and invite you to share them here. Kindly remember that a constructive dialogue hinges on respectful behavior among participants. Please make an effort to maintain politeness and open-mindedness towards everyone’s contributions.

Thank you for taking the time to read this, and we look forward to collaborating on bringing this concept to fruition. This journey may be long, but we are honored to be the ones taking the first step today.
pro-delegators-sign

10 Likes
2

I like the concept !

What would be the main challenge to implement it and is there any downside in your opinion?

Also, do we have a way to quantify or “show” what’s the current/potential demand in terms or applicants, jobs offering… etc within the AEZ ? Showing data could help to decide.

I like the neutral and non profitable aspect of this proposal. Just a tool, not another punzi. Looking forward to the discussion

Thank you Govmos for you dedication to the Cosmos community :slightly_smiling_face:

2 Likes
3

We think the ecosystem as whole should approach this topic as a necessary public-good funding. The key argument we shared relates to the fact that there will be an inevitable bottleneck in the future if this situation is not addressed preemptively. We are currently relying on foundations and DAOs which won’t be able to follow the demand as it scales. Moreover, creating a decentralized platform to take over the charge will require extensive work to be designed, specified, built, tested, and lastly implemented.

Due to the public nature of the business and its relatively low profit margin to operate correctly, we identified this as a perfect match for a joint funding from the two sources currently operating this human ressource coordination, namely the AADAO and the ICF.

As we previously described, building public infrastructure takes time, more than building in a centralized manner. This is why we think it is important to kickstart the first steps long before the actual bottleneck shows up. To this day, the plan is initiate community discussions, ideation and brainstorming. The goal should be to collectively declare our willingness to build such infrastructure, define the key features and components needed to achieve them. The next stage will be more technical as it involves defining clear specifications and cost estimations.

To answer your question more directly, the biggest challenge lies ahead of the specification and funding phases. We’re not yet there as this post only clears the path for community discussions. Regarding the downside, we only see the community spending required to fund the actual building. The community will have to balance the necessity-cost ratio.

4

Bringing a talent portal onchain is definitely an interesting usecase. Onchain attestations could solve some of the assumptions and trust involved with recruitment today - but I’m still unsure how we can utilize this for qualitative evaluations/data.

Regardless, agree with @Govmos that such a project will probably (esp at this stage) be a public goods type project. We will probably need a few trailblazers to innovate, experiment and then quash traditional recruitment portals.

If any team is looking to build on this idea, do give us at @ATOMAcceleratorDAO a shout!

3 Likes
5

This is indeed the tricky part to understand so you are correct to point it out, this clearly requires deeper explanations. Let us review step by step to answer your question properly:

  1. The main challenge in the design is to maintain privacy of user’s whilst bringing authentication to the data. The best solution we could find was to hold the database in a classic web2 server with access limited to active validators while the frontend is open-sourced. This is how we achieve the trust-minimization privacy preserving while having a decentralized execution made by a cohort of validators which risk severe reputation backlash if they ever break the privacy commitment. Moreover we clearly imagined a system where social consensus will slash via the Hub governance if someone ever does this.

  2. Once we have that private database, its important to understand how the data flows. On this server, the data is processed by the open-sourced frontend, therefore only the users with credentials are interacting via the app can write on this database (and also delete information when they want out). On their side the validators are only allowed to read.

  3. We assume that users of this system should have enough security & privacy guarantees to add as much data as possible regarding their profile. Let’s imagine a developer, the first thing I would do would be to connect my github account, and reference all the repos I have been contributing on. The app should be able to collect all that data from github if you authorized it.

  4. Now that we have a vast amount of data linked to profiles (provable contributions), we can talk about the search engine and the qualitative aspect you asked about. Let’s assume a recruiter wants to hire someone with the highest level of competence in IBC middleware development. Now this is purely hypothetical as the specification phase hasn’t yet happened but let’s imagine what that person would input in the search engine to find the best candidates:
    Criteria1: User must have 4+ years of provable developer experience.
    Criteria2: User must be available now for a 6 months part-time job
    Critera3: User must have contributed at least 10 commits to a repo with “IBC middleware” keyword included AND/OR user need to have passed the IBC middleware spectialty test in NodeGuardian AND/OR user need to have passed the level3 test from the ICA on IBC middleware.
    Criteria4: User need to have GoLang certification.
    Criteria4: User base full-time salary must be lower than 120k/y
    Criteria5: User must speak english
    …

With this system, recruiters can benefit from guaranteed results, with the option to contact users who meet their criteria if they agree to pay the required minimum fee. Moreover, the amount of eligible qualitative data can easily scale, as the system uses API/websocket to collect the data on reputable sources, it is up to the community to add new sources beyond github. We see this as a huge opportunity to leverage the InterChain Academy to create more and more certified qualifications and directly integrate them. This system extends beyond just providing qualified candidates, as it has the potential to serve as a central hub for all sort of contributors: those looking for work, recruiters, but also project initiators, marketing experts, and more. This system can scale as the workforce expands.

A valuable addition could be an analytics dashboard that identifies trends, gaps, and more. This could help address coordination issues, enabling people to find each other and collaborate more effectively. The integrated messaging system facilitates communication between parties, eliminating the need for complex networks of contacts that can introduce subjective filtering processes.

We hope this answers your question!

4 Likes
6

Welcome to apply for the QF grant that is dedicated to support teams and public infra like yourself!
You could find on DoraHacks website, or feel free to reach out to me on TG: chris_dora
would love to learn more about it.

3 Likes
7

This looks to be directionally similar to this Talent Hub I think:

1 Like
8

The UX design of this system shares many similarities with a typical web2 app, but with the addition of on-chain credential attestations. Our system, however, utilized a web2 backend with a fully open-sourced front-end and on-chain execution, multiple validators verifying the authenticity of web2 data for block committing. We also considered a fully web3 approach for users who decline optional privacy features. Although our vision differs in the backend, the timing may not be optimal to compete. Let’s revisit this in a few months and observe Calyptus’s progress. Thank you for the feedback, it was valuable and insightful.

2 Likes
9

Not exactly the same, but check out this project that came through on the Cosmos Hub Nigeria accelerator run by @ATOMAcceleratorDAO
https://dorahacks.io/buidl/24504

2 Likes
10

This project aligns well with several key objectives outlined in our initial vision for this initiative. We are encouraged by its direction and fully support the incubation and successful implementation of such projects within the ecosystem :slightly_smiling_face:

1 Like
11

This is the kind of framework that is necessary to facilitate some of the other kinds of businesses I’ve previously outlined in an ecosystem managed kind of way.

I’m of the opinion that projects that generate positive cash flow that is funneled back into the ecosystem, and that serve as a marketing/community relations tool - is a net positive multiplier for the ecosystem.

What is the general consensus in investing in businesses other than online blockchain apps? I think there is a huge opportunity to build DAO businesses that are more in the manual labor / robotic and automation sectors with a management structure.

  • Window Cleaning
  • Car Wash
  • Real Estate Development
  • Farming

And the kinds of collabs that can be done with chains like Regen and other businesses in this sector.

There is business development work and overhead associated, salaries for management team ect… with this strategy, but profit sharing and experimenting with this strategy would be an interesting social experiment.

What are your thoughts on using these kinds services as a community relations marketing approach?

This could even be a strategy that enguaged validator teams could help out in a substantial way, and I genuinely think a coordinated effort could generate the kind of network effects that could be positvie — just reading over some of these other topics. Validators.. The Cancer of Cosmos?

12

A Cosmos Cosm-Wasm app for managing projects?

cosmwasm-projectmanagement/
├── Cargo.toml # Project dependencies and metadata
├── examples/
│ └── schema.rs # Generates JSON schema for messages
├── src/
│ ├── contract.rs # Main contract logic (instantiate, execute, query)
│ ├── error.rs # Custom contract error types
│ ├── msg.rs # Message definitions (Instantiate, Execute, Query, Hook)
│ ├── state.rs # State definitions (storage items, structs)
│ ├── execute.rs # (Optional) Break down execute logic handlers
│ ├── query.rs # (Optional) Break down query logic handlers
│ ├── lib.rs # Crate root
│ └── event.rs # (Optional) Event definitions

Serious about putting this kind of plan into action?

Okay, let’s brainstorm the features needed for a project management application built using CosmWasm smart contracts.

Here’s a breakdown of potential features, categorized for clarity:

I. Core Project & Task Management (On-Chain Logic)

  1. Project Creation:
  • Define project name, description, goals.
  • Assign a project owner/administrator (wallet address - Addr).
  • Optionally link to a project-specific token or treasury.
  • Store project metadata (potentially linking to off-chain docs via IPFS hash).
  • Emit event: ProjectCreated.
  1. Task Management:
  • Create Tasks: Define title, description, status (Todo, InProgress, InReview, Done, Blocked), priority, estimated effort/points, optional due date (Timestamp).
  • Assign Tasks: Assign tasks to one or more wallet addresses (Addr).
  • Subtasks: Ability to break down tasks into smaller, trackable items.
  • Dependencies: Define relationships between tasks (e.g., “Task B blocks Task A”).
  • Status Updates: Allow authorized users (assignee, owner) to change task status. Status changes are immutable records.
  • On-Chain History: Every significant change (creation, assignment, status update) is recorded transparently.
  • Emit events: TaskCreated, TaskAssigned, TaskStatusUpdated.
  1. Milestones/Sprints:
  • Group tasks into logical milestones or time-boxed sprints.
  • Track progress towards milestone completion based on underlying task statuses.

II. User & Access Management (On-Chain Logic)

  1. Role-Based Access Control:
  • Define roles (e.g., Owner, Admin, Member, Contributor, Viewer).
  • Assign roles to wallet addresses (Addr) at the project level.
  • Control permissions for actions (creating tasks, assigning, updating status, managing members, approving payments) based on roles. Stored on-chain.
  1. Team Management:
  • Invite/add members (their wallet addresses) to a project.
  • Remove members.
  • View project members and their roles.

III. Financial & Token Integration (Unique Blockchain Features)

  1. Task Bounties/Payments:
  • Attach a bounty (in native tokens like ATOM or a CW20 token like USDC) to a task.
  • Funds could be held in escrow by the project management contract itself or a dedicated project treasury contract.
  • Automated Payouts: Configure payouts to the assignee’s wallet address upon task status changing to Done (potentially requiring approval from the project owner/reviewer).
  • Emit event: BountyAdded, PaymentReleased.
  1. Project Funding/Treasury Management:
  • Allow projects to receive funds (native/CW20) into an associated on-chain treasury address or directly into the PM contract’s controlled escrow.
  • Basic display of project balance.
  • (Advanced) Integration with DAO tooling for managing treasury proposals/spending.
  1. Contribution Tracking & Token Rewards:
  • Track contributions (tasks completed, reviews done).
  • Optionally reward contributors with project-specific CW20 tokens based on completed work or milestones achieved. This can incentivize participation in open-source or community projects.

IV. Collaboration & Communication (Hybrid On/Off-Chain)

  1. Comments/Discussions:
  • Attach comments to tasks or projects.
  • Consideration: Storing extensive comments directly on-chain can be expensive due to gas costs. Options:
    • Store comment hashes on-chain, with full content on IPFS or other decentralized storage.
    • Use a dedicated off-chain or layer-2 solution for discussions, potentially referencing on-chain task IDs.
  • Emit event: CommentAdded (with hash/reference).
  1. File Attachments:
  • Link relevant files/documents to tasks or projects.
  • Store files on decentralized storage (IPFS, Arweave, etc.).
  • Store the storage identifier (e.g., IPFS CID) on-chain within the task/project data.
  1. Notifications (Off-Chain Service):
  • While the contract emits events, an off-chain service would be needed to listen for these events (e.g., TaskAssigned, StatusUpdate, NewComment) and push notifications to users via traditional channels (email, mobile push, DMs) or web3-native messaging protocols.

V. Governance & Decision Making (Unique Blockchain Features)

  1. Simple On-Chain Voting:
  • Allow project members (potentially weighted by role or token holding) to vote on simple decisions, like prioritizing features or approving certain actions.

VI. Querying & Reporting (On-Chain Queries + Off-Chain Indexing)

  1. Data Queries:
  • Implement various QueryMsg endpoints to retrieve project lists, task details, tasks by status/assignee/project, user roles, order/review history (if integrated with a marketplace like the previous example). Use pagination.
  1. Activity Feeds: Query recent on-chain events/actions related to a project or user.
  2. Basic Reporting (Off-Chain Recommended): While simple counts (tasks done vs. total) can be queried, complex reporting (burn-down charts, velocity) is better handled by an off-chain service indexing the contract’s events and state.

Key CosmWasm Considerations:

  • Gas Costs: Design state and interactions to minimize gas usage. Avoid storing large, frequently changing data directly on-chain.
  • Storage: Utilize decentralized storage (IPFS, etc.) for large data blobs (files, extensive descriptions, potentially comments). Store only identifiers/hashes on-chain.
  • State Management: Use cw-storage-plus effectively (Map, IndexedMap, MultiIndex) for efficient data storage and retrieval based on common query patterns.
  • Events: Emit detailed events for all significant state changes to enable reliable off-chain indexing and UI updates.
  • User Experience (UX): Interacting directly with smart contracts via wallets can be cumbersome. A good front-end UI is crucial to abstract away blockchain complexities for non-technical users.

Building a project management app on CosmWasm leans into transparency, automation (especially around payments/rewards), censorship resistance, and global accessibility, making it particularly interesting for DAOs, open-source projects, and globally distributed teams.

1 Like
13

VII. What?

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎

14

Updating a kernel requires the chain to be stopped, or it used to at least, building an app to handle some of the same functionality with smart contracts creates a poduct on the hub where there is a fully operational ecosystem that can be enguaed internationally - and updates to the core fucntionality are non-consequential.

That’s the logic, anyhow. The management of services that generate net positvie cash flow, being bootstrapped by the community pool - is an idea I’ve thought is worth serious consideration. The goal is for those funds to feed back into the ecosystem, perhaps - enguage new participants in the ecosystem by introducing and/or encouraging the “buillt in” payment rail for those services, and having branded laborer’s servicing those job funcitons.

Something else to consider - if a validator can multi-task, manage a small team performing some service, and he makes addional income from this service, they might be less likely to dump the tokens - AND there would be that additonal network value introducded into to the ecosystem. There is a community of people here - how enguaged do “we” want to be in our network effects?

Some concepts I’ve been broaching for some time

1 Like
15

This architectural proposal is well thought out. Any team interested in developing this framework could consider integrating a modest developer fee into the execution of some—or all—of the on-chain contracts. This would allow for the initial development costs to be gradually covered over time. In our view, this would represent a net positive and contribute to the creation of a truly valuable product.

We also agree that the frontend suggestion is highly relevant. However, we believe it should be considered as a follow-up phase, given the significant workload required to ensure proper integration with all underlying contract interactions.

Conclusion:

At Govmos, we fully support the creation of this Talent Hub. The breakdown of features proposed by @jasonsprouse aligns perfectly with our own vision. Should he—or any other community member—be interested in building the actual contract architecture, we would be more than happy to support the effort in any way we can.

Thank you for reading,
Govmos
pro-delegators-sign

1 Like
16

I’m for this…it’s in alignment with things I’ve suggested in the past. The variety of work could cover everything from administrative to manual labor. It can be done as an independent chain such as you’ve suggested - with smart contracts or as a smart contracting system on Atom.

Which ever you think might be better. This is historically how these products come to market…a developer fee in the contract isn’t the practical way to get a product to market. I also want to point out that Ai, although it can expediate the development of solutions…I’ve seen Ai suggest anti-patterns that are severe security risks, for example: storing a private key signature in the browsers local storage.

Restricting funding because there is technology that helps productivity ≠ intelligence. BEAWARE, pay close attention and scrutinize anything thoroughly before you think even the best available systems “do the work for you.”

I’m also not sure how many people are familiar with other tools that have been in exsistence for a VERY LONG TIME, like Rational Rose - that generate stubs for sofware systems. Ai in and of itself isn’t exactly a superior product to conceptulizing and streamlinging the development of software products. Just an FYI.

1 Like