Open w1kke opened 5 years ago
We can store whitelist for accessing the service in metadata. We don't need to keep it fully on-chain. We can do it right now without modifying contracts.
in Registry we already have "whitelist" mechanism for adding services. Only members of an organization can add new service to the organization. @w1kke Do you want whitelist for creating new organization (which would be too extremist I think... )?
-> 1.) If it is in the metadata, then what prevents me from calling the service from the registry? The smart contract has to check whether the caller is whitelisted before the service is invoked. In my opinion this is an additional feature that is not needed for general services but some services and jurisdictions require this feature.
-> 2.) You were talking about this in https://github.com/singnet/platform-contracts/issues/76 that companies want to have their own names and somebody else can register them. To guarantee that this cannot happen they would have to do a KYC. This would be the whitelisting to create organizations. But this should again be in a separate registry.
-> 1.) Even if whitelist will be on-chain (and you not in this whitelist) then it will not stop you from calling service if you really want it. Ethereum blockchain is not encrypted after all, so you can find metadata_URI, download metadata and make a call.
Of course you could integrate whitelist into MPE contract and on MPE contract level you could forbid to open a channel, but I don't think it is necessary....
If whitelist will be in metadata then all our tools (snet-cli dApp SDK) will not allow you to open a channel and make a call. But of course you will be able to do by yourself.... But we are also not able to prevent your from sending your AGI tokens to non existed address...
-> 2.) I agree that whitelist for creating new organization will solve a lot of problem.... But what about decentralization?
-> 1.) I think companies would want to avoid even this option. Because they might want to offer computational/running cost expensive services that they want to avoid being called without paying. The tools are open source so someone could modify them and then access them. -> 1.)2.) Would it be possible to have two separate smart contracts where one is filled with KYC customers and services where the MPE contract supports denies access and the current one? People could then decide where they want to register.
To allow the limitation of access to services it would be a great feature to enable the whitelisting of Ethereum addresses. Using this mechanism service providers can limit access to their service to certain parties. It has to be possible to add/remove addresses.
The same mechanic can be used to limit the possibility to add new services to the registry. This makes it possible to create a registry where only services of KYC approved providers are available.
To still retain the openness whitelist registries and non-whitelist registry can exist in parallel. And apps like the marketplace can show all non-whitelist registries + the services that whitelist the currently used Ethereum address.
If this access mechanism would be done by the service itself there would always be a payment and transaction but after that the service would decline the execution. This would lead to the necessity of refunds and worsen the user experience.
@IbbyBenali - this would enable a 2-way KYC process for the marketplace.