Updated Vision #898
Comments
|
@ubiquity/software-development rfc |
|
I actually thought that the Dollar token was meant to be the main source of monetization. We already have the UbiquityPool contract where users (i.e. partners) are able to exchange collateral tokens for Dollars. We could enforce all partners to use payouts (i.e. generate reward permits) in Dollar tokens and increase a "mint Dollar" fee to 10%. Example:
Regarding the bot we could start with introducing paid subscription tiers. Example:
We could make the bot's tier dependant on the "mint Dollar" fee. The higher tier (i.e. paid bot subscription) used the lesser "mint Dollar" fee applied to a partner. The idea behind the bot's plugins sounds good but it will take time to implement compared to plain old paid subscriptions. P.S. We still need the bot to be stable + start acquiring partners because we somehow need to test monetization strategies. |
I think we should look it as a tool to leverage to make "behind-the-scenes" profits. For example, say that we "only support Ubiquity Dollars" for the most useful plugins. So we can offer some features for "free" but in reality there are swap/mint fees as well as us being able to make money on the collateral. Maybe one day we could consider lowering these fees to be more competitive and subsidize costs from our other products (card transaction fees to merchants, bot subscriptions etc) I'm open to new ideas around monetization and I hope to get the team's input along the way as much as possible. Philosophically, I like the Amazon approach of trying to bring down costs as much as possible for the end users by reinvesting profits constantly to hopefully offer exceptional products/service. They famously have been "barely profitable" due to their constant reinvestment.
I don't like enforcing these fees at the protocol level because it makes the Dollar far less competitive with the others in the space. However if we can do it at the application level, I think there could be some easy profits for the convenience factor. Similar to MetaMask swap or even Coinbase (vs Coinbase Exchange) trading fees.
I think that's okay if it takes some time.
I'm pretty optimistic about onboarding partners because I've received a lot of verbal agreements when promoting at events. However in order to make a good first impression, I decided to hold off on follow ups until its stable and useful. I think a good go-to-market strategy would be to get recognized names (e.g. MakerDAO) to use our system for free, in exchange for co-marketing, and then I think it can spread through network effects from there. This is both from other projects seeing Maker use the system, as well as the developers contributing. I am more keen to charge lesser known partners that have less reach. |
|
rfc @ubiquity/research |
Multi-Dev Oriented, AI Centric Bot - Powered Dollar DAOUnderstanding the vision to bring partners and potential high-class end users to make use the bot, we should be releasing a stable beta that does most of the intended and make use of interesting features (which we already were doing it), create dependence of our bot to these DAO making it highly attractive. I think we will have good interaction with the upcoming dollar deployment on a live stable, also create the demand for the Dollar token and have these partners on stake. to me it does absolutely look like a long-term vision, since we're still crafting it im sure there will be many changes a long the way. I think we should restrict core features need, which will make the bot highly lucrative when in demand and offer free uses always. thus making in attractive and creative the demand for the core/paid features aswell
This sound like an offchain stuff, to be execute on-chain, i think the database could do this work well, unless there are other needs |
So if someone wanted to use the API they would need to create their own Github bot that calculates bounty price and call our API which will only return an object containing the permit data and then their bot needs to post it as a comment? How would these plugins look in practice? Would they be separate repositories/packages and how would they interact with each other? How will partners enable these plugins and start subscriptions? Will this be a smart contract on chain that keeps track of subscriptions or is this something that will be done in our database?
Maybe plugins like task assignment scoring can have static monthly fees but plugins that involve AI which costs are based on usage should be billed per usage.
Who are creators in this context? |
The idea of a developer platform for projects to stimulate their contributors with smart customized incentives sounds very promising. The success of most projects depends on the level of interest of its contributors. Also, it is aligned with GitHub's long-term vision to facilitate collaboration on software creation.
Based on my experience with our bounties, I believe that convenience for everyone involved is critical. The time spent on receiving rewards or setting up platform plugins may prevent us from attracting a significant number of users. |
If we position the platform as suitable for different organizations, then the platform should support different reward scenarios. From the point of view of flexibility for other projects, it is very good that we have already implemented different types of rewards - for completing a task, for its creation, and for comments. But other projects might see reward scenarios differently than we do.
In the future, it is worth exploring non-monetary incentives for contributors. Contributors could have the opportunity to mint NFTs like "MakerDAO valuable contributor" for resolving tasks for MakerDAO, as well as NFTs like "Open Source OG", or "DeFi legend" for resolving issues for several projects. These NFTs could be the key to getting the highest-paid tasks, as well as criteria for airdrops from new projects that are looking to attract contributors. |
|
Dynamic NFT can be used as a "Contributor passport" |
|
NFT is good as long as there is a utility mean, otherwise users are intrinsically motivated by monetary rewards. Monetary rewards and NFT it's a plus |
|
FYI GitHub Accelerator vision
|
|
I've checked the Github Accelerator, looks great, i supposely they mostly fund non-web3 stuff or maybe it wouldn't matter, but you guys should send the application, i think the bot it's a fair candidate |
|
This whole plugin infrastructure basically reinvents github apps. Take, for example, a plugin that should respond with "Hey" to any comment. How it might work:
Here on step 3 we reinvent github webhooks (which by itself is a huge task with retries, message queues, autoscaling, etc...). Perhaps it makes sense to use github apps as separate plugins. This way we could use different github apps for permits, AI features, etc... + we get ready to use github app's billing. |
|
When you say GitHub App that makes me think of separate bots which I assume is not a correct interpretation. Regarding architecture, in case the team isn't up to speed: @wannacfuture recently implemented a means for "delegating compute" to another repository. We had to implement it because netlify has timeouts on some operations (like calculating comment incentives, and AI related features) which take several seconds to compute. Data is passed to an external GitHub repository actions dispatcher, which handles the compute, and then sends the data back to the bot to complete its routine. With this architecture, we can use repositories as our self hosted code and runtime backends. Using fine-grained personal access tokens we can also delegate compute to private repositories' GitHub Actions, for proprietary plugins. Technically speaking we can use any VPS as a plugin backend as well. So in theory we can map a webhook url (of a GitHub actions invocation) to every GitHub event in the config. We can have a standard interface (a set of standard properties and values) that we transmit to every webhook. Lastly we would just need some simple UI that can make editing YML more user friendly, like to be able to pick from a preset list of "delegated compute repositories" (maybe we can fork this UI) I think this v1 vision is realistic for us to achieve within a few months. It allows for
|
|
The idea to use repositories as Ubiquibot plugins seems good as it allows a lot of flexibility but I'm still worried about some aspects.
Do we have example of this? And when the compute is completed, how does it send data back to the bot? I'm guessing the bot will need API endpoints and here we need to think about security because anyone could send arbitrary payload to the endpoint. Will anyone be able to make a plugin? If so, this will require a vetting system that verifies the code is not malicious and code can also change over time so this is a huge undertaking. Maybe at first we only allow our own plugins.
I think the bot will need to be installed on public or private repositories because the documentation says: You must authenticate using an access token with the repo scope to use this endpoint. GitHub Apps must have the actions:write permission to use this endpoint. How does this work in the example of calculating incentives? Github sends a webhook to the bot when the issue is closed, the bot does some compute but wants to offload some compute and calls the plugin for comment incentives via Github actions dispatch API and then when the plugin finishes the compute, it makes API request to the bot with output data and then the bot finishes the incentives calculation and posts the comment on the issue? |
|
I think @wannacfuture can answer the implementation questions as they are the one who implemented it.
Yes. Technically speaking any API endpoint should work fine given what I know now. Perhaps it may be easier to work within GitHub's infrastructure when it comes to security related matters, but this is an assumption without having done research.
Unsure about the security implications but I'm sure this is easily surmountable within GitHub's authentication tooling/infrastructure.
Sure but I think we can make a very simple whitelist per repository. If the origin of the delegated compute is not from within the config's whitelisted plugin array it can ignore the request within that repository/organization, for example. We are not the first tech company to implement such an infrastructure, so I don't have concerns about this being a solvable problem.
This already works with the delegated compute for private
Yes that's pretty much it. |
We just send it using JSON.stringfy() and parse it on the action side - it can also send nested properties. And we can combine them in one field:
We are sending
Also for the data which is security-sensitive, we are using repo's secrets and making the repo as private so I don't think we need to worry about that. |
It would be nice to see this in action..
I think this is the fruit of being debugging hard on server-side?
Interesting, but probably there is still room for leaked data to watch if anything, if not then good... |
I see, so this event is triggered by Github API request by the plugin's code? And then Github includes repository name in the webhook event so the bot can check if the repository is in the whitelist. |
|
It will take us a year to implement the plugins feature. There are simpler ways of monetization that we can start using right now:
You never know what's gonna work so I don't understand why we should throw a year into the plugins feature while there are faster ways to implement monetization strategies which we can test right now. Why don't we test some simple monetization strategies first and in parallel start developing the plugins feature? In the end nobody is 100% sure the plugins feature will become a steady source of income. |
Why the long timeline? What is your definition of this? @wannacfuture already has a functional prototype. The module that generates the permits when tasks are closed as completed is already separated from the bot kernel and I've seen it working. I assume you mean a fully fleshed out "marketplace" in which case I tend to agree. However, leading up to that, the earliest point we can monetize a "plugin" is when we figure out an architecture based on wannacfuture's prototype to be able to collect fees.
These are not mutually exclusive. We should be considering and shipping all of these ideas.
I have mixed feelings on jumping the gun for monetization. I am interested to experiment with monetizing the lesser known partners, although I would prefer to focus on onboarding a small amount of prestigious partners vs tens of unknown partners in the early days. I believe that we can maximize growth by subsidizing fees while we're young. Also, if we can successfully close our series A in 2024, we should have a healthy runway to experiment. For context, at this particular moment we have approximately a four year runway. |
Long timeline reasons:
It's easier to onboard a "prestigious" partner when they see that the product is used by some other companies (i.e. partners), even the small ones. In the end it doesn't matter how "huge" is a partner if it's a paying one. Number 1 reason of why startups fail: |
I am aware and we have efforts underway to remedy this before 1 March 2024. I'm negotiating an offer now with a prospective Ubiquity Chief of Staff to:
We're also throwing a mixer this month and inviting students from top universities to get involved.
The sale is a lot more based on personal relationships. For example, MakerDAO was going really well until I put it on ice due to the product state. I want to roll out the red carpet for prestigious partners, both when initially developing the relationship, and for when they actually use the product. The state of the bot was unacceptable for onboarding two months ago.
I disagree. e.g. $50 revenue a month from MakerDAO is not equivalent to the network effects (and co-marketing reach) that we would get from them. In order to grease the wheels for the sale, we would tell them that we are not interested in their money, but instead co-marketing.
I think that getting to market (i.e. obtaining paid partners) during 2024 is a goal that we should definitely aim for. Lets sell before we finish implementing the plugins feature. |
|
"Plugins store" almost ready to boot: https://probot.github.io/apps/ |
Below is how I envision the config to look like in the near-ish future. Full list of events is generated locally on dependency install but I found a commit with the file https://github.com/ansible/webhooks.js-release/blob/6b8d9f69792bf16000cb609e649d31436ec528b5/dist-types/generated/webhook-names.d.ts#L1 handlers:
issue_comment.created: ubiquibot/check-first-comment
issues.closed: ubiquibot/comment-incentives
issues.opened: ubiquibot/task-matchmaker
issues.reopened: ubiquibot/check-penalty
label: ubiquibot/assistive-pricing
pull_request.ready_for_review: ubiquibot/gpt4-code-review
I also would like a dedicated payment permit generation API/endpoint where we can make it easy for plugin developers to pass in something like: { "pavlovcik": 100, "rndquu": 50 }curl -X POST https://pay.ubq.fi/generate \
-H "Content-Type: application/json" \
-H "x-devpool-installation-id: 1234567" \
-H "x-devpool-evm-private-key-encrypted: xxx" \
-d '{
"pavlovcik": 100,
"rndquu": 50
}'
And receive the payment permit back. It would be more elegant to dynamically read the // example plugin code
const rewards = { pavlovcik: 100, rndquu: 50 };
const comment = await generatePermits(rewards); // attaches installation id and evm private key encrypted
return comment;See more #906 |
an Unauthorized call will always throw a "Bad Request", "Unauthorized Access", by generating an one-time API key on a frontend it think will do it, what other security concerns could come to mind? |
I'm just trying to prevent fraud. For example, I generate payment permits to myself from another organization's wallet without contributing any comments or code to their project. |
! action has an uncaught error |
@wannacfuture this is another instance of a handler searching for "issue 1234" I'm assuming you hardcoded |
|
i think if @wannacfuture debug more in their own fork more chances are for better debugging to future (obvisouly) issues, so he lego his own all enviroment to purify the issues and then push to main |
Agreed |
|
I think we still need to figure out the "Value Transfer Architecture" before we can close this issue as complete. @whilefoo perhaps you have some ideas after working on the kernel @FernandVEYRIER you're new to the team, maybe you have some ideas. Also I think that because its the wild west with plugins and taking money, I think we should base ours off of CoW Swap's resolver bonds model Our implementation can be simpler because:
The implementation details require more thought but I'm sure we can model it off of CowSwap resolver bonds is my point. |
Context
I've been thinking on this for awhile on how to make the bot a developer platform. I think this is best for network effects and growth
Plugins
What if we open source the kernel of the bot and monetize "plugins" not too different from ChatGPT or chrome extension store.
The most valuable capability the bot has I think is the permit generation. Perhaps we open source this and make an API that allows you to post an object with the GitHub username and the amount that they get paid
{ "pavlovcik": 100, "rndquu": 50 }So your own plugin can do the compute based on whatever incentive structure you want to create, then you post back to the bot kernel and it will generate the permits.
This vision is still being crafted but I am very keen on making a developer platform for all DAOs to create their own custom incentive structures.
We can begin by monetizing "ubiquity opinionated incentives" so our own comment scoring config (includes relevance scoring, and clarity scoring) task assignment scoring (bounties mode) and task author scoring etc all as separate plugins that have separate monthly fees.
I think this model is pretty elegant and allows people to manage/incentivize their organizations/repositories as they wish.
Monetization for Creators
We also should be thinking about easy crypto based monetization for creators. For example, if logic is routed through to one of these plugins, the plugin should be able to set aside a fee for itself either during the transaction (skim off some ubiquity dollars?) or somehow do monthly/annual billing.
We should make it convenient for creators to collect money, starting with our monetized plugins.
Enforcing monthly subscription fees on chain might be simple. Every time there is a transaction routed through, it will deduct based on the block height of the previous month (or when they started their subscription) this is similar to our staking logic to farm UBQ now.
Value Transfer Architecture
Regarding value transfer we still need to design architecture that allows us to access the "permit wallets" of projects (perhaps a custom gnosis safe module that allows transfers of tokens? Alternatively we could theoretically transfer/burn from the ubiquity dollar protocol level but we need some solid per wallet opt-in capabilities or else people might feel uneasy about holding ubiquity dollars)
The text was updated successfully, but these errors were encountered: