-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Oracles] Supported Protocols #1260
Comments
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 For For |
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). |
I am not sure if dotnet core allow this, but we can try it |
In fact, I think that we should only allow 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. |
It has been decided to start with the implementation of HTTP-GET. 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. |
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
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. |
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:
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. |
We can discuss about Oracle HTTP Protocols here:
With protocols we should implement in HTTP?
(Main topic discussion Syscall and ApplicationEngine #1275)
(Initial discussion #1243 (comment))
Summarized by Erik:
Supported schema:
http
,https
,neofs
Supported http methods:
GET
,POST
**Whether or not to support
POST
is still controversial.The text was updated successfully, but these errors were encountered: