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