The ~provider-name note is technical debt from an earlier, less clear spec of the protocol when it seemed like we might use a more complicated hierarchical namespace where a "provider" might have had multiple endpoints registered underneath it. This is overly complicated and leads to confusion in the provider metadata setup — a user is asked to create a provider-name note, but the actual subentry name (in the beta, provider-name.grid-beta.hypr) is rightfully enforced. The entire concept of that note should be cut out of the protocol entirely.
For the foreseeable future, we should move forward with a design where the registry namespace is totally flat, and each sub-entry corresponds to a single service/tool/endpoint.
To wit, we should remove the ~provider-name note from the Provider client UI, users should declare a provider name and it should populate the sub-entry name field itself.
This needs to be tested end-to-end, as anywhere where the Operator client depends on ~provider-name it should be converted to depend on the sub-entry name. The two obvious places this might come up are in the Operator<>Provider API and the Operator search algorithm.
As the required changes to the Operator client are fairly minimal, @Gohlub should handle this issue on his own as much as possible.
The
~provider-namenote is technical debt from an earlier, less clear spec of the protocol when it seemed like we might use a more complicated hierarchical namespace where a "provider" might have had multiple endpoints registered underneath it. This is overly complicated and leads to confusion in the provider metadata setup — a user is asked to create aprovider-namenote, but the actual subentry name (in the beta,provider-name.grid-beta.hypr) is rightfully enforced. The entire concept of that note should be cut out of the protocol entirely.For the foreseeable future, we should move forward with a design where the registry namespace is totally flat, and each sub-entry corresponds to a single service/tool/endpoint.
To wit, we should remove the
~provider-namenote from the Provider client UI, users should declare a provider name and it should populate the sub-entry name field itself.This needs to be tested end-to-end, as anywhere where the Operator client depends on
~provider-nameit should be converted to depend on the sub-entry name. The two obvious places this might come up are in the Operator<>Provider API and the Operator search algorithm.As the required changes to the Operator client are fairly minimal, @Gohlub should handle this issue on his own as much as possible.