kadena-community / kadena.js Goto Github PK

Is your feature request related to a problem? Please describe.
When building a transaction we want to be able to sign with WalletConnect

Describe the solution you'd like
The same interface implementation that accepts IPactCommand as signWithChainweaver

https://github.com/kadena-community/kadena.js/blob/master/packages/libs/client/src/signing/signWithChainweaver.ts

Steps

1. Create a common interface that can support all sorts of signing
2. Implement the interface for singWithWalletConnect
3. Rebuild signWithChainweaver so it complies with this interface from step 1

edit: I see further down that you did add multiple its in one describe, so maybe just ignore this comment if it's intentional

I see you've added describe to all the tests individually. I'm not sure if my explanation was clear enough, that there can be multiple its in one describe. E.g.:

describe('subject under test', () => { 
  it('behaves in a certain way', () => {}); 
  it('behaves in another way with other variables', () => {}); 
})`. 

I'd say subject under test would here be devnet?
And one of the behaviours would be receives request key, on /send request of simple transaction
And another would be: receives the expected transaction result, on /local request of simple transaction

(see attachSignature.test.ts and base64UrlEncode.test.ts )

I'm not yet familiar enough with the context, so this might be semantically incorrect?

Originally posted by @alber70g in #26 (comment)

remove sigs and hash and cmd when a non-malleable transactionbuilder gets changed

Currently, when code is generated and placed in .kadena/client-generated, it's not available in the build.
It would be better to run it in the build with the generated code so it can be tested as a whole.

Same applies to [@kadena/pactjs-test-project]

add support for pacts (for crosschain transfers)

Is your feature request related to a problem? Please describe.
A change should always have a change log for a PR so when releasing these changes can be published

Describe the solution you'd like
Add rush change --verify to the PR. This command fails if a developer modifies a public package without providing related change files.

Instead of storing cmd and hash in the class PactCommand it might be better to use getters for cmd and hash. This could prevent malicious actions.

For that we need the nonce to be created with a getter as well.
And we need to extend the _unfinalizeTransaction function to reset the nonce when the Builders state changes from unmalleable to malleable.

Is your feature request related to a problem? Please describe.

Compatibility: Kadena client currently does not conform Pact.lang.api
Functionality Some enforced functionality should be optional

suggestion:
-- un- deprecate pact-lang-api until compatibility layer has been provided

Describe the solution you'd like
Compatibility:

Currently the major wallets make use of the pact-lang-api but kadena client only support signing with chainweaver (quicksign) in order to enforce current project to make use of kadena.js a adaptor should be provided ensure the backwards compatibility of the project. This adaptor is a separate later ensuring the cleanness of kadena client.

Functionality:
Kadena client enforces decimals when typeof x === 'number' this is okay for coin.TRANSFER but assumably not for other functions were you might want to provide for example an integer.

Additional context
I will extend this thread with other findings if needed.

What article is affected?

https://github.com/kadena-community/kadena.js#installing-prerequisites

What part(s) of the article would you like to see updated?

Requirements
node > LTS (node 16, as 18 isn't yet LTS)

install node
n lts // installs 18

suggest "n 16" instead

Additional information

No response

Describe the solution you'd like
Add functions that each create different types of keysets with predicateskeys-any, keys-all, keys-2

Add the UTCTime type to the PactLiteral sum type that matches its JSON serialization from here: https://github.com/kadena-io/pact/blob/master/src/Pact/Types/Codec.hs#L113

I'm creating this issue as a way to discuss the following problem:

As I'm working with the integration tests and devnet, I am having to wait a bit for blocks to come in since devnet is not as fast in producing "blocks" as pact-server.

In the code I'm setting a couple of sleep timers for some arbitrary time. This is a point of indeterminism.
I've seen this when working with /poll, /listen, and /spv endpoints.

A helper function that can be given one of the api fetch functions and that utilizes both a time-based and a block-based exponential backoff would be useful in this situation.

What article is affected?

https://github.com/kadena-community/kadena.js#installing-prerequisites

What part(s) of the article would you like to see updated?

Requirements
node > LTS (node 16, as 18 isn't yet LTS)

install node
n lts // installs 18

suggest "n 16" instead

Additional information

No response

PactCommand.finished(apiHost: string, interval: number = 5000, timeout: number = 120000)

• apiHost endpoint where pact lives
• interval how often the /poll call is done
• timeout when it stops polling, rejects when transaction goes over timeout
• returns Promise<IFinishedResult> when the transaction is finished.

Describe the bug
When generating types for a contract, the capabilities for that contract are taken into consideration. However types for capabilities in other contracts are not, for example coin.GAS.

Expected behavior
A suggested approach is to merge the capabilities of subsequent contract generation calls.

https://github.com/typicode/husky/tree/main/docs#install-1

disable postinstall script using pinst. Otherwise, postinstall will run when someone installs your package and result in an error.

Add Module Reference type to the PactValue sum type that matches its JSON serialization from here:
https://github.com/kadena-io/pact/blob/af024887dfd8eab522e2687bab586ee2b090557f/src/Pact/Types/PactValue.hs#L127

kadena-io/chainweb-node#1585

In Chainweb 2.17, we removed error reporting from /send. However, we didn't have "best simulations" for users to try their code out in as close to real world context as possible. /local used to fill this gap, but it was not robust enough. This PR enhances the /local endpoint to allow the user toggle on or off "preflight" (as close as we can get to mainnet) simulations, as well as the ability for the user to specify rewinds and simulation at a particular block height, and the ability to bypass user signature verification.

The usage is thus:

The behavior of the bare /local endpoint has not changed, allowing people to keep their work flows.
The /local?preflight=<bool> query flag allows people to run their commands against the full mainnet workflow. If false or left unspecified, reverts to the legacy behavior (running a tx through the interpreter to get outputs)
The /local?rewindDepth=<word (non-negative integer)> parameter allows people to rewind to a particular block height rewindDepth-many block heights in the past and run their commands (think: regressing against forks). If left unspecified, defaults to running at the most current block height on that chain.
The /local?signatureVerification=<bool> query flag allows people to run their commands with or without user signature verification (useful in the case of detached signature signing). If unspecified, defaults to verifying the tx.
An example full query would be /local?preflight=true&rewindDepth=100&signatureVerification=true to run a full command workflow at a blockheight 100 heights in the past, with full signature verification.

KadenaJs needs to support these new query parameters for the local call.

What article is affected?

https://github.com/kadena-community/kadena.js/blob/master/README.md

What part(s) of the article would you like to see updated?

I have no idea how to run tests for any of the libraries.

I feel that this should be in the readme, or at least linked to in the readme.

Due to this fact, I am unable to contribute properly to the repo, as one of the requirements is to "run the appropriate tests".

Additional information

No response

PactCommand.setApiHost(apiHostTemplate: string)

• apiHostTemplate is a string that contains {apiVersion} {networkId} and {chainId} and will be used when .local() .send() and .poll() are called.

tx.setApiHost("https://api.testnet.chainweb.com/chainweb/{apiVersion}/{networkId}/chain/{chainId}/pact")

Some users like me would like to use the client library without using "contract parsing" nor "template based".

I've found out that the PactCommand class was very convenient to use directly.

I'm pretty sure, that most devs (like me), prefer to use PactCommand, and writing a couple of Pact lines, in their JS source,
than using an heavy infrastructure of contract downloading/parsing... or writing templates.

Why not describing this class usage in the README.md ?

Originally posted by @alber70g in #25 (comment)

Yes that's a good one. Maybe we need to work on a base set of types to be used. I'm not a big fan of a separate types library. They can become overused, especially when they're broader than what's used in a function.

E.g.

// defined in @kadena/types
export type SomeGenericType = {
  name: string;
  color: 'blue' | 'red' | 'green';
};


// defined in @kadena/some-lib
import type { SomeGenericType } from '@kadena/types';

function getName({ name }: SomeGenericType) {
  return name;
}

In this example the SomeGenericType is way to broad for the usage. I'd rather have it exported and defined specifically, than made generic:

// defined in @kadena/some-lib
export type MySpecificType = {
  name: string;
};

function getName({ name }: MySpecificType) {
  return name;
}

Also, api-extractor can manage the type defenition .d.ts. generation based on public, alpha, beta, non-private JS/TSdoc

The way @kadena/client was designed is to use Pact.modules.<module>.<defun>(args). However, we can also use it as just a transaction builder, and customize the PactCommand.code property. Therefore, it would be good to separate the PactCommand-builder from the code-generated version.

Topics to consider:

• should PactCommand be in a separate library
• should we include the "default" coin caps in the PactCommand so that PactCommand.addCap will be strongly typed for the coin module

What article is affected?

https://github.com/kadena-community/kadena.js/blob/master/README.md

What part(s) of the article would you like to see updated?

The Getting Started portion feels incomplete to me.

I tried running rush add -p @kadena/types but I get this error:

ERROR: The "rush add" command must be invoked under a project folder that is registered in rush.json unless the --all is used

So, my files have errors in them, they can't import the @kadena/types or other things.

I would recommend cloning the repo, deleting rush from the global npm area, and starting from scratch for the setup. I'm certain there are more steps that I am unaware of.
I have also NEVER used rush. I tried reading the getting started with rush, but that wasn't helpful.

Additional information

No response

Add the Object Map of PactValue type to the PactValue sum type that matches its JSON serialization from here: https://github.com/kadena-io/pact/blob/1c517a906b2b6d0c8a4cdb107ffbc00887a9ac62/src/Pact/Types/Term.hs#L612

I changed the tag to tools. Should I also move it into the tools subdirectory in /packages?

Originally posted by @LindaOrtega in #26 (comment)

[@kadena/pactjs] add relevant tests to reach treshold

What article is affected?

Cookbook README

What part(s) of the article would you like to see updated?

I would love to see a super basic example of how to make a hello world on the /local endpoint without using the 'full option' of pulling contracts and generating types.
"Hello world" could look like this gist

Additional information

No response

null types are discouraged. They can be replaced by undefined unless they're needed by the API. Then we can parse the undefined to null

Originally posted by @alber70g in #26 (comment)

Is your feature request related to a problem? Please describe.
Currently the caps are not included when loading a contract that has a dependency on another contract. They can be added to the type definition by generating the types for the depending contract, but this is not automated.

Describe the solution you'd like
Automate the retrieval and generation of dependent contracts. It would be good to combine this in one step as mentioned in #173

Describe alternatives you've considered
-

Additional context
Keep in mind that currently the generated types are automatically merged. When a command automatically retrieves their dependencies, this should not be merged, as each contract will have it's own dependencies, hence its own required caps

Libraries based on what pact-lang-api used to have

• @kadena/cryptography-utils contains encode/decode/hash utils
• @kadena/chainweb-node-client typed js wrapper with fetch to call chainweb-node API endpoints.
  This will probably have some breakdown
  • blockchain wrapper around chainweb-node p2p api endpoints
  • pact https://api.chainweb.com/openapi/pact.html
  • rosetta https://api.chainweb.com/openapi/#tag/rosetta
• @kadena/chainweb-data-client typed js wrapper with fetch to call chainweb-data API endpoints
• @kadena/pactjs-client wrapper around chainweb-node-client with ability to switch environments etc. Removed in favor of @kadena/chainweb-node-client/pact
• @kadena/wallet-client client for wallet to sign, connect, retreive account info, etc
• @kadena/marmalade-client specific client for marmalade/NFTs
• @kadena/types common used typescript definitions. Preferably this will all move to the low-level libraries. Whenever you build something on top of those, you can use those types.
• @kadena/pactjs-utils low level pact utils (like PactNumber, createExp, keySet, ...) Renamed to @kadena/pactjs
• @kadena/chainweaver-client typed js wrapper with fetch to call chainweaver endpoints
• ====
• @kadena/pactjs runtime for generating pact expressions Renamed to @kadena/client
• @kadena/pactjs-cli cli to generate pact contract type definitions and interface to pact client. deployment of contracts, etc
• @kadena/pactjs-generator library that creates typescript definition from contract, template, etc
• .kadena/pactjs-generated library that does not exist on npm.
  It is generated by @kadena/pactjs-cli and @kadena/pactjs-generator and is a dependency of @kadena/pactjs(to be @kadena/client)
• @kadena/transaction-templates a supportive library for transactions. As there is no way to determine from pact alone which caps are needed for a given transaction, and in turn which signatures are needed, we want to provide the community a way to "publish" templates. These templates can be used by @kadena/pactjs-cli to generate the necessary typescript definitions
• packages/kadena.js do not depend on this package, as it's leftovers from when we started with the kadena-community/kadena.js monorepo

@LindaOrtega, @ggobugi27, @jmininger, @buckie can you review the libs and what we think that the contents should be, if that's correct?

// JSON blob that will export all the functions so we can generate the types from this file - chainweaver add button

{
  crypto: { // @kadena/cryptography-utils
    binToHex: binToHex,
    hexToBin: hexToBin,
    base64UrlEncode: b64url.encode,
    base64UrlDecode: b64url.decode,
    base64UrlEncodeArr: b64urlEncodeArr,
    base64UrlDecodeArr: b64urlDecodeArr,
    strToUint8Array: strToUint8Array,
    uint8ArrayToStr: uint8ArrayToStr,
    hash: hash,
    hashBin: hashBin,
    genKeyPair: genKeyPair,
    restoreKeyPairFromSecretKey: restoreKeyPairFromSecretKey,
    sign: sign,
    signHash: signHash,
    verifySig: nacl.sign.detached.verify,
    verifySignature: verifySignature,
    toTweetNaclSecretKey: toTweetNaclSecretKey
  },
  api: { // @kadena/chainweb-node-client
    prepareContCmd: prepareContCmd,
    prepareExecCmd: prepareExecCmd,
    mkSingleCmd: mkSingleCmd,
    mkPublicSend: mkPublicSend
  },
  lang: { 
    mkExp: mkExp, // will be removed, replaced by @kadena/pact-core
    mkMeta: mkMeta, // removed
    mkCap: mkCap // @kadena/chainweb-node-client
  },
  simple: { // @kadena/pact-client or @kadena/pact-core ?
    cont: {
      createCommand: simpleContCommand
    },
    exec: {
      createCommand: simpleExecCommand,
      createLocalCommand: prepareExecCmd,
      createPollRequest: simplePollRequestFromExec,
      createListenRequest: simpleListenRequestFromExec
    }
  },
  fetch: { // @kadena/chainweb-node-client
    send: fetchSend,
    local: fetchLocal,
    poll: fetchPoll,
    listen: fetchListen,
    spv: fetchSPV
  },
  wallet: { // @kadena/wallet-client
    sign: signWallet,
    sendSigned: sendSigned
  },
  cut: {  // @kadena/chainweb-node-client
    current: chainweb.cut.current
  },
  event: { // @kadena/chainweb-node-client
      range: chainweb.event.range,
      recent: chainweb.event.recent,
      stream: chainweb.event.stream,
      height: chainweb.event.height,
      blockHash: chainweb.event.blockHash,
  }  
}

mkdir contracts
npx @kadena/pactjs-cli retrieve-contract --out "./contracts/coin.module.pact" --module "marmalade.fixed-quote-policy"
npx @kadena/pactjs-cli contract-generate --file "./contracts/coin.module.pact"

Types are generated with IFixed-quote-policyCaps

Is your feature request related to a problem? Please describe.
When providing an index file to expose a public API for the contents of a directory, users are still able to import items from the index file and from any of the files within the directory. This allows users to export and use private items that are only intended to be used within the parent directory elsewhere.

Describe the solution you'd like
Restrict the export of items from a directory if an index (barrel) file is present

Describe alternatives you've considered
-

Additional context
Similar to this, however we would want the restriction to be applied depending on the existence of the index.ts file
https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-internal-modules.md

When importing integers and decimals, add following checks:

• Enforce that a Number that exceed safe integer limits should be represented as a PactInt or a PactDecimal. The isSafeInteger function might be useful here.

• Enforce that strings passed to the mkPactInt and mkPactDecimal are valid integers/decimals.

Add Guard of PactValue type to the PactValue sum type that matches its JSON serialization from here:
https://github.com/kadena-io/pact/blob/master/src/Pact/Types/Term.hs#L662

Is your feature request related to a problem? Please describe.
It's a best practice to pre-flight every single command with /local (with the caveat that some failures are still impossible to trigger in local)

Describe the solution you'd like
When calling /send first call /local when succeeded actually call /send

https://github.com/kadena-community/kadena.js/blob/master/packages/libs/chainweb-node-client/src/pact/send.ts#L41

Fix so that this package isn't so big when publishing. It now includes the following directories which can be excluded

• .heft/build-cache
• .rush/temp
• temp

Is your feature request related to a problem? Please describe.
Currently the commands are split up between retrieval of the contract and generation of the typings

Describe the solution you'd like
I like to have one command for retrieval and generation

Describe alternatives you've considered
Running both after one another but this requires the storing of a file.

Additional context
Related to this is the namespace that's not included in the retrieved contract. So the namespace is lost in type generation. See also #127

I think most packages will be used in both node and web environments. Therefore we need to make sure they are both web and node compatible.

Libraries like node-fetch can not be used in that case. As an alternative we could use cross-fetch

We also have to think of a way of assuring this is the case, with tests or otherwise.

• add web-lib profile to heft-rig
• change node-fetch to node and web compatible lib
• buffer is not browser compatible

  kadena.js/packages/libs/cryptography-utils/src/hexToBin.ts

  Line 7 in 76f148c

  return new Uint8Array(Buffer.from(hexString, 'hex'));

• #77
• Find out whether we can run our tests on headless chrome, next to node, so we don't have to have separate e2e tests

Add an example to the docs/tutorials on how to run a local Pact command.

const ENDPOINT = isTestnet ? "testnet." : "";
const CHAIN_ID = 0;
const NETWORK_ID = isTestnet ? 'testnet04' : 'mainnet01';
const API_HOST = `https://api.${ENDPOINT}chainweb.com/chainweb/0.0/${NETWORK_ID}/chain/${CHAIN_ID}/pact`;

const command = new PactCommand();
command.code = `(coin.get-balance "k:${publicKey}")`;
const { result } = await command.local(API_HOST);

if (result.status !== "success") return 0;
return result.data

eg pactjs contract-generate --file ../pact/stake-for-steak.pact

This module is in the free namespace

Is your feature request related to a problem? Please describe.
When creating a new app in KadenaJS monorepo we have to copy paste a lot of files/rules. This should be done by command line tooling.

Describe the solution you'd like
Add tooling where we can run a add-kadenajs-project command to copy all monorepo setup data to a project/lib

Hi, am trying to follow the pact election dapp tutorial which has been awesome (https://github.com/kadena-community/docs/blob/master/docs/build/guides/building-a-voting-dapp.md), but am having an issue with the frontend.

pactjs contract-generate --file ../pact/election.pact; pactjs contract-generate --file ../pact/election-gas-station.pact; pactjs contract-generate --file ../pact/root/coin-v4.pact

The above command throws a syntax error

Any form of help would be appreciated.
thank you.

What article is affected?

The README.

What part(s) of the article would you like to see updated?

To me, the purpose of the README is twofold:

1. Provide people who want to use the repo the information they need to get started.
2. Build the path and documentation that allows people to contribute to the repo itself.

To facilitate the above, I feel that the following pieces must be in place:

1. A clear description of the repo and its purpose.
2. A clear definition on everything the repo contains. I've made improvements already in #168 and @alber70g suggested doing something like this, which I am 100% on board with.
3. Step by step instructions on how to setup the repo so that others can easily contribute. I personally feel like this shouldn't be so complex that you need a separate .md file called CONTRIBUTING. Just put it all in the readme. The CONTRIBUTING file can be used to list off the current things that are being developed perhaps, but HOW you contribute should just be in the README.

Max Howell, the creator of Homebrew told me "I build the way to contribute to the tool, into the tool itself".
If we can make it so easy for people to request or suggest changes to KadenaJS that they almost have no excuse not to, we will have succeeded in building a tool that can be run by the community of people who use it.

I'm open to other things you guys feel a repo needs, these 3 things are a starting point. They need to be built into the readme, like needing to run rush change in my repo to create the logs of the changes that can be used to update the documentation. This should 100% be in the "contribution" area.

Additional information

No response

I started on a tool that, based on Typescript definitions, would be able to generate Pact expressions.

Inspired by Prisma ORM, that generates a type-safe client based on a database schema (see example)

We would be able to generate a type definition from all modules available on the blockchain (edit: using ASTs from Pact(?)). This allows users to make the right type-safe calls. Those are intercepted by a Proxy, that returns either Pact code or even a client that can execute the call to the chainweb-node API.

PoC: #45

This could be something like

const generator = Pact.coin.transfer("k:sender", "k:receiver", 4.5)
generator.client({ chainId, networkId }).sign().call() // create client, maybe sign, and post to chainweb-node
generator.generate() // returns (coin.transfer "k:sender" "k:receiver" 4.5)

Thoughts:

• we could generate the client as well instead of using a Proxy (I believe Prisma generates their client as well. Not 100% sure though)
• the generator could be completely separate from the client
• ...

Is there a specific reason to depend on the ~ only patch updates of this package? Otherwise we might change this to ^. I believe rush install -p <package> in the package directory does that automatically?

Also, I think this should not be a devDependency, as it's needed during the runtime of the package (i.e. running tests)

Originally posted by @alber70g in #26 (comment)

To describe the relation, this would be better.

Right now PactNumber is only wrapping the bignumber.js library. It would be nice if this is exposed, or PactNumber inherits from bignumber.js so it can be used in calculations and doesn't need to be converted back and forth.