Client UI (Web UI)

[thebeast0407]

To improve the usability of commands and make it easy to manage multiple services, accounts, networks from service provider perspective, we should have a Client UI support enabled for SNET CLI.

I would like to Propose a Client UI with the following features

1. Networks and Account Management

• List networks, add/update/delete networks
• List Accounts, add/update/delete accounts
• Activating Network and Account i.e. setting up default accounts
• Manage the keys

2. Transaction Management

• List all transactions
• Pending vs Completed Transactions
• Transaction Summary
• Manage Transaction Price
• Adaptive Pricing Mechanism

3. Service Management

• List services, Organizations
• Service Status, health, summary
• Organization summary
• Develop/Deploy/Publish services
• Organization and Service registration
• List of endpoints, add/delete/update service endpoints
• Service Metrics (Service Provider perspective)

4. Metadata creation and validation
5. Account Wallet to manage funds (service providers perspective only)
6. Channel Management and Treasurer
7. Local state – update/delete/publish/recover/reset
8. Code Generator – configurations, service stubs, etc.
9. Log Viewer
10. Connect to Daemon through Operator UI

it could be an addition to proposed Daemon's Operator UI ( #29). Only limitation I am seeing at daemon level is, One service provider might be hosting multiple services, which could be running multiple daemons. In that case the user will be having multiple Operator UI's for each of the daemon or daemon cluster.

Whereas SNET Client UI, can provide a single interface to manage all the services, and other CLI related functions.

[ferrouswheel]

There are a lot of features listed! I think if we tackle this we should split it up into a series of releases.

I also think that instead of implementing multiple UIs, one for the daemon and one for the CLI, we should just implement the a snet-cli client UI and make it show the daemon information accessed via grpc.

[ferrouswheel]

I think the client UI would also be the ideal place for service authors to be able to work on their service UI for the dapp. This would show the service author's UI component and allow the caller to optionally skip all the metamask and blockchain interaction, calling the grpc endpoint directly. See singnet/snet-dapp#31

[raamb]

@ferrouswheel please treat this as an Epic, when implemented this will definitely result in multiple tasks in different repos. (In fact I think it might be worthwhile for us to have a separate repo for such proposals)

The idea is to have one UI for the service developers wherein they can interact with

• Their services - This is essentially an SDK use case. We will use the Javascript SDK
• Their daemons - We will expose this on the Daemon via grpc. Obviously we will have to figure an authentication mechanism for this

The Javascript SDK will take shape as part of refactoring the DApp. In the mean time we can start building the UI for the daemon management and have them converge eventually. At that point we will have a

• command line client (hopefully leveraging the Python SDK)
• DApp (leveraging the javascript SDK - buyer perspective)
• Web client (leveraging the javascript SDK - buyer and developer perspective)

[pennachin]

Let's create a project board for this.