PR: bridge Personal Agent & UbiquityOS communication

[EresDev]

Resolves ubiquity-os/plugins-wishlist#3
Requires PR: init Personal Bridge EresDevOrg#1

All reviewers of this PR must also review EresDevOrg#1 because both plugin are in synergy. Both PRs are open to review.

QA: #6

How to test?

Currently Personal Agent handles only one command

/@web4er say hello

You can try this in QA link. web4er has personal agent setup. Be patient because it takes a little time to reply because two workflows run one after another.
For any other command it replies with different errors. More commands will be added to Personal Agent with time.

If you want to set up Personal Agent and its Bridge on your instance of UbiquityOS, follow Personal Agent Bridge docs and Personal Agent docs.

[0x4007]

@whilefoo @gentlementlegen please check this pull

[whilefoo]

I'm not sure why we need a bridge. I think it unnecessarily adds complexity. If this was in the kernel you wouldn't need to retrieve the agent config and decrypt the PAT with X25519_PRIVATE_KEY but simply call the plugin/agent which is the whole point of the kernel.

And I don't think it would clatter the kernel code because this is implemented in 50 lines of code or even less. Another intermediate plugin just adds latency, maintenance burden and doesn't add much value.

The only possible benefit that I see is that in the future this bridge could send more context to the agent but that should probably be the responsibility of the agent. Every org would also need to enable this plugin but if it's in the kernel it's enabled everywhere.

[0x4007]

So do you want to import this logic into the kernel? It makes sense that you or @gentlementlegen do it because you're most familiar with the kernel code.

[EresDev]

I'm not sure why we need a bridge. I think it unnecessarily adds complexity. If this was in the kernel you wouldn't need to retrieve the agent config and decrypt the PAT with X25519_PRIVATE_KEY but simply call the plugin/agent which is the whole point of the kernel.

plugin-agent could be present where UbiquityOS is not installed. So, it can't trigger the action of a plugin-agent without an encrypted PAT, can it?

And I don't think it would clatter the kernel code because this is implemented in 50 lines of code or even less. Another intermediate plugin just adds latency, maintenance burden and doesn't add much value.

The scope of this plugin seems wide if you see the issue specifications. I mean using kernel kind of a limits it. You don't want too much in kernel. If we assume these 50 lines work in kernel, I see more things coming there soon. Anything that needs more power for example:

Prompt follow ups: there are situations where I tag team members for input and they take days to reply. I think if they take longer than 24 hours to reply, I would want to dock XP

and similarly

Ideally the personal agent should monitor pulls that I approved and are still opened. If I said something like this, and if those conditions are met, it should merge the pull.

You don't want to give such a power to personal-agent directly and you don't want to handle list of such actions in kernel and you likely don't want a separate plugin for such actions. Bridge can expose a limited interface for personal agent.

Maybe I can say that UbiquityOS is for organizations, and personal-agent with its bridge is for individuals that may or may not be member of that organization.

[0x4007]

Maybe I can say that UbiquityOS is for organizations, and personal-agent with its bridge is for individuals that may or may not be member of that organization.

This is correct

[whilefoo]

plugin-agent could be present where UbiquityOS is not installed. So, it can't trigger the action of a plugin-agent without an encrypted PAT, can it?

Yes UbiquityOS app needs to be installed.

The scope of this plugin seems wide if you see the issue specifications. I mean using kernel kind of a limits it. You don't want too much in kernel. If we assume these 50 lines work in kernel, I see more things coming there soon. Anything that needs more power for example:

Prompt follow ups: there are situations where I tag team members for input and they take days to reply. I think if they take longer than 24 hours to reply, I would want to dock XP

and similarly

Ideally the personal agent should monitor pulls that I approved and are still opened. If I said something like this, and if those conditions are met, it should merge the pull.

You don't want to give such a power to personal-agent directly and you don't want to handle list of such actions in kernel and you likely don't want a separate plugin for such actions. Bridge can expose a limited interface for personal agent.

If the user of the personal-agent for example @0x4007 is an owner of an org then it's not a problem that the agent has power because it's written by the user so it can do whatever the user wants. If the user doesn't have any permissions then all they can do is automatically respond to comments.

The examples you're providing should be done by the agent and not by the bridge, because that's the point of agents if I understand correctly.

Although the examples could also be a standalone plugin because they would be useful for all organizations and not just 1 user, but ultimately the agent acts on behalf of the user and bridge is not responsible for containing logic (that's why it's called a bridge) but in this case I don't think a bridge is needed unless you have other functionality in mind that would be suitable for a bridge

[EresDev]

If the user of the personal-agent for example @0x4007 is an owner of an org then it's not a problem that the agent has power because it's written by the user so it can do whatever the user wants. If the user doesn't have any permissions then all they can do is automatically respond to comments.

By user,, you mean personal-agent owner or the user who comments? If org owner hosts personal-agent, do you think it meets the following issue specs?

This will look for username tags at the beginning of any comment, and relay everything to their self hosted plugin.
The rest of the magic happens within their own self hosted plugin so this should be a super simple plugin to build.

There are some ways we can make the template code which will be forked:

The vision here is that we can make custom user "agents" (i.e. plugins with LLMs) that are hosted by the user's GitHub (so they can modify it) and will automate actions for the user (with their PAT to authorize as them) with the full context of a particular repository/organization.

The user can "fine-tune" their LLM by adding extra details and preferences to their prompt in their forked code. I imagine that I would continue to add new sections as I see repetitive questions/queries._

Let's first decide that who hosts personal-agent then we can see if we need a bridge or not. With these specs, I think personal-agent is hosted by each user themselves.

[0x4007]

I imagine a future that we each have our own personal agents to essentially act as macros to automate what we all personally and individually find to be repetitive problems.

[whilefoo]

Yes each user hosts their own personal-agent and it gets triggered when someone tags them @0x4007 can you review this?

[0x4007]

Yes exactly, and in this instance I could have a personal agent with a custom prompt that will perform reviews exactly in the way that I would like to, and perhaps even in my writing style.

[EresDev]

Yes each user hosts their own personal-agent and it gets triggered when someone tags them @0x4007 can you review this?

Ok, with this, user's PAT stays, its encryption stays. Basically whatever is in the bridge right now stays.

We can do all this in the bridge or in the kernel. I don't mind moving it to kernel. But nature of this is issue is open-ended. It has potential to grow and things related to personal agent will continue to get added to bridge.

Also, you are right, it is bridge so it should only bridge messages but we can rename it to mediator or something if it grows. But right now it is exactly what it says.

I feel that sometimes personal-agent will require a part of a its job to be done under more permissions which UbiquityOS has. But the nature of the job is such you don't want a separate plugin for it. For example:

/@EresDev review my pr

the review is ok. now PR should be merged. personal-agent can't do this. it needs more permissions which you probably do not want to give to personal agent because it is too much power. Auth Tokens doesn't provide such fine grained access. You want that part of the job to be done under UbiquityOS. The bridge can also take care of such small tasks where you do not want a complete new plugin. Adding it to kernel would bulk up the kernel.

So, the summary here is:

if it is okay to keep adding things related to routing and authentication and (probably some more) to kernel, we can use kernel and discard the bridge.

[0x4007]

Seems that keeping things separate is better while we are still developing this idea.

[whilefoo]

I feel that sometimes personal-agent will require a part of a its job to be done under more permissions which UbiquityOS has. But the nature of the job is such you don't want a separate plugin for it. For example:

/@EresDev review my pr

the review is ok. now PR should be merged. personal-agent can't do this. it needs more permissions which you probably do not want to give to personal agent because it is too much power. Auth Tokens doesn't provide such fine grained access. You want that part of the job to be done under UbiquityOS. The bridge can also take care of such small tasks where you do not want a complete new plugin. Adding it to kernel would bulk up the kernel.

If the user that hosts the personal-agent doesn't have permissions to merge the PR then why would they want to merge a PR, we can set permissions for the user on the Github, no need to reimplement permissions in the bridge.
The idea is very simple, personal-agent acts on behalf of the user and I don't foresee any major functionality inside the bridge, but sure we can keep it separate for now and move it to the kernel later.

[0x4007]

QA looks fine. I think we should change the syntax to be just using @username instead of /@username.

[0x4007]

@gentlementlegen @whilefoo can you guys test and approve this

[whilefoo]

@EresDev I tried running the bridge but I had to fix a lot of things because it's so outdated to get it running. Can you please update both personal-agent-bridge and personal-bridge to use the latest SDK and also the latest ts-template - the template was outdated for a long time and has now been updated.
Also you should delete the worker part since it won't work on Cloudflare because of libsodium lib.

@0x4007 something to keep in mind: because this bridge is a plugin, it doesn't have full kernel privileges so personal-agent needs to be a public repo otherwise it won't work.

[0x4007]

It doesn't look like your QA is live and functional #6 (comment)

[EresDev]

It doesn't look like your QA is live and functional #6 (comment)

Try now. It was not ready when you were testing it. But should have worked with old command with /@ style. It works now with new command style. I inform explicitly when review points have been implemented. I am also working on other review points now, so maybe I should turn this into draft now.

[EresDev]

Seem like plugin-template has changed drastically. I spent a few hours trying to fix this but no luck. It appears I will have to redo most of this bridge and personal-agent to accommodate new plugin-template. I will do this when I am back from off days.

[0x4007]

@gentlementlegen seems im not the only one with problems with the template. How about you or @whilefoo take over because this is probably 95% done and strategically important.

[gentlementlegen]

ubiquity-os#41

@EresDev I'd suggest you start fresh once this is merged and then just port you code inside.

[0x4007]

EresDev told me that they are taking time off now so it's better if you guys handle it. Since you're busy setting up for the onboarding call tomorrow I think @whilefoo is best suited to take over.

[whilefoo]

Sure, I can take over