Defining "user stories" for the Registry. should we support getServiceRegistration(organizationName, serviceFullName)?

[astroseger]

My initial intention was to precisely define possible user stories for Registry in order to check, do we really need listServicesForTag functionality, removing which would completely solve #66 . But by doing so, I've realized that the main functionality of Registry is broken! Fortunately it is easy to fix it.

So let's define which functionalities in Registry are needed by user .

I. The service in SingularityNet is defined as OrganizationName + ServiceFullName. ServiceFullName can contains a path, so we cannot limit ServiceFullName to 32 characters (this will be important later).

(USER STORY 1)
What user wants, is to call services using OrganizationName and ServiceFullName. For doing so, he needs to get service registration using OrganizationName and ServiceFullName.

In #76 we've discussed that OrganizationName in Registry will be replaced with OrganizationIndex (or OrganizationGUID ), and user will use some other functionality (hopefully ONS contract) to convert OrganizationName to OrganizationIndex. But it changes nothing in the current discussing, so let's stick to the current implementation, and assume that we still have OrganizationName in the Registry.

So, we need a function to get service registration using OrganizationName and ServiceFullName. Unfortunately we don't have this function. We have serviceFullName (we call it service_display_name) in metadata, so to get service registration using OrganizationName+ServiceFullName we need to read entirely registry (solving path problem (#60) by introducing displayname in the registry was a bad idea. I'm sorry for this).

We cannot simply replace ServiceName with serviceFullName in Registry, because Solidity does not support mappings with strings of arbitrary size, so ServiceName should be bytes32. But as we've seen before we cannot assume that serviceFullName is shorter than 32 characters.

There is an easy solution: We need to rename ServiceName in Registry to ServiceNameHash, and set ServiceNameHash = keccak256(serviceFullName).

• we can assume that there is not collision between 256 bit hashes. If you uncomfortable with this assumption you should stop using Ethereum :)
• There is not security problem in such hypothetical collision (because full ID of the service is still OrganizationName + serviceNameHash)
• It solves our problem.

[ksridharbabuus]

@astroseger even the keccak256(servicename) may not solve the actual problem of uniqueness in the service names. Even this limits to have unique service name in the organization. Let us assume that if provider needs to enable multiple versions of the same service in the organization?

I still feel we need to have more clarity on the low level requirements to come up with the right solution. For example I am not able to figure out why end user needs to worry about the URI construction as the service request calls happens behind the scene. If needed we can expose a function to provide the Service URI where he can directly consume instead of asking construct the URI.

We need to have a detail discussion on the use case to come up with the better solution approach.

[astroseger]

I'm totally agree that we need to discuss...
Having serviceid (or even serviceglobaId) is might be a good solution (I believe you've proposed it back in HK). (id could be GUID :) ).

Nowadays user very rarely type URL of the site in the browser (I stole this argument from @vsbogd )

[raamb]

Refer to #76 (comment)
We revisit this post beta if required