Handling Sum Rewards From All Active Plugins

[0x4007]

Similar to how GitHub actions supports capturing output from each step in CI, we should do the same. We should support rewards output (including support for negative values) as well as comment output.

Then the kernel can sum the requested permits and post them all in a single comment at the end when the issue is closed as complete.

Regarding comment output, if we support full HTML comment output from each plugin, we could generate the comment body by concatenating all of the comment outputs of every plugin invoked as a response to the given event.

I suppose there might be another standard useful interface property for passing around metadata between each plugin that is not intended to be comment display data or financial permit data.

This is an architectural conversation for how to standardize the plugin-kernel interface properties so that they work for all of our intended modular use cases.

So I guess for inputs every plugin should support some standard properties which right now aren't clear to me. I presume we will pass along event context from the kernel. I suppose we can pass in a string as the arbitrary input value, similar to a command line interface. This will allow us to serialize complex json objects if needed, or pass in simple string parameters to plugins if that's all they need?

[0x4007]

@gentlementlegen @whilefoo rfc on kernel-plugin interface design, and enabling negative permits (at least for one plugin to subtract rewards from the others in an invocation)

[whilefoo]

Similar to how GitHub actions supports capturing output from each step in CI, we should do the same.

We already support that - you can use any output from a plugin as input to another plugin

Then the kernel can sum the requested permits and post them all in a single comment at the end when the issue is closed as complete.

I'm not sure if kernel should be responsible for dealing with permits, it should only call plugins. I don't understand why we need to sum permits, won't conversation-rewards generate all rewards and permit-generation will generate permits based on that?

Regarding comment output, if we support full HTML comment output from each plugin, we could generate the comment body by concatenating all of the comment outputs of every plugin invoked as a response to the given event.

That's a good idea, a standard property like comment and then the kernel posts a comment when all plugins finish executing. So conversation-rewards can output a comment about reward summary and permit-generation outputs permits, then the kernel posts 1 comment containing both.

So I guess for inputs every plugin should support some standard properties which right now aren't clear to me. I presume we will pass along event context from the kernel. I suppose we can pass in a string as the arbitrary input value, similar to a command line interface. This will allow us to serialize complex json objects if needed, or pass in simple string parameters to plugins if that's all they need?

For now all plugins have these standard inputs. If the need arises we can add more

[0x4007]

I'm not sure if kernel should be responsible for dealing with permits, it should only call plugins. I don't understand why we need to sum permits, won't conversation-rewards generate all rewards and permit-generation will generate permits based on that?

That's a good idea, a standard property like comment and then the kernel posts a comment when all plugins finish executing. So conversation-rewards can output a comment about reward summary and permit-generation outputs permits, then the kernel posts 1 comment containing both.

The kernel should be responsible for dealing with permits in a similar way that I propose it would be dealing with the comments. I'll try my best to explain:

won't conversation-rewards generate all rewards

No, there are many future planned incentives that should not be handled by conversation-rewards for example, providing rewards for completing pull request reviews (i.e. approve, request changes) providing time estimates (Time: label.)

Imagine a future where organizations codify their own direct financial incentives for their contributors. Conversation rewards is definitely a cool general purpose example, but its far from the only idea that I have (and I'm sure other partners will have.) To accomodate this future, we need to support "payment requests" from every plugin invoked in a webhook handler event chain.

Plugins should also have the ability to modify the rewards outputs of others.

One planned example of this is our developer relations (referral) system, with "zero sum" rewards. This will subtract from a contributor's reward, and pay the person who referred them. You can read more about it in my proposal here.

[ubiquity-os-beta]

Warning!	This task was created over 199 days ago. Please confirm that this issue specification is accurate before starting.
Deadline	Sat, Oct 26, 1:05 PM UTC
Beneficiary	0xE80FC2700ec6faF5f0347a2E7E7798FAf548e1c3

Tip

• Use /wallet 0x0000...0000 if you want to update your registered payment wallet address.
• Be sure to open a draft pull request as soon as possible to communicate updates on your progress.
• Be sure to provide timely updates to us when requested, or you will be automatically unassigned from the task.

[ariesgun]

/stop

[gentlementlegen]

/start

[ubiquity-os-beta]

Warning!	This task was created over 262 days ago. Please confirm that this issue specification is accurate before starting.
Deadline	Sat, Dec 28, 10:34 AM UTC
Beneficiary	0x0fC1b909ba9265A846b82CF4CE352fc3e7EeB2ED

Tip

• Use /wallet 0x0000...0000 if you want to update your registered payment wallet address.
• Be sure to open a draft pull request as soon as possible to communicate updates on your progress.
• Be sure to provide timely updates to us when requested, or you will be automatically unassigned from the task.

[gentlementlegen]

/stop

[sura1-0-1]

/start

[ubiquity-os-beta]

! You do not have the adequate role to start this task (your role is: member). Allowed roles are: collaborator, admin.

[surafeldev]

/start

[ubiquity-os-beta]

! You do not have the adequate role to start this task (your role is: member). Allowed roles are: collaborator, admin.

[ubiquity-os-beta]

Important

• Be sure to link a pull-request before the first reminder to avoid disqualification.
• Reminders will be sent every 1 day and 18 hours if there is no activity.
• Assignees will be disqualified after 3 days and 12 hours of inactivity.

[0x4007]

/ask any inputs for solutions on this conversation?

[Keyrxng]

Following the merge of #96 this task can be implemented far easier I think.

1. The worker can be called directly via fetch and the permit objects passed back to the kernel from each plugin with "last" in the chain producing the payout comment or the kernel itself (relies on the kernel/plugins knowing they are the last in a plugin-chain to signal to the kernel to write the comment)
2. The worker is treated as a Plugin and is built-in as the last plugin in all chains meaning all previous send back the payment requests to the kernel and it produces them all at once.

Below is what the endpoint/plugin would require from each plugin in order to generate a bunch of permits.

curl -X POST http://localhost:4000 -H "Content-Type: application/json" -d '{"settings":{"evmPrivateEncrypted":"wOzNgt-yKT6oFlOVz5wrBLUSYxAbKGE9Co-yvT8f9lePsx7wJwPVugS9186zdhr1T4UpkpXvq9ii5M-nWfrydMnllSkowH4LirRZsHbvRVSvDoH_uh80p6HpwqDSG3g4Nwx5q0GD3H-ne4vwXMuwWAHd","permitRequests":[{"type":"ERC20","userId":106303466,"amount":1,"evmNetworkId":31337,"tokenAddress":"0xe91D153E0b41518A2Ce8Dd3D7944Fa863463a97d","nonce":"0x123"}]}}'

So long as each plugin all sends the correct nonce which is ${user.id}-${issue.nodeId} then we can merge all requests into one permit rather than each plugin generating their own. The metadata then would be built from the chain of plugins that built the requests, maybe something like:

type PaymentRequest = {
  [pluginName: string]: {
    [userNodeId: string]: PermitRequestObject
  }
}

PermitRequestObject is equal to the settings within the curl command payload, the same as what text-conversation-rewards uses atm. If each plugin generates it's own permit that means we need to redesign the nonce schema I think.

[ishowvel]

Ok so in my opinion I think plugin chains would be quite a good approach, a reward getting passed down and getting merged with other rewards to them finally be passed to the kernel to be generated, posted on an issue, and saved to the db

If plugins don't rely on each other that doesn't really makes sense...plugins will pass rewards to the kernel not to other plugins

There will be no loss of metadata as each reward plugin will give out a standardized html strong to be displayed in a breakdown

The problem is that you're trying to merge rewards but in the payout UI you will "unmerge" them. What is the benefit of merging rewards?

{
  "reward": 50,
  "token": "0x1",
  "chainId": 1,
  "userId": 2,
  "metadata": [
     "metadata1",
     "metadata2"
}

vs

[
 {
   "reward": 20,
   "token": "0x1",
   "chainId": 1,
   "userId": 2,
   "metadata": "metadata1"
 },
 {
   "reward": 30,
   "token": "0x1",
   "chainId": 1,
   "userId": 2,
   "metadata": "metadata2"
 }
]

This rewards + plugin metadata mashup object will then get passed onto the kernel which will post a single permit of 465 WXDAI and below it detail each plugins reward in bulletpoints with their respective metadata being in a breakdown

The kernel can still post the comment with summed up reward for each user but it will be stored in DB as separate rewards. And the kernel won't generate a permit, it will just store the reward, the user will generate the permit in the payout UI

@gentlementlegen rfc

@Keyrxng funnily enough, I had the exact same idea that you had but the problem with this approach is this ^^

[whilefoo]

1. The worker can be called directly via fetch and the permit objects passed back to the kernel from each plugin with "last" in the chain producing the payout comment or the kernel itself (relies on the kernel/plugins knowing they are the last in a plugin-chain to signal to the kernel to write the comment)

I think the ultimate goal is for pay.ubq.fi to generate permits so the kernel would just save them in the DB in a ledger of sorts

2. The worker is treated as a Plugin and is built-in as the last plugin in all chains meaning all previous send back the payment requests to the kernel and it produces them all at once.

We removed plugin chains due to issues with KV rate limit and also since all reward plugins would be able to compute rewards independently it would be a bit counter productive to put them in a chain that runs sequentially.

[Keyrxng]

@ishowvel "great minds think alike, but fools seldom differ" 🤝🏼

---

I think the ultimate goal is for pay.ubq.fi to generate permits so the kernel would just save them in the DB in a ledger of sorts
We removed plugin chains due to issues with KV rate limit

I thought the KV workaround was temp mb.

If the kernel is only responsible for pushing permit shaped objects to the DB which the UI generates from, why does the kernel need to receive anything at all, why can't the plugin(s) just push direct to the db? I'm assuming to create the permit comment on the issue?

permit-generation can push to the DB via fetch so there's no need to over-engineer kernel-permit handling really if we hardcode using the permit-generation worker into our plugins.

Although if plugins are async and unchained, then the kernel wouldn't know when to post the new "permit comment" so it might have to be something generic "Rewards were generated for <user1>,... check them out here "pay.ubq.fi" especially with the text-convo being split apart into plugin modules.

---

Current and planned infra has changed a lot since this spec and with more big changes coming in that'll break apart text-conversation etc, it's probs best to wait until that is implemented or until the specification of both that and this are considered more in-depth. At least for myself with proposing solutions as things are still quite unclear to me.