Nostr integration

*draft : proposal / review needed

Top-down design where the upper layer needs to know only how to operate with the layer immediately below.

OpenAgents Interface

The OpenAgents interface is the user interface that provides a webui to talk with agents

Agents

Generic/specialized LLM or traditional software that can use tools by constructing their triggering events and waiting for responses

Nostr / Event Templates

Parameterized templates to execute tools on the execution layer.

• The agent will pick a template and generate an event by replacing the parameters with user inputs or other data.
• The event will be signed and submitted to nostr
• The execution layer will execute the event and return a response

Note: The agent doesn't need to understand the details of the events or whether it uses plugins, standalone nodes or anything in between. The agent only needs to know that triggering an event with a certain template will produce the desired outcome.

Plugins

Extism plugins are a practical way to extend agents functionalities without building additional nodes on the execution layer. They will be executed by a specialized openagents/extism-runtime node. An openagents/extism-runtime node can run multiple plugins in parallel.

Execution Layer

The execution layer is explained by borrowing some terminology from bitcoin mining. It can be seen as a collection of interconnected pools operating on nostr (immagine bitcoin mining but with nostr that acts as both the blockchain and the mempool).

• Everyone can self-host a pool
• Pool selection can be enforced in the event template
• Pools are interconnected via Nostr NIP-90 events
• Miners(aka workers/nodes) are connected to Pools and listen for compatible jobs to execute
• Pools can have their own policy to accept new miners
• Pools have a nostr key pair
• Miners submit results and info on the jobs they execute through the pool to nostr
• The user can audit and obtain all the logs and results of every step by looking for events on nostr

Miner vs Miner Managers

A miner is a software that listen on nostr for specific job requests that it can handle. All jobs executed by a node must be isolated by the runtime environment.

A miner manager is a special type of node that listen for multiple job requests and spawn the required nodes to handle them. Every job is executed in an isolated container that lives only for the duration of the job. The miner manager is responsible for managing the nodes and the resources they use. The miner manager must ensure a proper isolation for the containers, since they can run untrusted code (see. gVisor for a possible solution).

Sub Job Request

As part of the execution of a job request, a miner can request another miner to perform some work. This is identical to the way the user asks for a job: the miner will post a job request to nostr and wait for the response. For convenience pool provides an rpc call for this purpose, the miner can use that and avoid having to deal with implementing custom nostr logic on its own.

Event Templates discovery

Event templates are discovered using NIP-89. It is up to the miner to announce the event templates it supports and their expected outcome.

Templates get reannounced periodically, if a template is not reannounced after several minutes (10?) it is considered expired and evicted from the pool.

Special case: extism-runtime plugin announces

The extism runtime is a special case, as it will announce a template for each plugin available in the connected XTP registry. Different extism runtime nodes can be connected to different XTP registries and provide a different set of plugins.

On an higher level, these templates will just look like any other template, so the agent won't have to deal with custom logic to handle them.

Roadmap

• PoC implementation of node-to-node protocol based on on NIP-90 : https://github.com/OpenAgentsInc/nostr-poc
• openagents gRPC services OpenAgents Pool
  • grpc services exposing basic tools needed for an OpenAgents node (eg. nostr connector)
• openagents/extism-runtime image
  • A docker image based on openagents/runtime that runs jobs defined as a main extism plugin and a list of dependencies
• NIP-89 Job templates discovery
• Finalize first version of OpenAgents node-to-node protocol
• Define a way for a node to be registered at OpenAgents and act as an entry node for a certain task
  • Semantic Route?
  • LLM tool?
  • ???
• Restore current OpenAgents behavior on top of the new protocol
• Implement Event Auditors Pools, as source of trust, can handle this
  • Initially only OpenAgents will be a trusted auditor, but more can be added in the future
  • Auditors can be asked to verify and co-sign an event by the nodes
  • Auditors can check things like
    • The user exists and has a paid subscription
    • The user has enough funds to pay for the job
    • The job is not a spam
    • The job is only using allowed resources (eg. whitelisted images)
    • The job is not malicious
  • The auditors will publish an event with the result of the audit
  • Nodes are free to ignore the audit results or decide which auditor to interrogate and trust
• Implement monetization on top of the new protocol
  • Might be part of the audit process or something separate
  • Might be built around NIP-90 payment-required feedback
• openagents/node-manager image
  • Implement the node manager (see Nodes vs Node Managers)
• Runtime images for common languages
  • Should run only on isolated environment (such as Node Manager based environments)
  • Can be used to run custom code that is not compile to extism runtime
  • Can be used for code-gen
• Finalize and propose a job request type for the OpenAgents protocol in the NIPs repo
• Encryption
  • Some Jobs might have sensitive inputs and outputs. There should be a way to specify optional encryption to make the data readable only to certain trusted nodes and not to everyone connected to the nostr relays.
  • NIP-90 supports encryption
  • Ideally it should encrypt the job for a group of several nodes (eg. all nodes owned by a trusted party) to keep the protocol flexible

Execution flow

See NIP90-5003-draft.md