Summary
I would like to propose adding an optional Taskmarket delegation extension to the OpenHands extensions registry. I opened PR #471 as a proof of concept and would appreciate guidance on whether this integration fits the repository.
Use case
An OpenHands agent may identify work that is better handled by an external worker market. A small, documented extension could let an agent browse public tasks and present a prepared delegation for human review without taking control of payment or acceptance decisions.
Proposed scope
- Read-only task listing and pagination.
- A bounded preparation step that summarizes the exact task, reward, deadline, deliverables, network, and spend ceiling.
- Paid task creation delegated to Taskmarket's first-party CLI only after explicit human confirmation.
- Read-only task status and submission retrieval for human review.
- No silent accept/reject operation and no automatic resolution of submissions.
Safety and maintenance
The proof of concept does not request, store, log, or commit private keys, seed phrases, tokens, cookies, or wallet secrets. It keeps signing and payment in the first-party CLI, requires a one-time preparation token plus exact confirmation, and applies a configurable maximum reward ceiling. Tests cover Python syntax, the MCP protocol handshake, and a live read-only task listing; no paid write was performed.
Would the maintainers be open to this optional integration, and what changes would be required for it to be maintainable in the extensions registry?
Summary
I would like to propose adding an optional Taskmarket delegation extension to the OpenHands extensions registry. I opened PR #471 as a proof of concept and would appreciate guidance on whether this integration fits the repository.
Use case
An OpenHands agent may identify work that is better handled by an external worker market. A small, documented extension could let an agent browse public tasks and present a prepared delegation for human review without taking control of payment or acceptance decisions.
Proposed scope
Safety and maintenance
The proof of concept does not request, store, log, or commit private keys, seed phrases, tokens, cookies, or wallet secrets. It keeps signing and payment in the first-party CLI, requires a one-time preparation token plus exact confirmation, and applies a configurable maximum reward ceiling. Tests cover Python syntax, the MCP protocol handshake, and a live read-only task listing; no paid write was performed.
Would the maintainers be open to this optional integration, and what changes would be required for it to be maintainable in the extensions registry?