Bot Factory status check (GraphQL API)

[richburdon]

Currently there's no way to check if bots and bot factories are alive (and they mostly are not). Also the registry is littered with dead bot factories.

• [ ] Enable developers to "deregister" bots (mark them as inactive); requires WNS records to support labels?
• [ ] Implement GraphQL HTTP API endpoints for BotFactories to report current status (incl. active bots); each BF is assigned a port (in a pre-determined range)?
• [ ] Poll status from console.

[telackey]

Implement GraphQL HTTP API endpoints for BotFactories to report current status

I don't think this will work as such, because the BotFactories are controlled over WebRTC, and the Bots they spawn are as well. There are cases where:

1. You could reach by HTTP but WebRTC still fails.
2. You can reach by WebRTC but HTTP fails.

There is also the fact that basically ties BotFactories to public IPs and possible DNS registration (eg, to use HTTPS).

I agree with the direction though. I think there are many imaginable cases where it makes a lot of sense to "ping" a BotFactory before I attempt to use, but I think the status I care about in this context is, "Can I communicate with this factory in the same way I'll need to communicate with it in order to spawn and connect to a bot?" Which implies pinging it over WebRTC not HTTP.

[egorgripasov]

@richburdon - That is quite good topic for discussion;

The original requirement was to communicate with BotFactory over WebRTC, which is understandable enough; At the same time, this adds some p2p related uncertainty to the flow - swarming, etc. Also, in case of any protocol related errors (i've seen such) BotFactory would not be available as well; As @telackey mentioned, it does not feel like we should mix both WebRTC and HTTP and do some kind of "ping" using same protocol that is used to do spawn, invitation, etc.

1. If we use HTTP for everything (ping, get status, spawn/invite bot, etc) overall communication with BotFactory would be more stable. We would also be able to talk to BotFactory using less resources and time, so we actually could send some ping requests for multiple botfactories and check which are available, even before displaying them in BotFactory select. Downsides here are described by @telackey as well - tying BotFactories to public IPs , DNS, etc.

2. If we use WebRTC as communication channel, it makes sense to use it for ping as well. Actually, we already support that - there is a corresponding methods in botkit-client, as well as CLI command, which looks like

~ wire bot factory status --topic=$(wire bot factory query --name dxos.network/demo | jq -r '.[0].attributes.topic') | jq
{
  "started": true,
  "version": "1.0.0-beta.207",
  "uptime": "951480",
  "platform": "linux.x64",
  "bots": [
    {
      "type": "wrn:bot:dxos.network/chess#0.0.1",
      "botUID": "fa71fd3938276b6edca77a614f64a088f00b93516ece39761fcbe1d93926490f",
      "started": "2020-07-24T12:05:15Z",
      "lastActive": "2020-07-24T13:07:58Z",
      "stopped": false,
      "parties": [
        "19b88414d723952eca1612c89975bb3fa3bcfd93cb21fd4e6d42e410b936d38a"
      ]
    }
  ]
}

However, this type of ping won't be much different from spawn command itself - it could timeout on different levels of the stack - signal/ice connection, swarming, etc - so even with ping command you would be waiting for 30 seconds to find out that botfactory is not available (for one of the reasons.)