0x4007 commented 7 months ago

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)

0x4007 commented 7 months ago

@ubiquity/software-development rfc

rndquu commented 7 months ago

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:

Partner exchanges 100 LUSD for 90 Dollars (-10% mint fee)
Partner approves uniswap's permit2 contract to spend Dollar tokens
Now the partner's bot instance can generate permits up to 90 Dollars

Regarding the bot we could start with introducing paid subscription tiers. Example:

Tier 1 (Free): use the bot in up to 3 repos
Tier 2 (Paid): use the bot in up to 10 repos
Tier 3 (Paid): use the bot in up to 20 repos
etc...

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.

0x4007 commented 7 months ago

I actually thought that the Dollar token was meant to be the main source of monetization.

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.

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:

Partner exchanges 100 LUSD for 90 Dollars (-10% mint fee)

Partner approves uniswap's permit2 contract to spend Dollar tokens

Now the partner's bot instance can generate permits up to 90 Dollars

Regarding the bot we could start with introducing paid subscription tiers. Example:

Tier 1 (Free): use the bot in up to 3 repos

Tier 2 (Paid): use the bot in up to 10 repos

Tier 3 (Paid): use the bot in up to 20 repos

etc...

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.

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.

The idea behind the bot's plugins sounds good but it will take time to implement compared to plain old paid subscriptions.

I think that's okay if it takes some time.

P.S. We still need the bot to be stable + start acquiring partners because we somehow need to test monetization strategies.

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.

0x4007 commented 7 months ago

rfc @ubiquity/research

@gitcoindev @molecula451 @whilefoo @wannacfuture

molecula451 commented 7 months ago

Multi-Dev Oriented, AI Centric Bot - Powered Dollar DAO

Understanding 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

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?

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

whilefoo commented 7 months ago

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 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?

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.

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. But I'm not sure if it's a good idea to charge the partners during every invocation of the plugin because it will accrue a lot of transactions costs.

We also should be thinking about easy crypto based monetization for creators.

Who are creators in this context?

sergfeldman commented 7 months ago

make the bot a developer platform 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.

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. Crypto projects often stimulate the contribution of testnet users, liquidity providers, and content creators. Following this logic, it is essential to systematically stimulate the contribution of developers and creators on GitHub.

Also, it is aligned with GitHub's long-term vision to facilitate collaboration on software creation.

We should make it convenient for creators to collect money, starting with our monetized plugins.

Based on my experience with our bounties, I believe that convenience for everyone involved is critical. The simpler usage the better.

The time spent on receiving rewards or setting up platform plugins may prevent us from attracting a significant number of users.

sergfeldman commented 7 months ago

I think this model is pretty elegant and allows people to manage/incentivize their organizations/repositories as they wish.

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. Possible scenario variations:

A contributor has successfully completed the task -> the reward is automatically sent to his wallet -> after the transaction is completed, he is tagged in a comment with a link to the transaction on GnosisScan.
A contributor successfully completed the task -> points for the airdrop were associated with his wallet -> after TGE the contributor can claim his tokens.
A contributor successfully completed the task -> an NFT became available for him to mint -> after collecting several NFTs, the contributor receives a large reward.

In the future, it is worth exploring non-monetary incentives for contributors. Some enthusiasts contribute not only for financial rewards but also for getting recognition. Currently, GitHub provides such opportunities poorly and this is an area that we can use.

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. We can make them soulbound tokens to avoid abuse.

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.

sergfeldman commented 7 months ago

Dynamic NFT can be used as a "Contributor passport" https://chain.link/education-hub/dynamic-nft-use-cases

molecula451 commented 7 months ago

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

sergfeldman commented 7 months ago

FYI GitHub Accelerator vision

The world runs on open source. None of it would be possible without the global team of contributors who freely devote their time and energy to pushing our shared digital infrastructure forward. Open source developers often balance enterprise jobs by day and community work by night. For many, this isn't sustainable - especially in places where unpaid work isn't possible. Going full-time means navigating a maze of sponsorships and grants, licensing gray zones, and starting companies, with a rare few developing into durable businesses. Our open source community needs more examples and better guides on how to take the leap into full-time work. With the GitHub Accelerator, we want to pioneer new ways for developers to simply and sustainably work in open source full-time – built on developer's terms.

molecula451 commented 7 months ago

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

rndquu commented 7 months ago

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:

Plugin creator registers his plugin (i.e. server side app / API / worker) on the bot's website
Plugin creator subscribes to the on_comment webhook in the bot's website plugin settings
When the bot's github app receives a new on_comment event we resend the webhook data to plugin creator's server app
Plugin creator's server app either posts the "Hey" message using plugin creator's github token either sends a callback to the bot's backend with smth like {event: "post_comment", value: "Hey"} so that the "Hey" message could be posted using the bot's github token

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.

0x4007 commented 7 months ago

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

proprietary plugins
various plugin types
up to 6 hour plugin computations
access control
a clear path to implementation

whilefoo commented 7 months ago

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.

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.

Do we have example of this? How is the data passed to the Github actions? I'm guessing with API. It says data has at most 10 properties - I don't know if this counts nested properties too and if so it is quite limited. So then Github actions invoke the code - theoretically this code could be written in any language, right?

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.

Using fine-grained personal access tokens we can also delegate compute to private repositories' GitHub Actions, for proprietary 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?

0x4007 commented 7 months ago

I think @wannacfuture can answer the implementation questions as they are the one who implemented it.

So then Github actions invoke the code - theoretically this code could be written in any language, right?

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.

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.

Unsure about the security implications but I'm sure this is easily surmountable within GitHub's authentication tooling/infrastructure.

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.

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.

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.

This already works with the delegated compute for private ubiquibot-config repositories interfacing with public test repository.

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?

Yes that's pretty much it.

wannacfuture commented 7 months ago

How is the data passed to the Github actions? I'm guessing with [API]. It says data has at most 10 properties - I don't know if this counts nested properties too and if so it is quite limited.

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: eventPayload and its type is string - so we can send different string (which is stringified from object) for different events. The one thing you need to consider is that you cannot send circular object -> the object including functions or something.

And when the compute is completed, how does it send data back to the bot?

We are sending repository_dispatch event back to the bot and it won't return any security-sensitive data. It will just send the result of the calculation.

we need to think about security because anyone could send arbitrary payload to the endpoint.

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.

molecula451 commented 7 months ago

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: eventPayload and its type is string - so we can send different string (which is stringified from object) for different events.

It would be nice to see this in action..

The one thing you need to consider is that you cannot send circular object -> the object including functions or something.

I think this is the fruit of being debugging hard on server-side?

And when the compute is completed, how does it send data back to the bot? We are sending repository_dispatch event back to the bot and it won't return any security-sensitive data. It will just send the result of the calculation.

Interesting, but probably there is still room for leaked data to watch if anything, if not then good...

whilefoo commented 7 months ago

We are sending repository_dispatch event back to the bot and it won't return any security-sensitive data. It will just send the result of the calculation.

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.

rndquu commented 7 months ago

It will take us a year to implement the plugins feature.

There are simpler ways of monetization that we can start using right now:

paid bot subscriptions (make an exception for partners with a large audience)
paid listing at https://work.ubq.fi/
Dollar fees
etc...

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.

0x4007 commented 7 months ago

It will take us a year to implement the plugins feature.

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.

There are simpler ways of monetization that we can start using right now:

paid bot subscriptions (make an exception for partners with a large audience)

paid listing at https://work.ubq.fi/

Dollar fees

etc... 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.

These are not mutually exclusive. We should be considering and shipping all of these ideas.

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.

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.

rndquu commented 7 months ago

Why the long timeline? What is your definition of this?

I think this v1 vision is realistic for us to achieve within a few months. It allows for

proprietary plugins

various plugin types

up to 6 hour plugin computations

access control

a clear path to implementation

Long timeline reasons:

Plugins feature is huge. We need to move core logic to different packages, cover with tests, think of a safe communication between github actions, prepare SDK and docs for 3rd party integrators, prepare 3rd party integrator fee mechanic, create UI for 3rd party integrators where they can register there plugins and 100 other features. So it will take even more than a year.
TLDR; We need more core team members. Development capacity. When the bot is back live, when Dollar is deployed there will be an ongoing set of new features/bugs to implement/fix so the core team will struggle to find time for the plugins feature. We might end up "outsourcing" plugin related issues to bounty hunters which would eventually bring us to a mess (pretty much like now) in the bot's code which we would have to rewrite again in 2025. I've already mentioned that mission critical issues (like generating permits or checking contract's storage collisions) must be implemented only by the core team because it's in the best core team members' interests to solve an issue in the best way possible + core team members are aware of the overall architecture.

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.

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: No market need. So we should start checking whether the market is ready to pay and for what features. The plugins feature basically postpones for a year this "market check".

0x4007 commented 7 months ago

TLDR; We need more core team members.

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:

establish a local physical office.
have a dedicated team member leading the recruiting of key personnel.

We're also throwing a mixer this month and inviting students from top universities to get involved.

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.

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.

In the end it doesn't matter how "huge" is a partner if it's a paying one.

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.

Number 1 reason of why startups fail: No market need. So we should start checking whether the market is ready to pay and for what features. The plugins feature basically postpones for a year this "market check".

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.

0x4007 commented 7 months ago

"Plugins store" almost ready to boot: https://probot.github.io/apps/

https://probot.github.io/apps/cr-bot/

0x4007 commented 5 months ago

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.

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 evmPrivateKeyEncrypted based on the origin of the request, but without research it isn't clear to me how we can do this in a secure manner.

// 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 https://github.com/ubiquity/ubiquibot/issues/906

molecula451 commented 5 months ago

And receive the payment permit back. It would be more elegant to dynamically read the evmPrivateKeyEncrypted based on the origin of the request, but without research it isn't clear to me how we can do this in a secure manner.

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?

0x4007 commented 5 months ago

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.

ubiquibot[bot] commented 5 months ago

! action has an uncaught error

0x4007 commented 5 months ago

! action has an uncaught error

@wannacfuture this is another instance of a handler searching for "issue 1234" I'm assuming you hardcoded 1234 for some reason in the main branch. This is an example of why you should work on your own fork instead of debugging on main.

molecula451 commented 5 months ago

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

0x4007 commented 5 months ago

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

0x4007 commented 4 months ago

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 bond amount can be arbitrary, but checked by the kernel before invocation.
1. As a security feature, the kernel/permit-generation plugin can reject generating transactions of a certain amount with plugins that have a bond that is lower.
"Whitelisting" is handled by the partners who add the plugin in their configs.

The implementation details require more thought but I'm sure we can model it off of CowSwap resolver bonds is my point.

ubiquity / ubiquibot

Updated Vision #898

Context

Plugins

Monetization for Creators

Value Transfer Architecture

Multi-Dev Oriented, AI Centric Bot - Powered Dollar DAO