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.

[tiilliir]

/wallet 0x58e83b330158ba79de3cac0bc5b190f6ea000e69

[ubiquity-os[bot]]

+ Successfully registered wallet address

[tiilliir]

+ Successfully registered wallet address

/help

[0x4007]

@Keyrxng why doesn't help work? It seems that the bot reliability is not 100%

[gentlementlegen]

/help

[ubiquity-os[bot]]

Available Commands

Command	Description	Example
/help	List all available commands.	/help
/allow	Allows the user to modify the given label.	/allow @user1 label
/query	Returns the user's wallet, access, and multiplier information.	/query @ubiquibot
/start	Assign yourself to the issue.	/start
/stop	Unassign yourself from the issue.	/stop
/wallet	Register your wallet address for payments.	/wallet ubq.eth

[gentlementlegen]

@Keyrxng why doesn't help work? It seems that the bot reliability is not 100%

Pretty sure /help didn't work because there is also quoted comments above the command itself (so not recognized as a command).

[Keyrxng]

@Keyrxng why doesn't help work? It seems that the bot reliability is not 100%

Pretty sure /help didn't work because there is also quoted comments above the command itself (so not recognized as a command).

/help

yeah seems you are right mentlegen

[0x4007]

/help

[ubiquity-os[bot]]

Available Commands

Command	Description	Example
/help	List all available commands.	/help
/allow	Allows the user to modify the given label.	/allow @user1 label
/query	Returns the user's wallet, access, and multiplier information.	/query @ubiquibot
/start	Assign yourself to the issue.	/start
/stop	Unassign yourself from the issue.	/stop
/wallet	Register your wallet address for payments.	/wallet ubq.eth

[0x4007]

. /help

[ubiquity-os-beta[bot]]

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

[Hassanalmotawe89]

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?

[ishowvel]

Is this the issue which specifies the central payment infrastructure, aggregating payment requests to the kernel to then be passed on the permit generation plugin?

[ishowvel]

@gentlementlegen if this central payment infrastructure gets implemented then all the incentives wouldn't be posted in a single payment permit right? Do you have an idea to combat this

[gentlementlegen]

@0x4007 Would know more on how the final result should be.

[0x4007]

Every plugin returns a "payment request" and the kernel sums them and generates a single permit

[ishowvel]

@0x4007 can you give me an example of the flow you have in mind and the type of metadata that would also be given to the kernel alongside the reward

[ishowvel]

@0x4007 🙏🏾

[0x4007]

@gentlementlegen didnt you say that you have a pull ready for this

[gentlementlegen]

I was talking about the separation of the plug-in generation from text conversation rewards as an endpoint which has a PR ready

[ishowvel]

@0x4007 here's the solution I have in mind text-conv-reward and simplify-reward return payment request to the kernel with a reward amount and metadata comment and plugin-name

The rewards for each user gets merged to get the total reward for a user across all plugins and after each permit there will be some metadata from each permit in bullet points

each plugin will return an html compat string that they want to be put in a drop-down, plugin name and reward amount

For example [ 465 WXDAI ] @ishowvel

• text-conv-reward: [ 400 WXDAI ] (a drop-down with whatever metadata but in this case the table from text-conv-reward)
• simplify-reward: [ 65 WXDAI ] (a drop down showing the additions and removals of lines in the pull diff)

The only question I have is how will the kernel collect the permit requests to post in a single comment, posting each plugins reward in a separate comment sounds easy but is in my opinion not a good solution