iotaledger/streams

IOTA Streams, a framework for cryptographic protocols called Applications. Replaces Masked Authenticated Messaging (MAM). Alpha version.

A cryptographic framework for building secure messaging protocols

About ◈ Prerequisites ◈ Installation ◈ Getting started ◈ API reference ◈ Examples ◈ Supporting the project ◈ Joining the discussion

---

About

IOTA Streams is a work-in-progress framework for building cryptographic messaging protocols. Streams ships with a built-in protocol called Channels for sending authenticated messages between two or more parties on the Tangle.

As a framework, Streams allows developers to build protocols for their specific needs.

This process will be documented as the development progresses. However, since this crate is in an alpha stage of development it is still likely to change.

At the moment, IOTA Streams includes the following crates:

• Channels Application featuring Channels Application.
• Core layers featuring spongos automaton for sponge-based authenticated encryption, pre-shared keys, pseudo-random generator;
• Keccak for core layers featuring Keccak-F[1600] as spongos transform;
• Curve25519 asymmetric crypto featuring Ed25519 signature and X25519 key exchange;
• DDML featuring data definition and manipulation language for protocol messages;
• Application layer common Application definitions.
• Bindings.

Prerequisites

To use IOTA Streams, you need the following:

• Rust
• (Optional) An IDE that supports Rust autocompletion. We recommend Visual Studio Code with the rust-analyzer extension

We also recommend updating Rust to the latest stable version:

rustup update stable

Installation

To use the library in your crate you need to add it as a dependency in the Cargo.toml file.

Because the library is not on crates.io, you need to use the Git repository either remotely or locally.

no_std is currently supported. However cargo nightly must be used to build with no_std feature.

Getting started

If you don't have a rust project setup yet you can create one by running,

cargo new my-library

Remote Add the following to your Cargo.toml file:

[dependencies]
anyhow = { version = "1.0", default-features = false }
iota-streams = { git = "https://github.com/iotaledger/streams", branch  = "develop"}

Local

1. Clone this repository

   git clone https://github.com/iotaledger/streams

2. Add the following to your Cargo.toml file:

   [dependencies]
   iota-streams = { version = "0.1.2", path = "../streams" }

Getting started

After you've installed the library, you can use it in your own Cargo project.

For example, you may want to use the Channels protocol to create a new author and subscriber like so:

use iota_streams::app_channels::api::tangle::{Author, Subscriber};
use iota_streams::app::transport::tangle::PAYLOAD_BYTES;
use iota_streams::app::transport::tangle::client::Client;

fn main() {
    let node = "http://localhost:14265";
    let client = Client::new_from_url(node);

    let encoding = "utf-8";
    let multi_branching_flag = true;

    let mut author = Author::new("AUTHORSSEED", encoding, PAYLOAD_BYTES, multi_branching_flag, client);
    
    let mut subscriber = Subscriber::new("MYSUBSCRIBERSECRETSTRING", encoding, PAYLOAD_BYTES, client);
}

For a more detailed guide, go to our documentation portal.

API reference

To generate the API reference and display it in a web browser, do the following:

cargo doc --open

Examples

We have an example in the examples directory, which you can use as a reference when developing your own protocols with IOTA Streams.

A no_std version can be found in iota-streams-app-channels-example directory

Supporting the project

Please see our contribution guidelines for all the ways in which you can contribute.

Running tests

We use code comments to write tests. You can run all tests by doing the following from the streams directory:

cargo test --all

Updating documentation

If you want to improve the code comments, please do so according to the guidelines in RFC 1574.

Joining the discussion

If you want to get involved in discussions about this technology, or you're looking for support, go to the #streams-discussion channel on Discord.

streams's Issues

Changing a subscriber's secret key does not result in new messages

When you change the author's secret key, a new channel is created, which is correct behavior.

However, when you change the subscriber's secret key, messages with the same ID are created, which suggests that the secret key is not used and the seed is somehow hardcoded.

You can test this behavior by changing the subscriber's secret key in the following snippet and noting that the message ID does not change.

use iota_lib_rs::prelude::iota_client;
use iota_streams::app::transport::tangle::client::SendTrytesOptions;
use iota_streams::app_channels::{
    api::tangle::{Address, Transport, Subscriber}
    , message
};
use failure::{Fallible, ensure};

fn get_announcement_and_subscribe<T: Transport>(subscriber: &mut Subscriber, channel_address: String, announce_message_identifier: String, client: &mut T, send_opt: T::SendOptions, recv_opt: T::RecvOptions) -> Fallible<()> {

    // Convert the channel address and message identifier to a link
    let announcement_link = Address::from_str(&channel_address, &announce_message_identifier).unwrap();
 
    println!("Receiving announcement message");
 
    // Use the IOTA client to find transactions with the corresponding channel address and tag
    let list = client.recv_messages_with_options(&announcement_link, recv_opt)?;
    let mut found_valid_msg = false;
    for tx in list.iter() {
        let header = tx.parse_header()?;
        println!("Found and authenticated {} message", header.content_type());
        ensure!(header.check_content_type(message::announce::TYPE));
        subscriber.unwrap_announcement(header.clone())?;
        found_valid_msg = true;
        break;
    }
    ensure!(found_valid_msg);
    println!("Subscribing to channel");
    let subscription = subscriber.subscribe(&announcement_link)?;
    println!("Subscribe message identifier  {}", subscription.link.msgid);
    client.send_message_with_options(&subscription, send_opt)?;
    Ok(())
 }
 

fn main() {

    // Create a new subscriber
    let mut subscriber = Subscriber::new("CHANGEME", true);

    // Connect to a node and pass this object to the function
    let mut client = iota_client::Client::new("https://nodes.devnet.iota.org:443");

    // Subscribers need the channel address and announce message identifier to be able to subscribe to a channel
    let channel_address = "PDDEPZGGFQCMGQJBZEEZOJUQLANOMLFNCVOTJQQBPABFIAPVKLMLMOFKAUWYXSCZLKPKNLR9JPTKGLXVQ";
    let announce_message_identifier = "NIVMCSOJZHMVAQQHSBTMRKKVNNX";
        
    let recv_opt = ();

    // Change the default settings to use a lower minimum weight magnitude for the Devnet
    let mut send_opt = SendTrytesOptions::default();

    // default is 14
    send_opt.min_weight_magnitude = 10;
    send_opt.local_pow = false;

    match get_announcement_and_subscribe(&mut subscriber, channel_address.to_string(), announce_message_identifier.to_string(), &mut client, send_opt, recv_opt) {
        Ok(()) => (),
        Err(error) => println!("failed with error {}", error),
    }
}

Improve RNG

Description

Improve the use of RNG for key/nonce generation.

Motivation

Currently rand crate is used which provides limited capabilities for crypto RNG detection on different platforms. In no_std such detection is impossible, so a special solution is required.

Requirements

Write a list of what you want this feature to do.

1. Use getrandom crate (or crypto.rs if it's stable enough) in addition to rand crate for better detection of crypto RNG.
2. Implement global RNG initializable with secret key for no_std/generic platform.

Open questions (optional)

1. Stability of crypto.rs.
2. Do we actually need a generic RNG? Does esp32 have crypto RNG?
3. If so, RNG must use secret key and modifiable counter. How to securely store those? How to ensure counter gets always updated?

Are you planning to do it yourself in a pull request?

Yes.

Implement compilation to 32 bit

Description

Current streams compiles to 64 bit, but we need to support other targets like the following:

• i686-pc-windows-gnu, 32-bit MinGW (Windows 7+)
• i686-pc-windows-msvc, 32-bit MSVC (Windows 7+)
• i686-unknown-linux-gnu, 32-bit Linux (kernel 2.6.32+, glibc 2.11+)

Motivation

Smaller devices will need 32 bit compilation, for example the raspberry pi

Handle Binding Errors

Description

A unified structure for handling error's as they occur within the bindings will need to be created.

Motivation

Error handling is essentially non existent in the c bindings. These errors need to be caught, handled and some method standardised for users understanding these errors and what may cause them.

Requirements

• Catch and handle errors at the rust external api layer
• Return null for failed calls in c bindings

Open questions

Do we simply return null regardless of binding language?

failure is deprecated

failure has been deprecated a couple hours ago (See this commit), so we should probably switch to anyhow, which offers everything this project requires as far as I can tell.

cargo.toml dependencies section correction in documentation

[dependencies]
iota-streams = { git = "https://github.com/iotaledger/streams" }

will not work with the rest of the documentation

should read:

[dependencies]
iota-streams-app-channel = { git = "https://github.com/iotaledger/streams" }

[EPIC] Testing

Description

Time to develop a set of unit/benchmarking/regression tests to standardise updates for the library.

Motivation

While there have been a number of major updates to the code over the last few months, we have not developed a suite of tests and
testing tools to ensure stability and performance.

We will need benchmarking to compare the current implementation in binary with the previous Ternary version of the library, as well
as compare performance of point to point communication between devices over various iterations of node. For Ternary that will mean
using IRI, for binary that will be Hornet 0.5, and for future development that will mean Hornet with chrysalis pt 2 integration.

We also need regression tests to ensure that feature development does not break backward compatibility unless intended.

Unit tests are needed within each module to verify the performance of the individual components.

Requirements

• Unit tests for each core module
• Regression testing of p2p and p2mp operations as well as sequencing and client integration
• Benchmarking performance of p2p data transfer, ED25519 v WOTS, Binary v Ternary, encryption, spongos operations etc

Open Questions

• Which tests will be needed prior to chrysalis pt2 and which can be saved for after the transition?

[EPIC] Error Handling

Description

Error handling in the Streams library needs to be refactored on every level.

Motivation

Errors are not always handled in the most appropriate fashion. There are still several locations where a panic can cause a shutdown.
Error messages will need to be more descriptive to be useful and it's necessary to ensure we handle all errors propagated from our
dependencies. Furthermore we also need to ensure proper error handling in our bindings, which are currently lacking any proper handling
and instead result in panics from the internal functionality erroring out the implementation.

Requirements

• Refactor all panic based error handlers to one standard
• Propagating Dependency errors to the user
• Generate a centralised error handler
• Keep all error messages in easily found single location
• Handle errors on binding level
• Improve descriptions of errors

Open Questions

Failed to build using Remote dependencies

Bug description

When installing with the following in my Cargo.toml

[dependencies]
anyhow = { version = "1.0", default-features = false }
iota-streams = { git = "https://github.com/iotaledger/streams", branch  = "master"}

I receive the error below. Cloning the repo and installing works fine.

Which version of Rust are you running?

• Rust version: rust-1:1.47.0-1

Hardware specification

• Operating system: Arch Linux
• RAM: 8Gb
• Cores: 4
• Device: Macbook Pro

Steps To reproduce the bug

Explain how the maintainer can reproduce the bug.

1. Run cargo new my-library
2. Add to Cargo.toml

[dependencies]
anyhow = { version = "1.0", default-features = false }
iota-streams = { git = "https://github.com/iotaledger/streams", branch  = "master"}

2. Run cargo build

Expected behavior

Build correctly

Actual behavior

wil@taxi ~/D/i/secret (master)> cargo build
Updating crates.io index
Updating git repository `https://github.com/iotaledger/streams`
Updating git repository `https://github.com/iotaledger/bee.git`
Updating git repository `https://github.com/Alex6323/bee-p.git`
Updating git repository `https://github.com/iotaledger/iota.rs`
error: no matching package named `bee-ternary` found
location searched: https://github.com/iotaledger/bee.git?branch=dev
prerelease package needs to be specified explicitly
bee-ternary = { version = "0.3.2-alpha" }
required by package `iota-core v0.2.0-alpha.3 (https://github.com/iotaledger/iota.rs?rev=0ad8e7f#0ad8e7f7)`
    ... which is depended on by `iota-streams-app v1.0.0 (https://github.com/iotaledger/streams?branch=master#762142e8)`
    ... which is depended on by `iota-streams v1.0.0 (https://github.com/iotaledger/streams?branch=master#762142e8)`
    ... which is depended on by `secret v0.1.0 (/mnt/iota/secret)`

Fails to build.

Document PSK usage

Description

Pre-Shared Keys are another form of verification between subscribers/authors in a channel and have yet to be adequately discussed in our documentation. Usage and limitations of these psk's needs to be properly commented/documented for users.

Motivation

Pre-shared keys can be used to open a lot of potential functionality within Streams but hasn't been documented much.

Requirements

• Document usage of pre-shared keys in Author and Subscriber generation
• Document potential usages for pre-shared keys
• Add additional subscriber with PSK usage into examples

Open questions

Are there any additional restrictions we wish to impose on the PSK architecture? How will that effect the documentation?

Channels: Switch to Keccak as default PRP

Core: EdSig + EdDH

Support Edwards curve25519 based Schnorr signature and Diffie-Hellman key exchange.

As a channel author, I need to be able to restore my Merkle trees

If I were running a channel and my PC turned off, the state of my Merkle tree would be lost.
To start sending messages on my channel again (without reusing private keys), I'd need to be able to rebuild my Merkle tree.

We should add some sort of interface that allows us to rebuild the Merkle tree from a saved state.

Support async transport in Channels

Description

Implement async transport in Author/Subscriber API.

Motivation

Channels Author/Subscriber API is parametrized with Transport. Synchronous transport is supported for the moment. Asynchronous transport is (more) suitable for asynchronous/multithreaded applications, wasm and other targets willing to use asynchronous I/O.

Requirements

Write a list of what you want this feature to do.

1. Support async cargo feature in channels crate.
2. Support async in bindings.

Open questions (optional)

1. How does c should support async?
2. How does wasm should support async?

Are you planning to do it yourself in a pull request?

Yes.

Channels: Author/Subscriber state serialization

After the application shuts down the state is discarded so it's impossible to continue normal work. Need to add state serialization.

Secure zero secret/key memory

Description

Implement secret/key memory cleanup after use.

Motivation

Memory containing keys must be cleaned up in a secure manner. Otherwise it's susceptible to side-channel attacks.

Requirements

Write a list of what you want this feature to do.

1. Use zeroize crate.
2. Add special DDML type for secret keys that is dropped with zeroize.
3. Make sure key-related memory/data is cleaned up securely.

Open questions (optional)

1. Is DDML Key type for symmetric secrets enough?

Are you planning to do it yourself in a pull request?

Yes.

recv_messages.. and send_messages.. don't handle/propagate network errors

It sometimes happens that with a bad connection, recv_messages_with_options and send_messages_with_options fail with:
thread 'main' panicked at 'called Result::unwrap()on anErr value: Error(Json(Error("expected value", line: 1, column: 1)))', /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/iota-client-0.3.0/client.rs:328:46

This error can be traced back to:

/// Receive a message.
    fn recv_messages_with_options
    ....
        let find_resp = self.find_transactions(find_opt)?;
        if let Some(e) = find_resp.error() {
            bail!("Find transactions failed with: {}.", e)
        } else if let Some(hashes) = find_resp.take_hashes() {
-->        let get_resp = self.get_trytes(&hashes)?;
            if let Some(e) = get_resp.error() {
                bail!("Get trytes failed with: {}.", e)
            } else if let Some(trytes) = get_resp.take_trytes() {
                return Ok(bundles_from_trytes(&trytes)
                    .into_iter()
                    .map(|bundle| msg_from_bundle(&bundle))
                    .collect());
            } else {
                bail!("Get trytes contains no trytes.")
            }
        } else {
            bail!("Find transactions contains no hashes.")
        }
    }

Where get_trytes uses unwrap() on the network call, and the result is handled with "?", so if connection fails, or no response is received from node the entire application chrashes, a more pleasant behavior would be to handle the error or propagate it higher so the developer can handle it

Regression Testing

Description

We need a quickly verifiable means of confirming that changes to the code do not break basic functionality. We will need to take our examples and expand them into a pipelined process for testing for regressions.

Motivation

We will be making changes in the future that we want to ensure do not break currently available functionality.

Requirements

• Pipeline for generating/accessing a node on selected network
• P2P communication between Author and a Subscriber instance across the tangle
• P2MP communication between Author and several Subscriber instances across the tangle
• Expected sequencing occurs across all participants in channel
• Basic transportation layer

Open questions

Any additional functionality we want to throw into these tests?

Clippy, GH Actions and code clean up Pt. 2

Description

• remove all clippy allows
  example: #[allow(clippy::module_inception)]
  example: #[allow(dead_code)]
• TODOs in the code
• Add testing of bindings by compiling
• Add "iota-streams-app-channels-example" building

Motivation

Cleaner code = better code

Test webhook feature

Yup a test

Rename Author to Publisher

The Publish Subscribe is a well known pattern. Since streams fits into this pattern, as a developer it feels more natural use the naming convention of it.

Timestamps are in milliseconds instead of seconds

The timestamp field of the Channel transactions are in milliseconds instead of seconds.

This causes tools such as Tangle explorers to display a transaction date way in the future:

https://utils.iota.org/address/VZGHRWHIYKQBOMWSNRFGT9VAXPZASVOPGLYHBIV9NTTAAVAVHTMOZO9XHDDRDGADHRPJWWGJJEWLWPQXY/devnet

Additional note
The bundle structure seems strange. Tangle explorers declare them as invalid.

Document transition from MAM

Description

Many products and POC's have been built using MAM for secure messages. As MAM is deprecated we should be documenting the most efficient means of transitioning from these MAM implementations to Streams implementations.

Motivation

MAM is deprecated and users should be updating their processes to use supported libs.

Requirements

• Document similar approach of MAM and single-branch Stream for easy transition
• Document Approach for migrating MAM data to a Streams branch
• Investigate further potential approaches for transition

Open questions

Is there a means of transitioning the current data from a MAM stream to a Streams channel?
This will likely require doubling of information on the tangle. For those not wishing to do so, is there a means we can piggyback on the end of a MAM stream?

Channels: Author must have a function that returns the available number of MSS secret keys available

This functionality is required to perform the change key without leaving the user the responsibility of keeping that count.

It could be something like the following:

...
if author.remaining_secret_keys() == 0 {
  // Change the key
  let msg = self.author.change_key(&announcement_link)?;
  client.send_message_with_options(&msg, send_opt)?;
 ...
}
...

ChannelsClassic App

Design and implement ChannelsClassic using EdSig and EdDH instead of MSS and NTRU.

Make error message more helpful

If a subscriber unwraps the same Announce message more than once, this error is returned, which isn't particularly helpful and displays the channel address in trits.

This error is also returned if the subscriber tries to unwrap two different Announce messages.

Got Announce with address 243:[(243,0,0x2a78d9bd590):[|221102102122011020021020010022110200221110002110200000111221112102202100221110210000221222221011010200110000120221220101200212111220021221122102022222001111122100212010210212211210022102221020000211010221102020221220110000111001200102100122212]], but already registered to a channel 243:[(243,0,0x2a78d9bdf90):[|221102102122011020021020010022110200221110002110200000111221112102202100221110210000221222221011010200110000120221220101200212111220021221122102022222001111122100212010210212211210022102221020000211010221102020221220110000111001200102100122212]]

Source:

streams/iota-streams-app-channels/src/api/subscriber.rs

Line 296 in 6e25ad8

pub fn unwrap_announcement<'a>(

Solution

Firstly, could we display addresses in trytes to make them more friendly to read and compare?

Secondly, could we make this error clearer by separating the two scenarios?

1. `Subscriber tried to process an announcement with the same channel address more than once: Channel address in trytes

2. Subscriber has already processed an announcement with channel address: Channel address in trytes. Cannot process the new announcement with channel address: Channel address in trytes

MWM set in send options is overwritten if local_pow is disabled

When connected to comnet with remote PoW the message { msg: "MWM too high. MWM: 14, Max allowed: 10" } is returned, even if the send options have been set MWM to a value below 10.

This happens because if remote pow is enabled and send_trytes is called at iota-streams-app/src/transport/tangle/client.rs:406 the attach options of MWM used at iota-client-0.3.0/extended/send_trytes.rs:75 are overwritten from 9 to 14 at iota-client-0.3.0/extended/send_trytes.rs:69

Channels: Share pre-shared keys

Open public access to pre-shared key storage in the API.

RFC process incorporated on github

The template from Bees RFC process needs to be copied over to Streams

Update Specification [chrysalis pt 2]

Description

With Chrysalis 2 changes just around the corner, we've started to prepare the transition for the client portion of Streams. Now we need to document those changes in the specification and update the version.

Motivation

Changes to the client format and transaction structure in the tangle requires updates for documentation purposes.

Requirements

• Update transaction structure in spec
• Update client usage in Channels Protocol section of spec

Open questions

Still an open rfc process for finalising Chrysalis, will there be any more significant changes on the front that require updating in our docs?

Signature authentication does not always succeed

The first time you send an Announce message, and use a subscriber to unwrap it, the message is authenticated.

If you try to unwrap that message again, sometimes you see this error:

Authenticity is violated, bad signature

streams specification to markdown

The 1.0 version of the specification needs to be moved to markdown after we incorporate Chrysalis 2.0 changes and roll the rev.

bindings/wasm => build fails due to "wasm-pack: command not found "

1. Navigate to bindings/wasm
2. Install packages with npm i or yarn
3. Build project with npm run build or yarn build
4. Error is shown

$ npm run build:web && npm run build:nodejs

> [email protected] build:web
> wasm-pack build --target web --out-dir wasm-web && node ./build/web && rm ./wasm-web/.gitignore

sh: wasm-pack: command not found

Fix: Add missing package to the list of dependencies
package.json

  "devDependencies": {
    ...
    "wasm-pack": "^0.9.1",
    ...
  },

Channels: Author's `unwrap_unsubscribe` method does not remove Subscriber's public key

Follow link in Unsubscribe message and get Subscriber's NTRU public key and store it in link store.

Unit Testing

Description

During the rapid development that occurred in the ternary to binary conversion, many gaps were created in the testing procedure. We need to add unit tests for each module missing them, and improve/update the ones that already exist.

Motivation

Many modules are missing proper unit testing for their functionality.

Requirements

Need to develop unit tests for:

• app/message

• app/transport

• app-channels/api

• app-channels/message

• core/hash

• core/sponge

• core/prng

• core-edsig/key_exchange

• core-edsig/signature

• core-keccak/sponge

• ddml/command

• ddml/types

• ddml/link_store

Open questions

Are unit tests necessary for the current Transport or should we write them for Ch pt 2 only?

Create methods to create link from address and tag string

As a developer, I want to create a link from a given address and tag.

recv_message strategy for TangleTransport

Tangle may contain multiple messages at the same link. There are possible strategies when implementing recv_message:

• expect the only message, fail if none or multiple;
• return only the message attached last (having latest timestamp).

Also, it's possible to use recv_messages and try handling messages in order until a valid one is found.

As a developer, I'd like `send_message()` to return my bundle

The send_message() method sends a channel message to a node, using the iota_client instance.

However, the result that's returned from the node is not also returned by the send_message() method.

When using the channel app, this makes it difficult to know if the transactions were sent and what the resulting bundle information is.

Error: "Message version not supported: 0. " when parsing header

This gets thrown sometimes (not always) when calling tx.parse_header()

It happens on all types of messages.

Tangle: message bundles are inconsistent

Bundles published with iota-lib-rs are inconsistent.

Channels: Require explicit trust of public keys

Public keys shared in Announce, ChangeKey, Subscribe messages are untrusted in general. Additional mechanism must be used to verify public key trust.

Fix wasm bindings JS examples

On chrysalis-2 branch proceed to the bindings/wasm folder, install packages, build project, then run files from the examples folder

Errors:

1. Node example:

$ node examples/node.js
const greet = streams.Greet()
                      ^
TypeError: streams.Greet is not a function

2. Web example

$ examples/web.js
channel address:  04dd1a92ec6c6bea1e8290e24676e387f6092aeeafb108cf9ccdb00272f0b1610000000000000000
multi branching:  false
node:internal/process/promises:245
          triggerUncaughtException(err, true /* fromPromise */);
          ^
[UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "builder error: JsValue(ReferenceError: Headers is not defined
ReferenceError: Headers is not defined
    at /streams/bindings/wasm/wasm-node/iota_streams_wasm.js:1304:15
    at /streams/bindings/wasm/wasm-node/iota_streams_wasm.js:214:22
    at <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::ha76d20b57f128831 (<anonymous>:wasm-function[110]:0x4a676))".] {
  code: 'ERR_UNHANDLED_REJECTION'
}

[EPIC] Bindings for Steams

Description

This epic outlines the bindings we wish to write for Steams

Motivation

In order to improve usage of streams in other projects, we need to have it as easy to use as possible. This requires ready to use code for other languages, so developers don't have to write their own bindings

Requirements

In a non-prioritized order:

• C
• WASM/Node: iota-community/X-Team_IOTA_Streams#8
• NEON/JS: https://github.com/kwek20/streams/tree/feat/neon-binding
• Go (should use c bindings with cgo)
• Java / Android (should be using node.js for android)
• iOS / Swift (? xcode required) (should be using node.js)
• Python

Shared codebase:

Shared codebase will be located in /bindings/shared/{shared_name}

Shared name: "c" used in:

• C
• Go
• Java

Shared name: "js" used in:

• WASM
• NEON

Open questions

• Any other languages we need to create bindings for?
• Can we use another repository in order to generalize with iota.rs and other rust libraries?

Refactor Error Handlers

Description

Currently the error handling is very disjointed and isn't very compatible with a bindings structure. We need to create a proper architecture for handling common errors within the code. This will assist in improving error handling through the bindings as well.

Motivation

We need a standardised formatting for error/panic mitigation.

Requirements

• Create structure for generic error handling
• Single location for all generic error messages
• Remove any panics that can stall out usage (except perhaps during user/client generation)

Open questions

Which errors do we want to allow panic's from, and which do we want to stop from causing any panic?

Channels: deterministically derive message link

Currently, sender needs to communicate message link with the recipient in order for recipient to be able to recv_message. Some links can be derived deterministically using public data (such as public key, base message link, counter), eg. next_msg_link = hash(base_link, branch_no, seq_no).

Use enums for boolean parameters

When creating a new Author or Subscriber instance, it would be clearer if you had to pass something like WithNtruKeys or WithoutNtruKeys instead of true or false.

let mut author = Author::new("", 3, WithNtruKeys);

[EPIC] Updated/Improved Documentation

Description

Documentation needs to be improved and expanded in various places to improve clarity for developers intending to use the library.

Motivation

We want to improve the integration process for developers to ease transitioning into the network.

Requirements

• Update specification and comments for chrysalis changes
• Specification to Markdown
• Binding usage documentation
• Using pre-shared keys
• Transition plan for MAM to Streams

Open Questions

Improved binding documentation

Description

We have a main.c to assist users in understanding how to use the c bindings, but there can be improvements to assist users in understanding the tools at their disposal and how to properly implement them.

Motivation

Users need to understand how to properly implement the c bindings and use the memory management tools.

Requirements

• Document each function available and the purpose of each
• Better document how to utilise the shared object files
• Document how to pull C bindings into other languages (i.e. usage in GoLang)

Open questions

Will other bindings use the same functions? If so can we combine the documentation process for each?

Channels: rename tangle Author and Subscriber `unwrap_` methods to `handle_`

Title says it all. unwrap_ methods process messages only and do not modify state, whereas handle_ methods perform additional application-specific logic.

Propagate Dependency errors to user

Description

Wherever we become reliant on a potentially error producing dependency, we need to pass any errors that occur at this point up to the user end for easy debugging.

Motivation

There have already been instances where a dependency within the client library breaks in some way and hunting down the source and patching becomes difficult.

Requirements

• If an error is caused by a dependency, ensure that error message is passed up through the code
• Propagate iota.rs errors up to the user side

Open questions

What degree of granularity do we want on these propagated errors (full stack trace or just message)?