Problem to be solved
Our trycloudflare links are still pretty impermanent, websites, skills, etc go out of date (often for relying on latest tags too, different issue).
Proposed solution
Have the cli (and internal and external agents) manage the updating of agent registration to match the current tunnel with a set metadata call. Log approximately how much gas will be consumed / was consumed in u.Dim(). trigger this clean up if we detect a tunnel change? service rich metadata on the domain?
Out of scope
(but worth discussing)
what if we do a --publish equivalent to our launchpad, and give them a more persistent place for discovery (and maybe tunnelling?). something like pet-name.agent.obol.tech (or .dev or something), and allow them to CRUD metadata there? (imo it depends on how good decentralised finding services through 8004 is, could we watch for registrations? would that restrict us to eth funders only? whereas if they call us directly they don't need to go on chain to display them.
Problem to be solved
Our trycloudflare links are still pretty impermanent, websites, skills, etc go out of date (often for relying on
latesttags too, different issue).Proposed solution
Have the cli (and internal and external agents) manage the updating of agent registration to match the current tunnel with a set metadata call. Log approximately how much gas will be consumed / was consumed in u.Dim(). trigger this clean up if we detect a tunnel change? service rich metadata on the domain?
Out of scope
(but worth discussing)
what if we do a
--publishequivalent to our launchpad, and give them a more persistent place for discovery (and maybe tunnelling?). something likepet-name.agent.obol.tech(or .dev or something), and allow them to CRUD metadata there? (imo it depends on how good decentralised finding services through 8004 is, could we watch for registrations? would that restrict us to eth funders only? whereas if they call us directly they don't need to go on chain to display them.