We can discuss about Oracle HTTP Protocols here:
With protocols we should implement in HTTP?
(Main topic discussion Syscall and ApplicationEngine https://github.com/neo-project/neo/issues/1275)
(Initial discussion https://github.com/neo-project/neo/pull/1243#discussion_r347915530)
Summarized by Erik:
Supported schema: http, https, neofs
Supported http methods: GET, POST*
*Whether or not to support POST is still controversial.
My opinion.
We should allow GET and POST. Because are the most common used, and also, sometimes the API (like our RPC), required to send a little information by POST.
We should support http and neofs. Another protocol we need to consider is https.
For http and https, I think we only need to support GET.
For neofs, we need a URI standard. Please discuss here: #1256
According to W3Tech report more then 56% of websites use https by default, so https support is a must, not an option, even for just getting information from regular web sites.
Because Smart Contracts most probably would interact with dApp backends, there also must be support for at least both POST and GET verbs, because it's part of JSON RPC standard and both POST and GET are used in most REST APIs.
Agree with @realloc
Agree, https should be default, and we will need GET/POST for REST,and standard auth. neofs and http will also be fundamental. @shargon any way we can.enforce name resolution via dnssec? It could be important too, although oracle voting.may also "fix" this (or not).
any way we can.enforce name resolution via dnssec?
I am not sure if dotnet core allow this, but we can try it
In fact, I think that we should only allow HTTPS schema, and not HTTP
Tech benefits:
Economic benefits:
Agree with @shargon . We should allow https only.
Good, I also think that https is much better. Yet, if its self signed certificate, or "untrusted" entity, one should pass the allowed identification for the oracle to know what to expect... would this be passed on tx header as well? It could be good I think.
Maybe we need to have a built-in trusted certification authority list? Otherwise, non-determinism may occur.
If we need everyone to share the same rules, I suspect this should be done inside a smart contract, like the network policy smart contract.
Isn't this a basic requirement for id systems?
It has been decided to start with the implementation of HTTP-GET.
Once finished, continue with HTTP-POST, HTTP 2.0, ...
I would also like to define the different limits and how are we going to store these values (oracle policy?)
@belane Hi,Belane. I think we should add a GRPC protocol. Have you started?Or NGD can help to implement.
For NeoFS Oracle there is no need for generic grpc protocol support. Please see NeoFS protocol bindings, there is C# support. Additionally we are preparing a wrapper library for C# with more http-like abstraction layer,
Look forward to publishing as a Nuget package.
@belane Hi,Belane. I think we should add a GRPC protocol. Have you started?Or NGD can help to implement.
gRPC sounds cool @doubiliu. No, I hadn't thought about it, do you think we should prioritize it over others?
Can be synchronized, if your time is priority, ngd can help to achieve it
I don't think gRPC is our priority, so don't implement it yet.
I think that NeoFs maybe only will require POST for upload the files, is this correct? @realloc
For NeoFS Oracle there is no need for generic grpc protocol support. Please see NeoFS protocol bindings, there is C# support. Additionally we are preparing a wrapper library for C# with more http-like abstraction layer,
I tried to find the protocol bindings without luck, can you share the direct link please?
@shargon, Not exactly. NeoFS can't be used via http gate from within the Smart Contract or Oracle, so http POST would not work. There should be a separate NeoFS Oracle using NeoFS API directly. Semantically it would be very similar to http PUT, but implementation is different.
We plan to release updated C# bindings early next week, but current quarantine measures may slow us down a little.
NeoFS can't be used via http gate from within the Smart Contract or Oracle...
Why not?
@erikzhang It would break the decentralized nature of NeoFS integration with Neo. While NeoFS network is decentralized and all nodes speak the same NeoFS API, http gates are separate single instanced applications. They do not form any resilient decentralized network, they just proxy requests.
@shargon I think it's okay. We access NeoFS through this form of URI:
neofs://{containerId}/{objectId}
It has nothing to do with http.
grpc looks like to be a good idea, https://github.com/NeoResearch/libbft has been created using that.
Most helpful comment
According to W3Tech report more then 56% of websites use https by default, so https support is a must, not an option, even for just getting information from regular web sites.
Because Smart Contracts most probably would interact with dApp backends, there also must be support for at least both POST and GET verbs, because it's part of JSON RPC standard and both POST and GET are used in most REST APIs.