Description

Currently, we have no defined database migration process. Any schema changes should ideally be handled through an automatic migration process implemented within the library.

Motivation

For schema changes, the database migration should be a seamless process for consumers.

Requirements

• Research for ways on how to best approach this;
• Have a look at Bee on how they tackle this problem;
• We would need to introduce versioning within the database

Some earlier thoughts on this topic: https://github.com/Thoralf-M/wallet-core/blob/dev/documentation/database_migration.md

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

No.

Implements iotaledger/iota.rs#786 on develop.

Actually check for all commands.

Description

In the examples, sometimes addresses or IDs need to be changed to run successfully. Currently those are "magic values" provided directly to the function calls. We probably should change that to be clearly named variables near the top of the example for clarity.

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

No.

Also try to get rid of dasel or update to v2

Discussed in iotaledger/wallet.rs#919

Description

They are currently missing, while other languages do provide them.

Motivation

Consistency.

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

Yes.

Description

I would remove the extensive log info.

Instead of this:

2022-06-02 08:41:55 (UTC) wallet::command::account_manager           INFO  IMPORTANT: write this mnemonic phrase in a safe place.
2022-06-02 08:41:55 (UTC) wallet::command::account_manager           INFO  It is the only way to recover your account if you ever forget your password and/or lose the stronghold file.
2022-06-02 08:41:55 (UTC) mnemonic                                   INFO  local judge strong leave chuckle hand drastic found unfair female gift what cash throw rotate poverty make approve cluster settle leave casual agree ring
2022-06-02 08:41:55 (UTC) wallet::command::account_manager           INFO  Mnemonic stored successfully

I would do something like this:

IMPORTANT: write this mnemonic phrase in a safe place.
It is the only way to recover your account if you ever forget your password and/or lose the stronghold file.

local judge strong leave chuckle hand drastic found unfair female what gift cash throw rotate poverty make approve cluster settle leave casual agree ring

Mnemonic stored successfully

Way easier to read the important info fast. Why should I as user need log level and timestamp?

Open questions (optional)

As @Thoralf-M said we could probably make use of https://docs.rs/fern/latest/fern/struct.Dispatch.html#method.format

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

Yes maybe

• Review privacy
• Burn NTs
• Make it so the remainder amount is enough to cover at least the rent
• get_remainder_address returns Chain
• Should take current timestamp as param ? (to allow get_time_checked ?)
• Think of an alternative to OutputInfo
• Remove the Requirements struct ?
• Filter out timelock/expiration at the beginning
• SDR expired
• Should an automatic alias transition care about created foundries ? Increase foundry_counter ?
• Configuration to remove features/unlocks of transitions?
• Remove requirements box and don't call requirements on transitioned outputs
• Always do automatic state transitions ? Or governance ok ? Add some tests
• iotaledger/iota.rs#1356 (comment)
• iotaledger/iota.rs#1356 (comment)
• Increase amount of transitioned output to potentially avoid a remainder
• Too many inputs check ? -> feaf9e3

Description

We lack tests that verify that address derivation is at par across implementations and bindings i.e., rust implementation and (java, nodejs, python) bindings. We should add them to be sure every implementation has correct address derivation.

Related ticket: iotaledger/iota.rs#790

Motivation

Extensive tests like these are needed to be confident about deterministic address derivation across all implementations.

Requirements

For a set of mnemonics, ensure they lead to deterministic addresses for different indexes.

• Python — @bingyanglin;
• Java — @kwek20;
• Rust — @Thoralf-M;
• NodeJS — @laumair;
• Wasm — @laumair

The mnemonics and expected addresses should be shared between all tests.

Tests should cover both derivations from mnemonics and also from hex seeds.

Open questions (optional)

Happy to hear if there are any other similar test scenarios that should be covered.

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

Yes — for nodejs bindings.

Description

Rn you just get an outputId that is potentially owned by you. But what the output has is a mistery to the user.

How I imagine this is when you print balance, you get something like:

potentially owned output: 0x344534....
claimable until: 20:00 15.05.2022
category: microtransfer of 10 glow

or:

potentially owned output: 0x344534....
claimable until: 20:00 15.05.2022
category: native token transfer of 100 0xrandom-token

or:

potentially owned output: 0x344534....
claimable until: 20:00 15.05.2022
category: transfer of 100 000 glow

Motivation

Give the user the option to understand what outputs he can claim

Requirements

1. Calculate when an output can be claimed
2. Calculate what one would get, when claiming it
3. Display it in the balance overview

Description

Implement a sweep function which claims/consolidates all outputs that are owned by an output
(there is already some code private, but needs some further changes)

Motivation

Easy way to clean up owned outputs by an alias or nft, so one can burn it afterwards without loosing something

Requirements

1. Get all outputs that can be controlled by this address
2. Send a transaction with them to the ed25519 address that is used to sign (if it's an alias or nft address, then the ed25519 address in their unlock condition)
3. If an owned output is an alias, nft or foundry output, don't burn them, but return an error

Description

We should improve DX of our bindings by providing useful utility functions, classes or enums (whatever is available and fits best in the related language).

For example an output could be a class where you provide the amount through a function: output.set_amount(x)
Also all values should be provided in dec and converted to hex internally.

Motivation

This allows auto complete to help, mitigates typos and makes it easier for the dev to provide the needed info

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

Yes

Description

Add a second way to sync accounts based on utxo changes, we can get for each milestone from /api/v2/milestones/{index}/utxo-changes (as long as the node didn't prune it) instead of requesting the outputs for ever address in the account.

Motivation

When an account has many addresses ~50k or more it takes seconds to sync when we request the outputs for every address individually and only gets slower the more addresses the account has. Exchanges are the main target group here. If we can just apply the utxo changes, then the account should be synced much faster.

Requirements

1. Start from a snapshot
2. Get utxo changes and request only the new created outputs (spent outputs will ne known already) from the outputs endpoint
3. Update account addresses/outputs, currently the easiest way seems to be just replacing this part https://github.com/iotaledger/wallet.rs/blob/3a6c40455c6a9cd5ce2f91cb7be8c7dbdcd93526/src/account/operations/syncing/mod.rs#L67-L73

Open questions (optional)

Should we maintain the whole ledger state (starting from a snapshot file) locally, or discard all outputs that aren't related to our own addresses? Keeping other outputs would increase the storage requirement, so we should probably not keep them, but maybe we should separate this ledger state a little bit separated from the wallet, so we can also use it for other applications

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

No.

Description

Shimmer code examples using Rust to showcase the library's functionalities in all languages.

Motivation

As we aim to make developer onboarding easy in all languages, it'd be great to provide the same examples in all languages.

Requirements

Add examples showcasing the following functionalities using Rust:

• Backup data
• Restore data
• List transactions
• Claim outputs

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

If no one's planning on working on these, I can take a go at it.

Description

Based on iotaledger/wallet.rs#1820, it becomes clear that there are some use cases where an unsigned output is required without actually sending it. Therefor, we should think about changing the API so that sending an output and building one are very easy to do separately.

Motivation

This use case is important when we want to store unsigned transactions (e.g.: ledger flows). Potentially, this might also be interesting to create a batch of transactions and then send them all at once.

Requirements

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

1. all the send methods that return a Promise<Transaction> are refactored into prepare... methods that return a prepared output of type OutputTypes. This way ...
2. the send methods can be removed from the message interface and ...
3. all transactions will use sendOutput([ output[)

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

No.

Hi would like to request if its possible to add a type property to struct Event here https://github.com/iotaledger/wallet.rs/blob/bbebd26198732e768cf58ff407fbe3cdcf01c5e4/src/events/types.rs#L14

Currently the type of the event appears as the Key of the json instead of the Value.

Eg.

{
  "accountIndex": 0,
  "event": {
    "SpentOutput": { # Appearing as key
      "output": {
        "outputId": "0xe23d69a6fc1e859ab3f778f907cf8bf31517dea65fb6577396101f6ffd5c6ef90000",
        "metadata": {
          "blockId": "0x1798b047a139a6679de33e97e86dfedbdfd3554b41be66927b50b68d7747f043",
          "transactionId": "0xe23d69a6fc1e859ab3f778f907cf8bf31517dea65fb6577396101f6ffd5c6ef9",
          "outputIndex": 0,
          "isSpent": true,
          "milestoneIndexSpent": 2492220,
          "milestoneTimestampSpent": 1670597393,
          "transactionIdSpent": "0x2d8dd8a23e86e1438efcd236ccfffa75a45c1d5807c05f1ec60dece7e12ae830",
          "milestoneIndexBooked": 2492178,
          "milestoneTimestampBooked": 1670597183,
          "ledgerIndex": 2518863
        },
        "output": {
          "type": 3,
          "amount": "1000000000",
          "unlockConditions": [
            {
              "type": 0,
              "address": {
                "type": 0,
                "pubKeyHash": "0x03b75085d5fab12547c9b20a4258d3bf47c07c0d37ea030dceb44cd63bf09ea4"
              }
            }
          ]
        },
        "isSpent": true,
        "address": {
          "type": 0,
          "pubKeyHash": "0x03b75085d5fab12547c9b20a4258d3bf47c07c0d37ea030dceb44cd63bf09ea4"
        },
        "networkId": "8342982141227064571",
        "remainder": false,
        "chain": [
          {
            "hardened": true,
            "bs": [
              128,
              0,
              0,
              44
            ]
          },
          {
            "hardened": true,
            "bs": [
              128,
              0,
              16,
              123
            ]
          },
          {
            "hardened": true,
            "bs": [
              128,
              0,
              0,
              0
            ]
          },
          {
            "hardened": true,
            "bs": [
              128,
              0,
              0,
              0
            ]
          },
          {
            "hardened": true,
            "bs": [
              128,
              0,
              0,
              1
            ]
          }
        ]
      }
    }
  }
}

I find this would make it easier to serialize it and wont impose any breaking changes to the current bindings.

This would also make it uniform to iota.js which uses a variable type to distinguish between AddressTypes like Alias,Ed25519 or Nft.

Description

We are missing binaries that support the arm64 architecture

Motivation

prebuild only builds binaries targetting the x64 architecture. Since a lot of users use arm64, we need to update the workflows to include builds for arm64 as well.

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

Yes

Description

Currently only the total balance is shown. To better show what is happening and give the user a way to investigate individual addresses, we should list the Bech32 addresses as well and maybe even their direct links in the explorer for quick navigation.

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

No.

Description

We should use sccache for caching the Rust compilation cache. This has already been done for identity.rs and it seems to work well for them. The cache is "smarter" than simply uploading the target folder to the GitHub Actions cache. I ran tests a while ago with wallet.rs and saw good results, but I'll run them again since those tests are a few months old.

Motivation

• "Smarter" caching
• Takes up less space than uploading the target folder

Requirements

• Run tests to see difference in build time vs. current caching approach
• Open PR to switch to sccache
• Investigate whether existing cache needs to be deleted so there are no issues
• Move sccache actions in identity.rs repo to own repository (optional)

Open questions (optional)

None

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

Yes

Including content from #295

Description

Currently I can just print the overall account balance by entering balance on the account prompt, like so:

Account "Alice": balance
AccountBalance {
    base_coin: BaseCoinBalance {
        total: 1100000000,
        available: 1100000000,
        voting_power: 0,
    },
    required_storage_deposit: RequiredStorageDeposit {
        alias: 0,
        basic: 85200,
        foundry: 0,
        nft: 0,
    },
    native_tokens: [],
    nfts: [],
    aliases: [],
    foundries: [],
    potentially_locked_outputs: {},
}

I want to be able to do:

Account "Alice": balance rms1qzps6nx0nk0mn3hfq9cgzsdtt77dxec0cdm6tmmrjx5746fg0xsx5h9kcd6

and get the balance associated with that particular address.

Motivation

It's a useful feature to get a better idea about the funds on a particular address and it makes it easier to monitor a certain address for incoming or outgoing funds.

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

Yes.

Description

Still always Option<SyncOptions>. On creation of account we either set a SyncOptions or we set SyncOptions::default(). when passing None, we use that one we set instead of always calling SyncOptions::default

Motivation

So we dont need to manage our SyncOptions ourselves but can set and forget unless we need something specific

Also try to get rid of dasel

Task description

Currently, not all examples are running. This gives a window of opportunity to write tests to see if the bindings work correctly. And to experiment with a mocking framework.

Requirements

Tests:

• Create Account Manager
• Create Account
• Generate Address
• Check Balance
• Send Transfer
• Backup
• Restore
• Events
• Logger

Acceptance criteria

TBD

Creation checklist

• I have assigned this task to the correct people
• I have added the most appropriate labels
• I have linked the correct milestone and/or project

Task description

When protocol values change, like changed minimum pow score, we should start using the value for new blocks right away, so the blocks have the correct pow score to get accepted
Related tip https://github.com/iotaledger/tips/blob/dynamic-pow/tips/TIP-0037/tip-0037.md
Maybe we should also reduce the node syncing interval for that from 60 seconds to a lower value

Requirements

N/A

Acceptance criteria

N/A

Creation checklist

• I have assigned this task to the correct people
• I have added the most appropriate labels
• I have linked the correct milestone and/or project

Task description

As we aim to make developer onboarding easy in all languages, it'd be great to provide the same examples in all languages.

Requirements

Add examples showcasing the following functionalities using the Java binding:

• Get Address Balance (iotaledger/iota.rs#1420)
• Listen to MQTT

Acceptance criteria

• The examples have been added to the binding
• The examples have been added to the doc's how-to guides

Creation checklist

• I have assigned this task to the correct people
• I have added the most appropriate labels
• I have linked the correct milestone and/or project

Description

I often just type wallet as the first thing. No we can discuss if I'm just stupid , but wouldn't it make sense to run wallet init internally than if nothing was created yet?

Motivation

Feels more intuitive to me and I saw some people which did the same thing as I did 😅

Requirements

1. Run wallet
2. If no db or stronghold file was created yet, execute the init routine.
3. Enjoy initialised wallet

Open questions (optional)

Should we just check if the folders/files weren't created yet, or what would be the best way to do it?

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

No

Description

Merge Overview content into the Welcome page and remove redundant content.

IOTA

• Remove IOTA 1.5 (Chrysalis) in a Nutshell and Testnet sections. They point to outdated or removed information, or info already covered elsewhere.
• Merge Overview content into the Welcome page.

Shimmer

• Remove the Testnet and Joining the Discussion sections.
• Reduce the amount of content in Account Approaches to one or two paragraphs.
• Merge Library Overview and Account Approaches content into the Welcome page.
• Improve the recommendation to use Stronghold for secret management and remove the caution.

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

Yes.

Description

Extend storage functionality with encryption as we currently have in the dev branch, might require some bigger changes to the storage module, because the current version is reduced to the basic functionality.

Transaction ids and output ids can't be used as keys in the db directly, otherwise any encryption is useless since the corresponding things can be found in the public

Motivation

Privacy

Requirements

1. Add options to set an encryption key
2. Be able to change the encryption key
   (3. Function do "logout", which clears the encryption key and data in memory)

Open questions (optional)

Might make sense to wait for iotaledger/wallet.rs#806 before doing it or doing both at once

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

No.

Description

The faucet is an important component for users who like to experiment and try things out without funding an address manually. Furthermore the faucet might be part of a testing strategy and therefore might also play an important role there.

Working with the faucet in code however is hard:

• it's not clear when the faucet processes the funding request
• it's not clear when the funds arrive
• it's not clear if an address will get funds as the request might get skipped since it already owns enough funds on the address - but this param could be different from faucet to faucet
• the HTML response of the faucet is not really helpful

Currently, the user has to perform the checks themselves in their own code to increase reliability - which is not ideal, because you need to know how the faucet works and understand the protocol.

How to improve the situation

• change the faucet to be more reliable and offer a proper REST API so that the response can be consumed properly in the wallet.rs code;
• add the logic from iotaledger/wallet.rs#1643 to the Rust faucet function instead, so that all languages benefit from it;

Task description

In firefly we would like to be able to reject/return a transaction that was sent to us with async conditions (i.e. Storage Deposit Return Unlock Condition or Expiration Unlock Condition), without providing the storage deposit ourselves.

This means that we would just send the whole amount of a transaction back to the sender.

Requirements

• Rejecting a basic output would send it back
• Reject native tokens would send them back?
• Rejecting an nft would send it back?

Acceptance criteria

TBD

Creation checklist

• I have assigned this task to the correct people
• I have added the most appropriate labels
• I have linked the correct milestone and/or project

Description

From the examples currently it is not quite clear how the AccountManager is able to initialize in further examples, without giving it any paths to the backup and database created in the first example. A small comment on the default behavior would help.

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

Yes.

Description:
Currently MQTT is not supported by the Java bindings.

Related issues:
#50

Description

Instead of returning a string as a status, we should return an enum that reflects the possible values of a participation event status (upcoming, commencing, holding, ended).

Motivation

It improves the type safety for wallet.rs.

Requirements

Open questions (optional)

Use this section to ask any questions that are related to the feature.

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

Yes

Description

Add optional MQTT listener to subscribe to the wallet address. When an event is detected, the wallet should be updated with it. Instead of having the logic to update the wallet in two places (MQTT + syncing), we could maybe just call sync with force true to get the wallet updated and without the need of adding extra logic.
When MQTT and background syncing is enabled (and working: connected to a node), the background syncing interval should be increases, since we should then get notified from MQTT when we need to sync.

Motivation

Detect transactions faster with less http requests.

Requirements

1. Subscribe to address on startup
2. When an even arrives, update the wallet/call sync
3. If background syncing is enabled, increase the interval

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

Maybe.

Description

Currently there is no way to configure the SSLContextFactory to provide a way to support self-signed certificates when connecting to private tangles to communicate with them securely. When trying to connect to a private tangle which has a self-signed certificate (HTTPS), the following error is thrown by the API currently, Error: error sending request for url (https://localhost:14266/health): error trying to connect: invalid certificate: UnknownIssuer.

Motivation

This will allow for the Java API to connect to private tangles that are secured using self-signed certificates (HTTPS) as you can provide the certificate store within the code, instead of having to communicate with them unsecured (HTTP).

Requirements

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

1. Expose an SSLContextFactory option to provide your own certificate stores

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

No.

Description

Just like in the examples of the other languages, we should have sync calls in the Rust examples. For example running the transaction example multiple times currently fails with Node(NoInputs), because the account is never synced in that script.

• Add account.sync(None).await? where appropriate, with a small comment why you'd want to call sync.

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

No.

• Check if is_alias_transition() from iota.rs would be better to use instead of alias_state_transition() #419
• [Have a client in the AccountManager ?] #423
• Instead of burn_native_token(), burn_nft(), destroy_alias(), destroy_foundry() we could maybe just have a single burn(burn: Burn) method (burn is also optional in TransactionOptions, should maybe get removed there?) #336

With the new changes, mainly the new ISA, we should check if we can change/remove the following things

• Having both ClientBlockBuilder and ClientBlockBuilderOptions feels a bit weird
• Check if all DTOs are actually useful
• Make is_alias_transition() public, so alias_state_transition() can be removed from wallet.rs?
• Remove SecretManageExt?

Description

Not sure if this really improves something, but we could doe something like this (replaced ``` with '''):

## Setup

Initialise the wallet with a given node and a randomly generated mnemonic.
'''sh title=Input
./wallet init --node [NODE API URL]
'''
'''sh title=Output
> ...
> INFO  Mnemonic stored successfully
'''

Create a main account.
'''sh title=Input
./wallet new main
'''
'''sh title=Output
> ...
> INFO  Created account "main"
'''
'''sh title=Input
> Account "main": exit
'''

Which would generate something like this:

Motivation

Could allow it to easily detect what is input and what output.

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

Yes

Description

We should improve DX of our bindings by providing useful utility functions, classes or enums (whatever is available and fits best in the related language).

For example an output could be a class where you provide the type through a function or enum. Even if this is a low level API Python devs shouldn't need to know what type: 0 means

TODO:

• #48
• #47
• #46
• #166
• #167

Motivation

This allows auto complete to help, mitigates typos and makes it easier for the dev to provide the needed info

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

Yes

To avoid an HTTP call every time.

• Getting started
  • Setup
  • Wallet
  • Storage
  • Events
  • API Reference
• Guides / examples
  • Account Manager Interface
    • Create accounts
    • Get account(s)
    • Backup storage
    • Recover accounts
  • Account Interface
    • Generate & list addresses
    • List & get outputs
    • List & get transactions
    • Mint & send Native Tokens
    • Mint & send NFTs
    • Prepare, sign & send transactions
    • Get Balance
    • Claim outputs
    • Sync accounts

Description

Enrich the exchange integration guide with practical information and best practices:

• Summary of what changed compared to the chrysalis version: api?
• How to access Shimmer rewards with wallet.rs?
• Warning and explanation about unlock conditions
• Explanation of storage deposit system
• General FAQ