oasislabs / oasis.js Goto Github PK

Implement https://github.com/oasislabs/oasis-client/blob/master/src/oasis-gateway/developer-gateway/http.ts#L34

See https://github.com/oasislabs/oasis-client/blob/master/src/coder/encoder.ts#L63.

• RPC
• Subscription

Let's punt this until return output from the transaction oasislabs/oasis-gateway#10 is addressed. Labeled as blocked.

Looks like it broken after making the change to lerna

Once the developer gateway implements the getPublicKey endpoint, we should validate signatures returned from the key manager for both the existence or non-existence of a key.

With the change in #66, we inserted dummy links for npm packages, since we haven't yet published. Once we publish, we should update these links. See https://github.com/oasislabs/oasis-client/pull/66/files#diff-04c6e90faac2675aa89e2176d2eec7d8R13.

Implement https://github.com/oasislabs/oasis-client/blob/master/src/oasis-gateway/developer-gateway/http.ts#L43

After discussion, @eauge and I decided that the client should generate a session key for the user and include that in its requests to the developer gateway.

TODO:

• Generate UUID upon creation
• Include the UUID in the header of each request to the developer gateway
• Define how to prevents clients from accessing other client's sessions

Currently we are fetching the transaction receipt by polling up to 5 times after a deploy. See #102.

Instead, before executing the raw transaction, we should implement a subscription for new blocks, send the deploy out, and then search for the receipt in the new block subscription.

need to use deoxysii to encrypt and decrypt calls to confidential contracts

Until there's a way to automatically determine the address-level conflict set of transactions, the user needs to specify these manually. There should be a way to send the conflict set to the gateway using the client.

Re: https://github.com/oasislabs/runtime-ethereum/issues/782

We should have e2e tests using all components together.

Given I'm a developer,
When I call an Oasis Service rpc method with an invalid input,
Then I should receive a useful error.

Potential test cases:

  
  it('throws an exception when the incorrect type is given to an rpc', async () => {
    // Given.
    let service = new Service(idl);

    // When.
    let input1 = defType();
    let input2 = 'hi';
    let promise = service.rpc.the(input1, input2);

    // Then.
    return expect(promise).rejects.toEqual(
      new Error(`Invalid arguments ${JSON.stringify([input1, input2])}`)
    );
  });

• Validate RPC arguments
• Validate deploy arguments

We should implement and support a web3 backend for the client so that it can talk directly to web3 gateways.

TODO:

• New implementation of the OasisGateway interface.
• Propagate service options to the gateway backend, i.e., add an optional "options" parameter to all service rpcs.

Should be part of the CI build

Need to relay serialized requests over the client-[devserver] protocol

• RPCs

@willscott @ryscheng please add a LICENSE to this repo.

All http requests to the developer gateway specifiy 'X-OASIS-INSECURE-AUTH': 'example'. See https://github.com/oasislabs/oasis-client/blob/master/packages/developer-gateway/src/session.ts#L19.

@eauge can you comment on the appropriate path forward here? I.e., what is this field used for and should we make changes here?

TODO:

• rpcs + http protocol to dev-server #3
• get public key #37
• update idl #26
• generate sighash from idl #15
• oasis-gateway deploy #42
• integration tests #31
• subscribe #38
• confidential data wire format #50 < 1 day
• UUID session #51 ~3 days +- 2 (blocked)
• docs #29 ~ 2 days
• web3 backend #52 ~ 5 days
• license #92 < 1 day
• 'X-OASIS-INSECURE-AUTH': 'example' #90 ~1 day
• developer gateway needs a timeout policy #82 ~1 day
• #109
• decode responses #57 ~ 1 day (blocked)
• rpc serialization #85 (blocked)
• update readme links #68 < 1 day
• publish on npm #88 < 1 day
• confidential flows
• e2e tests in CI oasislabs/e2e-tests#93
• deploy build to cdn #158
• replace mantle references with new name #156
• yarn lock security alerts #154

need either a wasm compilation of http://github.com/oasislabs/serde_eth or an alternative implementation to be able to serialize called methods into byte code.

parse an ABI and export methods & events.

support:

await mycontract.method(arg1, arg2);

mycontract.addEventListener('event', myHandler);

Because we need an issue for everything ;)

WebSocket analog to #3.

• RPCs
• Event subscriptions

We can do invoke with http now that we have an endpoint in the oasis_namespace.

Currently, we will add a deploy header with confidential set to true when using an ethereum gateway. This doesn't make sense for the new runtime,.

Instead, we should use default Ethereum semantics. To do this, we probably want to move the prepending of the deploy header to the initcode to be within the RpcCoder interface so that we can just ignore the header from the EthereumGateway and use it from an OasisGateway.

Proposed format: public key || cipher length || aad length || cipher || aad || nonce || signature

Cipher length and AAD length are both encoded u64 to keep the cipher 16 byte aligned.

Currently, we have some utility modules that dispatch based based upon whether we're in a browser environment or not. We should be able to remove these by configuring Rollup to import the modules correctly.

For example, we we import tweetnacl like this with this file.

Also our EventEmitter imports need fixing (e.g., see #25), as they are causing us to use any types.

Given I'm a developer,
When I create a Service object with an invalid IDL,
Then I should receive a useful error.

Currently we "discover" confidentiality by querying getPublicKey.

With the new key manager, this is no longer acceptable because all contracts have keys. Instead, we'll have to check the deploy header via inspecting the code.

Given an IDL,
When I construct a Service at runtime,
Then I should be able to make RPC calls to the service.

Currently the client just polls the developer-gateway forever until it gets the response back.

We should have a policy for when to give up and throw an error.

Scoped to the front end interface.

The idl format changed in oasislabs/oasis-rs#71.

We should update all our tests to use it and ensure it works.

Currently we just treat them like any types and use ts-ignore so that we can use both ethabi and our idl. E.g., see: https://github.com/oasislabs/oasis-client/pull/59/files/d72208174387ef67c3fb1068e51c44422da8dec0#diff-e0ff952460fd1c3469846bbde8376004R16. We should do this better.

can the test logic be separated from the browser html / scaffolding?

_Originally posted by @willscott in https://github.com/oasislabs/oasis-client/pull/66/files/244333a267421975fdc07d7dd7688d26bc831a90#diff-902ccfe3f360efb98e79a69b7643d161R13

Implement HTTP and WS versions of something like

export interface Provider {
  // Data in the transaction field.
  send(request: RpcRequest): Promise<any>;
  subscribe(request: SubscribeRequest): EventEmitter;
}

Should probably have invoke semantics.

• RPCs
• Subscriptions

For example, to point to a custom network, all Service's must be instantiated with a gateway pointing at a desired network, e.g., new oasis.Service(idl, address, { gateway}). Similarly, for key storage.

If no such options are specified, default ones are used here.

It would be nice if clients could override default options with a custom set, so that instantiating (and deploying) new Services used such default options. This would dry up code with repeated instantiations/deployments of different services, so that the above code turns into new oasis.Service(idl, address).

• p1: update docs depending upon marketing names
• p1: update docs after publishing to CDN
• p1: document http headers for dev gateway (i.e. for the change here: de69353)

We need mechanisms to authenticate the user. One mechanism that we have is google auth. However, to make testing easy, and be able to have multiple users, we have 'X-OASIS-INSECURE-AUTH': 'example', so that we can have multiple users providing a different value so that their sessions will not collide.

In the case of NilAuth, which is another auth that @willscott added, collisions are avoided by making sure that sessions are always different. For the developer gateway though, all users will be the same user when using NilAuth.

In my opinion we may need to define an authentication mechanism that we can use at least for staging to make our lives easier, which still provides authentication but not tied to google oauth.

Originally posted by @eauge in #90 (comment)

• Sample app that goes with quick start guide

oasisclient is unidiomatic. oasis-client isn't descriptive enough since there is, in fact, a rust client.

Add a deploy endpoint to https://github.com/oasislabs/oasis-client/blob/master/src/oasis-gateway/index.ts#L8

For the developer gateway, we mostly get this for free with the implementation of the RPC endpoint.

• IDL used in the constructor should be generic https://github.com/oasislabs/oasis-client/blob/master/src/service.ts#L51 and the resultant parsing of the IDL should be generalized as well. See RpcCoder.
• RPC encoding should be pluggable to support ethabi

We should consider using something like https://greenkeeper.io/ to ensure our dependencies are kept up to date.

Blocked by spec here oasislabs/oasis-rs#119