Consolidated Comment Per Plugin Chain Run ID

[0x4007]

Right now its messy that every plugin posts their own comments. It allows for flexibility but I think its a bad idea for it to be the main way. . I propose we have a method that lets the developer pass in the comment data and the kernel posts the comment on behalf of the plugin. . The important part is that the comment has special metadata, a run ID, that includes the Cloudflare KV run UUID.
. And when other plugins in the chain want to leave a comment, it appends in its own divided section (using the plugin ID) The kernel can have a custom parser that can manipulate the comment per plugin section (or "field") with the help of the metadata. . The plugin developers are abstracted away from these low level details, and instead just have to worry about passing strings to the kernel to do the heavy lifting with. . The primary method should have appending behavior, but we should also support clobbering (replacing the comment content, limited to only the section/field controlled by the plugin) . A simplified example of a section separator:

<!-- uuid@plugin name -->

<!-- abcdef123456@ubiquity-os-marketplace/text-conversation-rewards -->

The parser can identify section separators with a regex and parse out each plugin's output.

[0x4007]

Not sure if this is a day or week task @gentlementlegen @whilefoo rfc

[whilefoo]

I propose we have a method that lets the developer pass in the comment data and the kernel posts the comment on behalf of the plugin.

Would this method send the comment to the kernel right away and the kernel would post it immediately or would it gather all comments and send it back to the kernel at the end of the plugin execution along with other other data like usual?

The latter sounds more feasible to me and is more easier to implement

The important part is that the comment has special metadata, a run ID, that includes the Cloudflare KV run UUID.

So the plugin would include a string comment and its own metadata, then the kernel would add some standard metadata like run ID...?

And when other plugins in the chain want to leave a comment, it appends in its own divided section (using the plugin ID) The kernel can have a custom parser that can manipulate the comment per plugin section (or "field") with the help of the metadata.

So basically two methods: one method which appends a new comment to previous ones and another method that would replace all previous comments with a new one

[0x4007]

Would this method send the comment to the kernel right away and the kernel would post it immediately

Ideally, for status updates per plugin. For example, text-conversation-rewards says please wait before starting. Anyways we can figure that out later if its too difficult, as that is the only plugin that has that behavior.

then the kernel would add some standard metadata like run ID

Kernel metadata would act as clear borders between each plugin's output.

and another method that would replace all previous comments with a new one

Yes, of that plugin. Plugin A can't clobber plugin B's output for example. They are guarded by the kernel section dividers.

[gentlementlegen]

This is already implemented by the SDK so now every comment will have that metadata on it. I think it is too complex to send the data to post to the kernel, example for text-conversation-rewards were the same comment gets modified during the run. Using the SDK to post will ensure that all the plugins are consistent, and avoids having to modify the kernel.

[0x4007]

same comment gets modified during the run.

I disagree, you just need to check and compare the run ID from within the metadata of any comments by ubiquity-os[bot]