but messages transactions (value=0) works.

thread 'main' panicked at 'index out of bounds: the len is 1 but the index is 1', /home/xxx/.cargo/registry/src/github.com-1ecc6299db9ec823/iota-model-0.3.0/bundle.rs:96:18

This part of the code is wrong

pub fn add_trytes(&mut self, signature_fragments: &[String]) {
    let empty_signature_fragment = "9".repeat(2187);
    let empty_hash = EMPTY_HASH;
    let empty_timestamp = 999_999_999;

    for (i, bundle) in self.0.iter_mut().enumerate() {
        let new_sig = if signature_fragments.is_empty() || signature_fragments[i].is_empty() {
            &empty_signature_fragment
        } else {
            &signature_fragments[i]
        };

It's not possible to use the index of the bundle iteration to access the signature_fragments!

Sending message transactions (value=0) with send_transfers(None) does not work.
I always got "Error: Must provide seed to prepare transfer"

The error also occurs with your provided example "message_transfer.rs"

CI jobs should report failed immediately when an error occurred.

If I send a transaction with a long message that doesn't fit into a single signatureMessageFragement, a second transaction is created with the same bundle hash, but at the same index 0 instead of 1:
https://thetangle.org/bundle/CGGYHCWAABKSHHBIQYIIOOHKKKQSFBXRJOEKEXGNVVHVLEHIIUKPBBSHFNSHKCPLEAKGZEVKZHHHPCGPZ

Bug description

Building bindings/wasm fails.

Specification

macOS Catalina 10.15.4
What hardware are you using?

Steps To reproduce the bug

Explain how the maintainer can reproduce the bug.

1. Navigate to bindings/wasm/
2. Run yarn

Expected behaviour

It should successfully build for node & web platforms

Actual behaviour

Running yarn build fails with the following error:

yarn run v1.21.1
$ yarn build:web && yarn build:nodejs
$ wasm-pack build --target web --out-dir wasm-web && node ./build/web
[INFO]: 🎯  Checking for the Wasm target...
[INFO]: 🌀  Compiling to Wasm...
   Compiling clear_on_drop v0.2.3
   Compiling serde_json v1.0.53
   Compiling wasm-bindgen-macro v0.2.62
   Compiling iota-common-preview v0.1.0
   Compiling failure v0.1.8
error: failed to run custom build command for `clear_on_drop v0.2.3`

Caused by:
  process didn't exit successfully: `/Users/foo/workspace/iota.rs/bindings/wasm/target/release/build/clear_on_drop-5c1a578bdb052915/build-script-build` (exit code: 1)
--- stdout
TARGET = Some("wasm32-unknown-unknown")
OPT_LEVEL = Some("3")
HOST = Some("x86_64-apple-darwin")
CC_wasm32-unknown-unknown = None
CC_wasm32_unknown_unknown = None
TARGET_CC = None
CC = None
CFLAGS_wasm32-unknown-unknown = None
CFLAGS_wasm32_unknown_unknown = None
TARGET_CFLAGS = None
CFLAGS = None
CRATE_CC_NO_DEFAULTS = None
DEBUG = Some("false")
running: "clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-unknown-unknown" "-Wall" "-Wextra" "-o" "/Users/umairsarfraz/workspace/iota.rs/bindings/wasm/target/wasm32-unknown-unknown/release/build/clear_on_drop-e6a0d73c7f42615d/out/src/hide.o" "-c" "src/hide.c"
cargo:warning=error: unable to create target: 'No available targets are compatible with triple "wasm32-unknown-unknown"'
cargo:warning=1 error generated.
exit code: 1

--- stderr


error occurred: Command "clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-unknown-unknown" "-Wall" "-Wextra" "-o" "/Users/umairsarfraz/workspace/iota.rs/bindings/wasm/target/wasm32-unknown-unknown/release/build/clear_on_drop-e6a0d73c7f42615d/out/src/hide.o" "-c" "src/hide.c" with args "clang" did not execute successfully (status code exit code: 1).



warning: build failed, waiting for other jobs to finish...
error: build failed
Error: Compiling your crate to WebAssembly failed
Caused by: failed to execute `cargo build`: exited with exit code: 101
  full command: "cargo" "build" "--lib" "--release" "--target" "wasm32-unknown-unknown"
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Currently the bee crates already made some breaking changes, including

1. Need to switch to chrysalis-pt-2 branch.
2. Traits moved from the bee-common-ext to bee-common (like Packable).
3. The message builder and its fields has been enhanced.

w/o updating the corresponding iota.rs codes, the iota.rs cannot even compile if we use the latest bee crates.

We should re-export the crates users need to handle API. Add examples to show how to use them

Not all apis need to be verified from multiple nodes. Here's the list what we need at most:

• find_transactions
• get_balances*
• get_bundle
• get_inclusion_states
• get_inputs
• get_latest_inclusion*
• get_latest_solid_subtangle_milestone
• get_new_address
• get_trytes
• is_address_used
• is_promotable
• traverse_bundle
• were_addresses_spent_from*

*apis have quorum support in trinity #82

The library currently misses the implementation of the following methods:

• retry();
• reattach();
• promote().

The implementation details are added to the specification document. For a reference implementation, see:

• Determining if a message needs promotion or reattachment https://github.com/iotaledger/trinity-wallet/blob/develop/src/shared/libs/iota/transfers.js#L99-L139;
• How to reattach https://github.com/iotaledger/trinity-wallet/blob/develop/src/shared/libs/iota/extendedApi.js#L299-L332;
• How to promote https://github.com/iotaledger/trinity-wallet/blob/develop/src/shared/libs/iota/extendedApi.js#L211-L247.

Related: #150

/cc @cvarley100 @fijter @bingyanglin @wusyong

The readme doesn't make notice of the fact that the WASM binding is now available at NPM. This can be discovered by navigating to bindings/wasm, but in my opinion should be clear from the root readme.

Current interface of ternary crate is not that user friendly. We should define a higher abstraction instead of raw re-export. So it can be easier to work with.

• add_neighbors
• attach_to_tangle
• broadcast_transactions
• check_consistency
• find_transactions
• get_balances
• get_inclution_states
• get_neighbors
• get_node_info
• get_tips
• get_transactions_to_approve
• get_trytes
• remove_neighbors
• store_transactions
• were_address_spent_from

We should sync README like libraries in other languages to let users easier to start with.

When using the library with a single unsynced client it is impossible to make API calls.

e.g. Running a single local node for testing it is never in sync, so the following code always fails

const client = new ClientBuilder()
  .node('http://localhost:14265')
  .build();
const tips = await client.getTips();

The following error is returned.

Error: ClientTask error: Client(SyncedNodePoolEmpty)

This would also mean that if a node falls out of sync for any reason you can't use the API to diagnose the problem. You can't even call getInfo.

Bring back format check and maybe also add lint check.
We probably want to use other actions that won't break on stable release.

This lib only checks for balance and if an address was used for an outgoing value tx and both things are stored independent of snapshots/pruning

The minimal example in the readme.md is not up to date. It uses send_transfer instead of send_transfers. Further the method is missing an argument.

It would be nice if you can fix it, since I am a rust newb and can't get it to work myself. Thank you!

Streams team is experiencing an issue where using the iota.rs library call send hangs forever
https://github.com/iotaledger/iota.rs/blob/iota-1.0/iota-client/src/client.rs#L28
It seems like the issue is in reqwest or smol after a quick investigation, but this is unconfirmed.

If you want to recreate the issue all you need to do is:
Clone https://github.com/iot2tangle/Streams-http-gateway, and cargo run --release This will give you a channel root in the terminal, take that and put it to the side for now.

Send the curl command they have in their readme and run it 30-40 times to put some data into the channel
Clone https://github.com/iot2tangle/Example-streams-subscriber and cargo run --release [channel root here]

It will find just over 20 of the messages, and then it hangs
When we breakpoint our way through the process, we found that it was hanging on the findTransactions or getTrytes call from the iota.rs side while it uses the response! macro. Since it does this, and we await the response, our streams subscriber instance stalls out, and then so does the Example-Streams-Subscriber.
Because it doesn't return an error or an actual response, it's stuck awaiting forever

So the workaround we are thinking of applying is to timeout our calls to the client so that if it hangs, we can kill the call and return a timeout error on our end, as we've already tried adding a timeout into the client library itself, but it feels like it's just putting a bandaid on a potentially critical problem. On our end we do not utilize the async calls asynchronously, we await each one

We have tested this with different nodes.

Actual findings: (Dyrell)
24 successful rounds of 5 calls (4 find transactions and 1 get tryte)
then fails on the 4/5 call every time on the 25th round (so 124 seems to mean something?)

After inspecting network traffic with wireshark:
Red: Streams instance calls, Blue: Node responses
Small Responses: findTransactions, Big responses: getTrytes
PDF with data: packets.pdf
Explanation: All requests have a response, then the very last message (1124) is the FIN packet we send as there's no more connection (FIN ACK wasnt caught). Findings: All requests are send and we receive responses)

Actual findings: (Brord)
Example: Run the following in Example-streams-subscriber: cargo run --release 85f4e5ceedbab180cc7b2f117b86eaac2cf113b1a73d17bf90de1e44d7464c690000000000000000:b0a612fce2b888182963e792

It will stall out after receiving 17 messages, when fetching the data of the 18th. It finds the hash and then continues to call get_trytes, on which it stalls forever. (https://github.com/iotaledger/iota.rs/blob/iota-1.0/iota-client/src/client.rs#L342)

To clarify; it goes into our get_bundles method, does find_transactions, goes through handle_client_result, and passes the ensure!. Then it calls get_trytes and we wait forever.
streams get_bundles method: https://github.com/iotaledger/streams/blob/develop/iota-streams-app/src/transport/tangle/client.rs#L323

(Before sending the 18th message, it stalled on find_transactions in get_bundles, the second attempt. First time resulted in empty (no message), second one stalls)

The need-to-modify or unimplemented yet APIs follow

General API

• find_messages(): not implemented yet, need a wrapper and use the already implemented low-level APIs.
• get_address_balances(): Not implemented yet, need a wrapper and use the already implemented low-level APIs.
• retry(): Not implemented yet.

Full Node API

• find_outputs(): Not implemented yet, need a wrapper and use the already implemented low-level APIs.
• find_addresses(): Need rename it from get_addresses().
• reattach(): Not implemented yet.
• promote(): Not implemented yet.

All of the above are documented in the specification and should be implemented.

Current interface of bundle crate is not that user friendly. We should define a higher abstraction instead of raw re-export. So it can be easier to work with.

Deliver messages is not available for now. We should bring it back with message can be more than one transaction long.

use iota_client;

fn main() {
  println!("{:#?}", iota_client::get_node_info("https://nodes.comnet.thetangle.org".to_string()).unwrap());
}

thread 'main' panicked at 'called Result::unwrap() on an Err value: Error(Json(Error("missing field appName", line: 1, column: 80)))', C:\Users\Boss.cargo\registry\src\github.com-1ecc6299db9ec823\iota-client-0.1.0\lib.rs:272:44

Current send() implementation does not support the following parameters for a message with value transaction

1. output (Users can manually pick their own output instead of having node decide on which output should be used.)
2. indexation_key (An optional indexation key of the indexation payload.)
3. data (An optional indexation data of the indexation payload.)

Also, current output parameter in the send() is actually the address parameter defined in the spec, which is needed to be rename as address.

At the moment higher level APIs are under src directory. It would be better they are all under same crate with basic IRI APIs.

As @Alex6323 proposed previously, here's the lints tokio also uses. If this good to everyone, I'll start doing it.

#![warn(
    missing_debug_implementations,
    missing_docs,
    rust_2018_idioms,
    unreachable_pub
)]

For security content, the seed is sensitive data that should not put in the parameter of send_transfers if it's not used in the API.

It looks like iota-crypto/keccak.rs was lifted verbatim from the tiny-keccak crate. It ssems like this is okay under its very permissive CC0-1.0 license, but still not good style.

We should replace the code and link tiny-keccak directly for proper attribution.

Current client type is still fairly low level. We should provider a higher level abstraction for users. For now we want to have a node pool to let us choose random nodes, and a quorum setting to control how many nodes should it queries and how many should be considered as confirmed. The basic building structure looks like this:

struct IotaBuilder {
    node_pool: Vec<Url>, // Url type from hyper
    network: Network, // Network enum
    mwm: u8,
    quorum_size: usize,
    quorum_threshold: u8, // I don't like floating point here, maybe this can present as percentage.
}

impl IotaBuilder {
    // Fields will have default value when initializing
    fn new() -> IotaBuilder {
        IotaBuilder {
            node_pool: Default::default(),
            network: Network::Main,
            mwm: 14,
            quorum_size: 1
            quorum_threshold: 50,
        }
    }

    fn add_node(&self, node: Url) {
        self.node_pool.push(Url);
    }

    fn add_node_list() {
        todo!()
    }

    fn add_node_pool() {
        todo!()
    }

    // The instance is created here.
    fn build() -> Iota {
        todo!()
    }
}

1. In get_unspent_address(), the type of the returned tuple should be (Address, usize).
2. in get_output(), the input parameter type should be UTXOInput, and the returned type should be OutputMetadata

Since it's now under official Github, maybe it's a good time to rename it to be same as other language libraries like iota.js, iota.go etc. Perhaps revise README.md is also needed? 🤔

The following test is accepted:

assert!(input_validator::is_address(&"0".repeat(iota_constants::ADDRESS_LENGTH_WITHOUT_CHECKSUM)))

We use anyhow to easily propagate error for convenience. And there are some places we just unwrap/expect since we know the flow.
It would be better we have a concrete error type. And we will not need any error handling crate any more in this way.

This is the meta issue about wasm support. We should provide a binding crate under this workspace. The crate will provide the higher level intuitive abstraction to Javascript users.

Since updating to the latest release, I get the following error when including the library:

Uncaught (in promise) LinkError: WebAssembly.instantiate(): Import #53 module="wbg" function="__wbindgen_closure_wrapper1069" error: function import requires a callable

get_node_info() expect the node to return a set of fields related to the Java Runtime, jre*, however node software such as Hornet doesn't return these fields as it uses Go.

I'm a bit of a Rust noob, so forgive the obvious solution I'm missing, but would it be best to drop these fields entirely as node software moving forward such as Bee and Hornet wont have these included.

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error(Json(Error("missing field `jreAvailableProcessors`", line: 1, column: 655)))', /...../iota-client-0.3.0/client.rs:261:48
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Suggestion:

Make create_address and create_addresses functions public available.

So the API is more open for developers and they can create addresses from an index.

It seems like we lost the local POW functionality that was present in the old iota-lib-rs. Will it be reimplemented?

adds rustfmt checking and enhance the CI script.

Is there a reason why we can't just convert arbitrary binary data to trytes? The whole trytes_converter module seems overly complex to me, why do we have to use manual lookup tables from ascii to numerical values instead of just using str.bytes and converting? The latter change would also allow us to convert utf-8 to trytes.

yeah, TIL it exists.
https://github.com/iotaledger/iota.rs

net2 crate has been deprecated; use socket2 instead

The net2 crate has been deprecated
and users are encouraged to considered socket2 instead.

See advisory page for additional details.

I want to read the message from the transaction I sent.
Everything works fine if the message fits into a single transaction.
For larger messages I always get the error message "Invalid tail transaction supplied"

This line in traverse_bundle() seems to be the cause
ensure!(tx.current_index == 0, "Invalid tail transaction supplied.");

You cannot make this comparison >>> 'current_index == 0' <<< if you call this function recursively ...

The API responses are not validated in test cases. Tests should make sure responses are in the expectation.

I looked at the client-code, and at the getNewAddress-function and discovered a flaw compared to how the protocol has worked earlier.
There has never been any problems using security-levels above 3, they just don't gine any added security, but an address generated with securitylevel 4 or 5 would just need as many tx'es to publish the signature, and all parts of it would then be used to verify the signature.

At least this worked with IRI, and there has not been any mentions about changes in support for sec-levels above 3
samplebundle is KWCSPUKCALYCDPRGDWEVSU9HRIJWUDCXJCDYPCZZJSBDY9SYR9H9X99QWUHPLDDY9UVSBWAKHAZFKSCCC
just sendt and verified by hornet-nodes from an address created with sec-level 5 (using the old java-libs)

GetNodeInfoResponse {
    app_name: "HORNET",  
    app_version: "0.5.0",
    jre_available_processors: None,
    jre_free_memory: None,
    jre_max_memory: None,
    jre_total_memory: None,
    jre_version: None,
    latest_milestone: "RJKTKKROBIWONMGTMQBXFMZUAHRBOLJOBTEHAAZFI9OV9HQRKODILCEURPUWXNQDDPVEAHX9GJIVDW999",
    latest_milestone_index: 827485,
    latest_solid_subtangle_milestone: "RJKTKKROBIWONMGTMQBXFMZUAHRBOLJOBTEHAAZFI9OV9HQRKODILCEURPUWXNQDDPVEAHX9GJIVDW999",
    latest_solid_subtangle_milestone_index: 827485,
    milestone_start_index: 827177,
    neighbors: 3,
    packets_queue_size: None,
    time: 1598358375000,
    tips: 100,
    transactions_to_request: 0,
}

For comparison the result you get from the iota.js lib

{
 "appName": "HORNET",
 "appVersion": "0.5.1",
 "latestMilestone": "WK9SYZVXUNHERXALUCBLCJIKBNTKGUKADZKQMY9TMRHLFLQNXQOYRXZH9PJGVUPXKBSPWCJTTWFX99999",
 "latestMilestoneIndex": 1589390,
 "latestSolidSubtangleMilestone": "WK9SYZVXUNHERXALUCBLCJIKBNTKGUKADZKQMY9TMRHLFLQNXQOYRXZH9PJGVUPXKBSPWCJTTWFX99999",
 "latestSolidSubtangleMilestoneIndex": 1589390,
 "isSynced": true,
 "isHealthy": true,
 "milestoneStartIndex": 1587019,
 "lastSnapshottedMilestoneIndex": 1587019,
 "neighbors": 24,
 "time": 1598358203526,
 "tips": 146,
 "transactionsToRequest": 0,
 "features": [
  "LoadBalancer",
  "RemotePOW",
  "WereAddressesSpentFrom"
 ],
 "coordinatorAddress": "UDYXTZBE9GZGPM9SSQV9LTZNDLJIZMPUVVXYXFYVBLIEUHLSEWFTKZZLXYRHHWVQV9MNNX9KZC9D9UZWZ",
 "duration": 0
}

Here are the api in Trinity that need quorum support. The first module implementation should start with these at least:

• get_balances*
• get_latest_inclusion*
• were_addresses_spent_from*