Ping protocol in uAgents

[GataKamsky]

We need a ping protocol in uagents. This will allow AI Engine to filter out agents that are not active. Today AI Engine picks up any agent. This can include agents that are not reachable and active.

cc: @ejfitzgerald

[Dacksus]

I feel it might be worth discussing alternatives, so here are my thoughts:

Assuming we have a ping protocol, sending out a ping message can result in 2 things: 1) the target agent is active/online and returning a ping or 2) the target agent is not active and the connection times out.

Without a ping protocol one would get the same behaviour by sending the intended request message. The only difference is that in case the target agent is active, the reply can directly be used.

I assume that the reason for thinking about a ping protocol is that when looking for agents for a task, the ai engine does not know yet which agent the user will choose, but we want to no the active state before suggesting it to the user. So what about the alternative of sending an actual request even before user selection? In the positive case (target agent is active) there are again 2 possible situations: 1) the ai engine can already compute a valid context or make a useful guess. In that case the result can be cached and directly returned / used should the user select this task. 2) Ai engine has too little information and needs to create a bogus context/request. In this case the reply only indicates the lifeness, but a new and useful request must be created. In the negative case we don't send more messages compared to the ping scenario at the cost of precomputing potentially wasted contexts. In the positive case we save a message and gain some responsiveness upon task selection.

@qati needs to advise how often it might be feasible in general to precompute contexts before selection and the overhead this might induce.

We had similar concerns a while back and discussed to add a deregistration functionality to the almanac such that it only returns active agents. However, this obviously doesn't change the situation for agents that are simply abandoned or drop out due to connectivity issues, if we don't tighten the almanac registration timeout or include a heartbeat protocol at this level.
Key question here: Does the ai engine always resolve via the Almanac API or does it only check it's own listings DB? (I.e. would you even try to contact agents that already timed out on the Almanac?)
Conclusion at that time was that the inherent timout of the almanac registration period would be enough to deal with inactive agents.

Long story short, I can see the requirement but it feels a bit like a workaround of our own intended architecture and functionality and I think it's worth resuming the discussion to extend/change Almanac functionality, or considering wrapping such functionality that is only needed in the context of the ai engine into a separate module outside of the core microagent framework to only be included by agents connecting to the ai engine.