We have recently added (near/nearcore#1910) a new RPC API method: changes.

Read more here: near/docs#173

Quering ${path} failed should be Querying ${path} failed

https://github.com/nearprotocol/nearlib/blob/d8b0f397fdf6a0729d293660e3c4dda153ea314e/src.ts/providers/json-rpc-provider.ts#L53-L59

For example when tx fails, get an error like this:

Uncaught (in promise) Error: [-32000] Server error: [object Object]
    at JsonRpcProvider.sendJsonRpc (nearlib.js:767)
    at async Account.signAndSendTransaction (nearlib.js:83)
    at async Contract.value [as incrementCounter] (nearlib.js:269)

If the user is logged out:
near.account() won't work with an empty string
nearlib.Contract() won't work without an account

Thus you can't call contract view functions if the user is not logged in, which isn't good UI (i.e. for guestbook you can't see guestbook entries if you're not logged in).

Desired behavior:
Contract view functions should be able to be called when logged out

Discussion:
Potentially creating some sort of 'read-only' account as a placeholder for guest

We need a wallet injection API that existing wallets that have dApp browser can leverage to integrate with apps.

For example:

• https://github.com/polkadot-js/extension

not sure where to document this exactly, here or nearprotocol/near-shell

i started by creating a new account through NEAR Shell

near create_account sherif3 --masterAccount=sherif

and ended up trying to recover the account via NEAR Wallet and getting [this error](https://github.com/nearprotocol/nearlib/blob/d8b0f397fdf6a0729d293660e3c4dda153ea314e/lib/account.js#L34)

Missing public key for sherif3 in default

Error in background action: BadRequestError: Error: Failed to fetch access key for 'sherif3' with public key ed25519:EsjyvmBb2ESGiyjPHMBUnTGCe1P6hPjmxxY2b2hrTBAv

could mean one of:

• i'm not supposed to do this [!/images/icons/emoticons/warning.png!| /images/icons/emoticons/warning.png]
• we need clearer message in NEAR Shell about how to "attach" a created account to your wallet
• we need clearer message in NEAR Wallet about how to recover accounts created via NEAR Shell

also related to this flow, the error only appeared in the console. no SMS was sent while trying to recover and this error did not appear anywhere in the DOM. generally SMS messages were arriving for another accounts while following the same steps to recover it: sherif2. but that account was originally created via the NEAR Wallet interface on another computer.

The new structured errors are implemented in #163. We cant' enable the new errors format as long as all nodes are not upgraded with near/nearcore#1854

https://github.com/nearprotocol/nearlib/blob/cf9aa908a6205d7175c6b25224b6c20e2f348e36/src.ts/providers/json-rpc-provider.ts#L74-L83

We need to have an easy way to sign transactions when there is no access to the blockchain from the SDK. For example, by providing the last block hash through API.

@vgrichina commented on Thu Feb 14 2019

Need to use real browser, e.g. through https://github.com/GoogleChrome/puppeteer

@evgenykuzyakov commented on Tue Mar 12 2019

@azban I think you are already working on this.

@azban commented on Tue Mar 12 2019

this is done here.. i need to integrate this into CI tho. https://github.com/nearprotocol/integration/blob/master/integration/tests/integration/test_integration.py#L52

@evgenykuzyakov commented on [Thu Feb 21 2019](near/nearcore#604)

—

@vgrichina commented on [Thu Feb 21 2019](near/nearcore#604 (comment))

It's better to use specialized tool like https://sentry.io/

—

@evgenykuzyakov commented on [Thu Feb 21 2019](near/nearcore#604 (comment))

Nice. Whatever is better, let's add it.

the error message reported in the snippet below would be clearer to me if it read "Missing private key ..." since the signer is failing to fetch a private key from the keystore with signer.getPublicKey
https://github.com/nearprotocol/nearlib/blob/d8b0f397fdf6a0729d293660e3c4dda153ea314e/src.ts/account.ts#L56-L60

is this because i'm still confused about how keys work? it's possible 😕

or maybe is "Missing public key ..." somehow the canonical way to report that "a private key was not found locally and so no associated public key could be retrieved" or something?

running dist script requires downgrading bs58 to 3.0.0.

• Way too many boilerplate to connect with default settings / using config file.
• waitForTransactionResult should be built-in in regular API, is too low-level for most use cases
• Provide ActiveObject-like API similar to ethersjs?
• Provide Web3 shim?

Hard to interpret error messages like:

Error: [-32603] Internal error: Tx (00) not found

Once 0.4.0 is merged to master in nearcore we can remove some legacy code, e.g. adaptTransactionResult, fixLegacyBasicExecutionOutcomeFailure, and mapLegacyTransactionLog.

After near/nearcore#1999 it will be impossible to get blocks at old heights. The test providers.test.js should be changed. Change may look like the following:

There are Signature types right now in nearlib, which should be somehow simplified. It makes documentation about offline signing not very consistent (also transactions.Signature is not exported, but is needed for SignedTransaction construction).

Similar to near/near-wallet#219.

Expected behavior
When entering an invalid (non-existent) contractId argument in nearlib.WalletAccount.requestSignIn, the developer should receive an error.

Right now keystore only has message signing and signature verification but doesn't have anything related to encryption/decryption.

Currently, when the network is slow and RPC times out during transaction confirmation, the end result is an error message, with no indication or whether or not the transaction was successful.

See #258 in near-wallet for a related error.

We're showing a deprecation warning for the contract wrapper recommended in the docs.

near.loadContract is deprecated. Use `new nearlib.Contract(yourAccount, contractId, { viewMethods, changeMethods })` instead.

We should either change the example in the docs, or remove the deprecation warning from near.loadContract

@vgrichina commented on Fri Feb 15 2019

Test is currently whole wall of code with few unrelated tests jammed together:

    test('make function calls', async () => {
        const args = {
            'name': 'trex'
        };
        const viewFunctionResult = await nearjs.callViewFunction(
            contractName,
            'hello', // this is the function defined in hello.wasm file that we are calling
            args);
        expect(viewFunctionResult).toEqual('hello trex');

        var setCallValue = await generateUniqueString('setCallPrefix');
        const setArgs = {
            'value': setCallValue
        };
        const scheduleResult = await nearjs.scheduleFunctionCall(
            0,
            aliceAccountName,
            contractName,
            'setValue', // this is the function defined in hello.wasm file that we are calling
            setArgs);
        expect(scheduleResult.hash).not.toBeFalsy();
        await nearjs.waitForTransactionResult(scheduleResult);
        const getValueResult = await nearjs.callViewFunction(
            contractName,
            'getValue', // this is the function defined in hello.wasm file that we are calling
            {});
        expect(getValueResult).toEqual(setCallValue);

        // test that load contract works and we can make calls afterwards
        const options = {
            viewMethods: ['hello', 'getValue'],
            changeMethods: ['setValue'],
            sender: aliceAccountName
        };
        const contract = await nearjs.loadContract(contractName, options);
        const helloResult = await contract.hello(args);
        expect(helloResult).toEqual('hello trex');
        var setCallValue2 = await generateUniqueString('setCallPrefix');
        const setArgs2 = {
            'value': setCallValue2
        };
        const setValueResult = await contract.setValue(setArgs2);
        expect(setValueResult.status).toBe('Completed');
        const getValueResult2 = await contract.getValue();
        expect(getValueResult2).toEqual(setCallValue2);
    });

compare to other tests, e.g.:

    test('can get logs from method result', async () => {
        await contract.generateLogs();
        expect(logs).toEqual([`[${contractName}]: LOG: log1`, `[${contractName}]: LOG: log2`]);
    });

@ilblackdragon commented on Tue Mar 26 2019

@janedegtiareva any update here?

question

why to we sometimes call nearlib methods with a hash as string and other times use a hash as UInt8Array?

detail

JsonRpcProvider has several methods for fetching network info including fetching a block by "id" which can be an integer or hash (as string), a chunk by hash (as string) and transaction by hash (as UInt8Array).

class JsonRpcProvider extends Provider {
  async block(blockId: BlockId): Promise<BlockResult> {}
  async chunk(chunkId: ChunkId): Promise<ChunkResult> {}
  async txStatus(txHash: Uint8Array, accountId: string): Promise<FinalExecutionOutcome> {}
}

sample code that exercises these methods require some inconsistent thinking in terms of the interface and this adds friction to learning

for example,

retrieving a block

// using the previous snippet to pull the latest block hash
let chain = (await near.connection.provider.status()).sync_info
let id = chain.latest_block_hash
// let id = chain.latest_block_height // <-- this also works here

// we can pass the results to the provider.block method
await near.connection.provider.block(id)

retrieving a chunk

// assume here we use the block data above to fetch chunks from the block
// and identify this chunk hash as interesting ...
let hash = "6SrBkhwVLAZC2YQJG3YUSef2UGf7UxwpsLZEY3dsZMKb"
await near.connection.provider.chunk(hash)

--> and here's the inconsistency <--

retrieving a transaction

// assume here we find a transaction in the chunk above that we want to inspect
// but we can't use the txHash directly, we have to decode it
let txHash = "3L37n7LowxfpFEJcQvYmoQPo4NpgV2ZUmr4vXSBYhxPL"
let decodedTxHash = nearlib.utils.serialize.base_decode("3L37n7LowxfpFEJcQvYmoQPo4NpgV2ZUmr4vXSBYhxPL")
await near.connection.provider.txStatus(decodedTxHash, '')

this may be my misunderstanding but why can't we just use the transaction hash here directly? seems like we're just encoding it again inside the implementation (and accountId accepts an empty string so i'm not sure why that's even exposed in this interface)

async txStatus(txHash: Uint8Array, accountId: string): Promise<FinalExecutionOutcome> {
    return this.sendJsonRpc('tx', [base_encode(txHash), accountId]).then(adaptTransactionResult);
}

a naive glance (i don't know Rust) at the nearcore JSON RPC client decodes the transaction hash again (and seems to require the accountId parameter)

async fn tx_status(&self, params: Option<Value>) -> Result<Value, RpcError> {
  let (hash, account_id) = parse_params::<(String, String)>(params)?;
 
  /// @amgando --  this line seems to decode the transaction again
  let tx_hash = from_base_or_parse_err(hash).and_then(|bytes| {
    CryptoHash::try_from(bytes).map_err(|err| RpcError::parse_error(err.to_string()))
  })?;
  let result = self
    .client_addr
    .send(NetworkClientMessages::TxStatus {
      tx_hash,
      signer_account_id: account_id.clone(),  /// @amgando -- not sure why account_id isn't just an empty string here
    })
    .compat()
    .map_err(|err| RpcError::server_error(Some(convert_mailbox_error(err))))
    .await?;
  self.tx_polling(result, tx_hash, account_id).await
}

get nonce(): number { return this._accessKey.nonce; }

Something as simple as this would allow the nonce to be retreived from the account object, which would allow some more complex "sign then send" functions

I would like to bring an issue of presenting NEAR amounts that are small or can be rounded incorrectly.

Here are the test cases:

• 1 yoctoNEAR is currently formatted as 0 NEAR; There are two better ways to format 1yoctoNEAR (I believe both are useful in different contexts):
  • 1 yoctoNEAR / 1 yN
  • <0.00001 N / "less than 0.00001 N"
• 999999999999999999999999 yN is rounded to 1 N. It is hard to find the best way to present this value, but here is my take:
  • "almost 1 N"
  • "0.999999 .. 1 N"
  • "1 N without 1 yN" 😕

Ref near/near-explorer#152

    /**
     * Encode a buffer as string using bs58
     * @param {Buffer} buffer 
     * @example
     * KeyPair.encodeBufferInBs58(key.publicKey)
     */
    static encodeBufferInBs58(buffer) {
        const bytes = Buffer.from(buffer);
        const encodedValue = bs58.encode(bytes);
        return encodedValue;
    }

Stuff like this should be inside the bs58.encode() function instead of outside, bs58 should auto determine the type is Buffer or Uint8Array. Maybe use a forked bs58 with this update?

Or get a base58 lib that supports uint8array buffers.

This can be addressed by making there is a singleton connection and cache the nonce (e.g. in local storage).

If I load a contract that only has view methods:

const contract = await near.loadContract("hello-world", {
  viewMethods: ["helloWorld"]
});

It fails at runtime as follows:

nearlib.js:265 Uncaught (in promise) TypeError: Cannot read property 'forEach' of undefined
    at new Contract (nearlib.js:265)
    at Near.loadContract (nearlib.js:666)
    at main.js:12

I always have to supply an array of change methods, even if there aren't any, to keep nearlib happy:

const contract = await near.loadContract("hello-world", {
  viewMethods: ["helloWorld"],
  changeMethods: []
});

Could changeMethods default to an empty array if not supplied by the user?

Nearlib expected to be used by DApps and DWallets and it functionality should cover:

• Blockchain structure:
  • Block header by (block.number or block.hash)
  • Shard header by (block and shard.index) or shard.hash
  • Transaction header by (shard and transaction.index) or transaction.hash or account.nonce or address.nonce
  • Transaction header by (shard and transaction.index) or transaction.hash
  • Latest block number
  • Main coin balance
  • Merkle proofs of different structures
• Account management:
  • Transaction internal and external (hardware wallets) signing
  • Custom message signing similar to EIP-712
• Smart contract interaction:
  • Calling view methods of smart contract without on-chain tx
  • Creating transactions by forming method call arguments

Throws an error
SyntaxError: Unexpected end of JSON input
at JSON.parse ()

  at Account.viewFunction (node_modules/nearlib/lib/account.js:140:21)

this is reproducible via running unit tests for template 01 in near studio.

The default amount of gas for function call is too small and developers often have to set this value manually. Since the unused gas will be returned it seems reasonable to pass in maximum allowed amount of gas for function calls.

There are few things we want to improve:

Configuration search:

• For Node.js use cases, search for .near/ folder with config and keys. Main uses cases:
  • local to project (so go up to folder with node_modules / package.json and check for .near). This can be official TestNet and custom network.
  • running node connected to official TestNet (~/.near/ for configs). Want to use it, but need to use contract helper for account creation.
  • running custom network with local node (~/.near/ for configs). Want to use local key pair for account creation.
• Create various types of transactions functions that support creating and signing transactions (without having connection).
• ConnectProvider interface that various providers like RPC, RPCv2, Network, WebSockets can implement (e.g. current NearClient is RPC provider). Provides sendTransaction(txBytes, [timeout]) -> Promise<FinalTransactionResult> and query(path, data) -> Promise<QueryResult> interfaces.
• AccountCreatorProvider - interface, that either uses helper or given keys to create accounts.
• connect that is configured / or searches for configuration and uses given ConnectProvider, AccountCreatorProvider and KeyStore.
• Account abstraction, that provides accessors to account state (balance, etc), access keys (with permissions per key), etc. Allows to initialize Contract with it to send Tx from it.
• Wallet API is defined via 2 URLs: "Authorize App" API and "Sign Tx" API.
• Contract handles itself sending to Wallet if currently signed Tx is not allowed by access key or access key is missing.
• KeyStore should have some form of Wallet to provide what are current accounts available for given network, and allow to change accounts and networks. Also this should use Wallet API to "login" to retrieve current account id if unavailable.

Seems like a good solution to avoid nonce collisions, proposed by @ilblackdragon

https://github.com/nearprotocol/nearlib/blob/master/lib/account.js#L66

@vgrichina thoughts?

@DanielRX

This is needed ASAP. So please prioritize this

Protos are part of the specification that different components of the system use.
We should have them in separate repo, that also provides Rust, JS, Python, etc packages that ppl can use without needing to re-build them.

Should just retry with proper nonce when possible. Otherwise any concurrent request break apps.

steps to recreate

1. use nearlib to call any contract method with incorrect or non-existent named argument

the error will appear in the client-side JS console

why/where/when did this happen?

this happened by accident while following the [Zero to Hero](https://docs.nearprotocol.com/docs/tutorials/zero-to-hero) tutorial in our docs

 // incorrect (will reproduce this error)
 await contract.setResponse(

 { string: "here we are" } 

)

// vs

// correct (will not produce the error)
 await contract.setResponse(

 { apiResponse: "here we are" } 

)

detail

i think this is the right place to submit this since nearlib could handle this error gracefully but i don't see enough information in the error message to be useful to the developer.

failed transaction on TestNet [here](https://explorer.nearprotocol.com/transactions/9c5JPRgKeAdWrw2GW6YChukDHJUxdSw76AQzfAgoNopV)

this error appears in the

Uncaught (in promise) Error: Transaction 9c5JPRgKeAdWrw2GW6YChukDHJUxdSw76AQzfAgoNopV failed. WebAssembly trap: unknown Error: Transaction 9c5JPRgKeAdWrw2GW6YChukDHJUxdSw76AQzfAgoNopV failed. WebAssembly trap: unknown
at Account.signAndSendTransaction (nearlib.js:97)
at async Contract.value <span class="error">[as setResponse]</span> (nearlib.js:294)
at /app/gbgfhnucs/async <anonymous>:1
TypedError @ nearlib.js:763
signAndSendTransaction @ nearlib.js:97

Object.keys(contractObj) returns ['account', 'contractId'] when it should return all methods on the contract object.

We should consider separating construction and signing of transactions so that unsigned transactions can be passed to signers not on the same device for example.