New gRPC NameService API

The PR replaces hash type by []byte.
This is good but it removes the support of Service SID.
It needs to be added back, but as a client side system that use a new and clean API to resolve the sid.

I suggest to create a new gRPC service NameService that should be compatible with any resource identified by a unique hash. Of course, we will only implement sid on this new service for now. But it will prepare the foundation for a more general purpose name service.

service NameService {
  rpc List(ListNameServiceRequest) returns (ListNameServiceResponse) {}

message ListNameServiceRequest {
  string name = 1;

message ListNameServiceResponse {
  []string hashes = 1;

The List api should return a list of hashes’ resources that match name == service.sid.

The current only way to add a new name will be by creating a new service with a sid.

We will be able to add new APIs to this service to completely separate sid and name resolution.

I like the idea of NameService but we need to ask why we need such nameservice in the first place.

Handle sid is for developer purpose only so why can’t someone just use a function in bashrc and use it?

function mesg-sid {
  mesg-cli service:list | grep $1 | akw '{print $3}'

Why do we want to implement something for dev purpose only? Without version, sid can’t be used across the network because the results will be ambiguous

1 Like

Conclusion after the meeting:

  • The resolution will be done in the CLI and JS Lib using the service list or instance list APIs
  • Add a filter based on sid to service.list and/or instance.list if really needed
  • We will think about a new API later