Operator UI

[ldub]

The SingularityNET daemon should host an admin dashboard for use by service operators.

Should support

• Remote access
• Authentication via password or metamask
• Revenue/Billing overview
  • Revenue in AGI
  • Revenue per service method or client/job owner
• Service status page
  • Breakdown of calls and errors by gRPC service method or client/job owner
  • Latency
• Blockchain interaction explorer
• Configuration
  • Price, parameters, version, etc
  • Service registry management (may be in the dapp instead)
  • Rate limiting configuration ( #28 )
  • Monitoring endpoints and notifications

Stretch goal

• Standalone admin panel that can connect to many instances of snet-daemon (for operators who run many services)

[thebeast0407]

Instead of password based authentication, we can leverage blockchain based signature validation approach, which would be much more secure and easier way.

How it works ?

1. The machine which we are trying to access must have a ethereum account configured for account validation. Only public key will be configured in the machine. Private will be with the service provider or Admin himself
2. Whenever the admin wanted to authenticate himself with the target machine (daemons deployed in here), he must chose a random text and sign it and send the signature to the target machine
3. Target machine validates the signature using the address configured, and allows the admin user to proceed with accessing daemon and perform the intended actions

At present daemon uses receiver account for many blockchain dependent operations. But for Operator UI authentication, we may have to use a different account for the following reasons

• If a single service provider wanted to deploy multiple services using different account for different services, and manage all the different daemons from single operator Ui interface
• securing the recipient address from exposing its details accidentally by admin users. If we use existing recipient address and if in case the private key is compromised, user may loose all the existing funds in that account as well

Would like implement the approach of having a separate account for operator UI and follow the above mentioned steps for authentication, and keep the daemon recipient address.

@raamb @vsbogd

[raamb]

@arturgontijo @ferrourwheel would like to get your view as well. The intention is to build a standalone app which can manage Daemons. This will make the task of configuring the Daemon very simple as it will be GUI based.

[astroseger]

@Dinesh2521 We already have grpc interface for such type of control in the daemon: control_service. This interface already include blockchain authentication (a little bit different protocol though..)! In snet-cli we use this interface to actually control the service (see snet treasurer). We only need to extend this control_service (if we need more control...)

This control center is what we initial called the treasurer server... :)

[arturgontijo]

This GUI would be great for a service provider to update/control/monitor all his daemons at once.

I think @Dinesh2521 item 1 (ethereum account) could be the payment address from service metadata. Even in case that service provider uses different payment address for different services, in this case the GUI could work like MetaMask does for multiple wallets (pks), allowing user to create new wallets and "import" existing accounts (wallets).

[raamb]

@arturgontijo I was hoping to have the operator UI even configure the daemon for the first time. This will be done before the daemon knows whats the payment address is. I was thinking of having the daemon started with an address that it will accept commands from and we could then have all configuration including the first time set up via the operator UI.

[arturgontijo]

Got it, now it makes sense to me. That's great!

[ferrouswheel]

I think the UI should be entirely on the CLI side, using control_service or other authenticated grpc endpoints. A service developer can run snet serve-ui (or something similar) and then access the UI locally, this UI would also aggregate different daemon endpoints into a single consistent view - which is more useful than going to each endpoint individually.

If a service developer wanted a permanent UI hosted somewhere, they could run snet serve-ui on a server next to a daemon (we'd have to figure out what the authentication would look like in this case).

I'm not a fan of making the daemon configure through the UI, and generally I think it'd be better for the security of the daemon to not have it hosting new functionality that increases the attack surface.

[ferrouswheel]

Another issue is if we eventually support a slimmed down version of the daemon that can run on IoT devices (something I'm investigating), then it'd be nice to still monitor these daemons, but it will be resourced constrained. This is a situation where having the UI on the client side would be ideal. We wouldn't have to duplicate the web UI on differents version of the daemon - it'd all be part of the CLI.

Similarly, if the community wants to create their own implementation of the daemon, then it could show up in the CLI web UI, just like any other implementation.

[ferrouswheel]

This will make the task of configuring the Daemon very simple as it will be GUI based.

As someone who has had to configure and manage server software on windows and linux, I can tell you that adding a GUI does not necessarily make configuration any simpler. ;-)

However, this is another place where you could create a GUI wizard for configuration on the CLI side, and deploy the changes to the daemon. Any daemon config changes on the CLI side could be deployed with snet push singnet/snet-cli#174

(In addition, this GUI wizard wouldn't need to be a web app, it could be a desktop app or a terminal/curses app, depending on the environment it's run in)

[raamb]

@ferrouswheel yes we are on the same page w.r.t the operator UI.

Our approach is as follows

• Expose admin APIs (grpc) on the daemon. These APIs allow you to configure various settings of the daemon.
• The daemon will accept a public address when its started and any request signed by the private key corresponding to this address will be honoured by the daemon
• We will have a standalone stateless dapp that can be used to access any daemon. Requests will be signed using the private key corresponding to the address the daemon was started off with
• This dapp will allow you to configure the daemon to begin with. Subsequently we can expose functionality to unlock channels, set up advanced rate limiting rules etc.

[vsbogd]

BTW, only two items from original description are related to daemon itself:

• Rate limiting configuration ( #28 )
• Monitoring endpoints and notifications

All other things are related to logs, metrics, blockchain contracts, service metadata. It does make sense to add other use cases if we have them.

[anandrgitnirman]

All, as a baby step, please find the proto definition below

syntax = "proto3";

package config;

service DaemonConfigurationService { rpc GetCurrentConfiguration(ConfigurationRequest) returns (ConfigurationDetailsResponse) {} rpc UpdateCurrentConfiguration(ConfigurationRequest) returns (ConfigurationDetailsResponse) {} rpc StopProcessingRequests(ConfigurationRequest) returns (ConfigurationDetailsResponse) {} rpc StartProcessingRequests(ConfigurationRequest) returns (ConfigurationDetailsResponse) {} }

enum RequestType { CONFIG_READ = 0; CONFIG_WRITE = 1; STOP_PROCESSING_REQUEST = 2; START_PROCESSING_REQUEST = 3; // Used only by the Watch method. }

enum ResponseType { FAILED = 0; SUCCESS = 1; }

message ConfigurationRequest { RequestType request_type = 1; //Signature will compromise of the below // ("_Request", "block_number","json_data",address) bytes signature = 2; string json_data = 3; }

message ConfigurationDetailsResponse { ResponseType response_type = 1; string json_data = 2; }