encointer / encointer-js Goto Github PK

Now that the tests are fixed after #15 is merged, we should also have some e2e tests here in GithubActions

Perform some basic actions in the tests:

• transfer, query storage, some encointer-pallet calls
• important: test custom rpc's of the encointer node.

Right now, we have a mixture of base58 and hex formats for input/output arguments, I would suggests, that we keep it unified, maybe in base58?
This is the case:
Custom Rpc call: bazaar.getAllBusinesses(cid) expects hex format
Custom rpc call communities. communities.getAll()
Returns to be determined
Gesell node client: list-businesses flag expects cid in base58 format
Gesell node client: get communities: returns communities in hex format

As of v.3.3 the tests do not run anymore. This is like due to a change in the build-process.

We never tested the worker since we added the TLS into the enclave with the self-signed certificate. I guess, the websocket lib has an issue with self-signed certs. See, error:

As polkadot-js/apps already supports it, it should just be a matter of upgrading the @polkadot deps.

• Closes #106

Currently we have defined our fixed point types like:

BalanceType: i128

but what is returned from the chain is:

BalanceTypeChain: {
     bits: i128
}

We need to somehow align this properly such that:

• To the outside; the developer does not see a difference, whether he is using encointer-js or polkadot-js/api directly.

Which basically means that we need to change the encointer-js code to BalanceTypeChain as arguments and return values of its function.

We need to update the code at several places to fix that.

#48 extracts computeMeetupIndex and was loosely tested to fix #43.

However, more testing is needed:

• correct index for reputables
• correct index for endorsees #51
• correct index for newbies #51

After upgrading the encointer-wallet I get the following build-warnings:

WARNING in ./node_modules/@polkadot/types-known/upgrades/index.js 62:25-27
"export 'BN' was not found in '@polkadot/util'
 @ ./node_modules/@polkadot/types-known/index.js
 @ ./node_modules/@polkadot/api/base/Init.js
 @ ./node_modules/@polkadot/api/base/Getters.js
 @ ./node_modules/@polkadot/api/base/index.js
 @ ./node_modules/@polkadot/api/rx/index.js
 @ ./node_modules/@polkadot/api/index.js
 @ ./src/service/settings.js
 @ ./src/index.js
 @ multi ./src/index.js

WARNING in ./node_modules/@encointer/worker-api/index.js 2:0-93
"export 'CallOptions' was not found in './interface.js'
 @ ./src/service/settings.js
 @ ./src/index.js
 @ multi ./src/index.js

WARNING in ./node_modules/@encointer/worker-api/index.js 2:0-93
"export 'IEncointerWorker' was not found in './interface.js'
 @ ./src/service/settings.js
 @ ./src/index.js
 @ multi ./src/index.js

WARNING in ./node_modules/@encointer/worker-api/index.js 2:0-93
"export 'PubKeyPinPair' was not found in './interface.js'
 @ ./src/service/settings.js
 @ ./src/index.js
 @ multi ./src/index.js

WARNING in ./node_modules/@encointer/worker-api/index.js 2:0-93
"export 'WorkerOptions' was not found in './interface.js'
 @ ./src/service/settings.js
 @ ./src/index.js
 @ multi ./src/index.js

WARNING in asset size limit: The following asset(s) exceed the recommended size limit (244 KiB).
This can impact web performance.
Assets:
  main.js (1.71 MiB)

WARNING in entrypoint size limit: The following entrypoint(s) combined asset size exceeds the recommended limit (244 KiB). This can impact web performance.
Entrypoints:
  main (1.71 MiB)
      main.js

Our node-rsa implementation has been working some years ago, see encointer/encointer-wallet-flutter#124.

However, it seems that meanwhile there are some issues with it. I can't create encrypted blobs that can be understood by the worker, even though I am using the same code as we used back then in the encointer-wallet. There error is thrown here on the worker side.

Litentry seemed to have failed getting encryption to with the node-rsa module too, and they could finally get it to work with the node-js built-in crypto module, integritee-network/worker#987 (comment). However, this lacks browser support.

I will try to get it to work some more, before I start looking for alternatives, wip in: #89

Migrate the stuff from polkadot-js/apps here, so we can just import the library there.

See polkadot-js/apps#8425.

This is what we want to be able to do: https://github.com/polkadot-js/apps/blob/396a87743e3ab283e93d7426671ffe8232f526a5/packages/apps-config/src/api/spec/acala.ts#L4

breaking change in encointer/pallets#373

explorer shows zero reputables on gesell now. use bot-satellite (atlantic) community for testing
https://explorer.encointer.org/?rpc=wss%3A%2F%2Fgesell.encointer.org

• community storage in geohash buckets (cid's can't be fetched from chain state anymore. only rpc)
• CID format change

Seems quite straightforward to use

https://www.npmjs.com/package/json-rpc-2.0

The initial implementation of the encointer-worker implicitly assumed that the community identifier is kind of the shard of the integritee worker. In the worker api rework in #89, I have in some places abused the community identifier to be the shard vault. This dirty use should be fixed.

Since integritee-network/worker@0af6918, we use TLS directly into the enclave.

We have never tested if this works with the current implementation here. Maybe we don't need any changes at all.

encointer/encointer-node#204

This test reproduces the phenomenon from encointer/encointer-wallet-flutter/issues/374

The same account is returned multiple times.

• lerna version --force-publish updates the versions in the package.json file and performs a commit + push to the repository.
• a subsequent build for the packages to be published, changes the package-info.ts files due to the new version.

Hence, to publish the package, we need two commits currently. Maybe we should do it manually again to be able to do it in only one commit?

As our flutter app and the explorer share the need to use the worker-api for Cantillon support, it would make sense to publish a npm package for this.

We have an organization registered at npmjs.com

see pallet changes in
encointer/pallets#336

Due to latest Encointer node use Metadata V13 polkadot.js packages need to be updated.

• assignment calculation client side

Since paritytech/substrate#8615, metadata includes all info necessary to derive type definitions. We should drop our custom typedefs

Manual release procedure can go wrong, e.g., one can forget to run yarn install before running the release cycle locally.

Instead, the npm relase cycle should be triggered in the CI when a github release has been created.

encointerBalances_getAllBalances
ceremonies_getReputations

https://github.com/encointer/encointer-node/releases/tag/v0.8.0

The incognitee-frontend currently fails to instantiate the worker:

The support for the worker has been removed from the encointer-wallet app a while ago, but maybe this pr contains some relevant information for a missing polyfill or something the like: encointer/encointer-wallet-flutter#1538

This has either to do with:

• #69
• #70
• #71

ERROR: Unable to load user definitions: Must use import to load ES Module: /home/clang/code/encointer-js/packages/types/src/interfaces/definitions.ts
require() of ES modules is not supported.
require() of /home/clang/code/encointer-js/packages/types/src/interfaces/definitions.ts from /home/clang/code/encointer-js/node_modules/@polkadot/typegen/cjs/fromDefs.js is an ES module file as it is a .ts file whose nearest parent package.json contains "type": "module" which defines all .ts files in that package scope as ES modules.
Instead change the requiring code to use import(), or remove "type": "module" from /home/clang/code/encointer-js/packages/types/package.json.

Edit: After some investigation I can say that this is due to #70.

Should try to fetch the community specific demurrage or fallback to the runtime const, see encointer/explorer#68

Already existing logic in encointer-wallet-flutter:

https://github.com/encointer/encointer-wallet-flutter/blob/916ec20cc4f3289a2467d14dc27750369441a2b4/lib/js_service_encointer/src/service/encointer.js#L130

There are no unit tests for that, and we got an error of an invalid location while submitting attestations, most likely due to bad parsing of negative lattitudes

We need to query 4 registries (bootstrapper, reputable, endorsee, newbie) for each call. A convenient wrapper would be nice.
The return value should be (#bootstrappers, #reputables, #endorsees, # newbies)

The current integration tests are very limited because it runs on a node without any communities.

This should not happen because we ignore the build folder [here], and I double-checked that the directories are correctly resolved. I don't know why we still run into this error.

Workaround: run yarn clean to delete the build folders before running tests

This is more a note to self, as I have run into this twice already when updating the dev-deps.

In the conversion from string to fixed-point values, we parse the string to a float. In theory, this can be inconsistent.

The runtime validates the locations in the attestations exactly. So if a discrepancy occurs, the attestation is invalid. So far, this has not been observed.

The question is whether we care about an exact transform, or if we just allow for slight discrepancies when validating the fixed point number in the location.

We do this manually, and there seems to be a change in the formant, so we fail, and get the can't extract error error.

since encointer/pallets#165 we now have a possible offset defined on meetup time and we have to support this in encointer-js to have valid meetups

See: encointer/encointer-wallet-flutter#1521 (comment)

We should either throw an exception in these cases or return an Option<MeetupIndexType>

run unit tests as GH action

#89 fixed the worker implementation for recent integritee-workers in general, but the encointer implementation is still not complete and is dangling in a state in between. To make the encointer-worker work, we need:

• Make some functions needed in sending TrustedGetters and TrustedCalls more generic, such that we can create encointer types instead of integritee types depending on the contexts (currently only integritee types supported).
• Probably update the type definitions for the encointer types