Libindy 1.7 to 1.8 migration Guide

This document is written for developers using Libindy to provide necessary information and to simplify their transition to Libindy 1.8 from Libindy 1.7. If you are using older Libindy version you can check migration guides history:

Notes

Migration information is organized in tables, there are mappings for each Libindy API part of how older version functionality maps to a newer one. Functions from older version are listed in the left column, and the equivalent newer version function is placed in the right column:

  • If some function had been added, the word ‘NEW’ would be placed in the left column.
  • If some function had been deleted, the word ‘DELETED’ would be placed in the right column.
  • If some function had been deprecated, the word ‘DEPRECATED’ would be placed in the right column.
  • If some function had been changed, the current format would be placed in the right column.
  • If some function had not been changed, the symbol ‘=’ would be placed in the right column.
  • To get more details about current format of a function click on the description above it.
  • Bellow are signatures of functions in Libindy C API. The params of cb (except command_handle and err) will be result values of the similar function in any Libindy wrapper.

Libindy 1.7 to 1.8.0 migration Guide

Libindy API

The main purpose of this changes is providing a way of getting additional error information like message and backtrace.

Changes

  • Migrated Libindy to failure crate for better handling and error chaining.
  • Added synchronous indy_get_current_error API function that returns details for last occurred error.
  • Updated Libindy wrappers for automatic getting error details:
    • Python - added message and indy_backtrace fields to IndyError object.
    • Java - added sdkBacktrace field to IndyException. Libindy error message set as the main for IndyException.
    • NodeJS - added indyMessage and indyBacktrace fields to IndyError object.
    • Rust - changed type of returning value from enum ErrorCode on structure IndyError with error_code, message, indy_backtrace fields.
    • Objective-C - added message and indy_backtrace fields to userInfo dictionary in NSError object.
  • Updated Indy-Cli to show Libindy error message in some cases.
v1.7.0 - Libindy API v1.8.0 - Libindy API
Get details for last occurred error.
NEW
indy_get_current_error(
            error_json_p: *mut *const c_char)
Set libindy runtime configuration
indy_set_runtime_config(
        config: *const c_char) -> ErrorCode
Note: Format of config parameter was changed. Current format is:
{
    "crypto_thread_pool_size": Optional[int] - 
        size of thread pool 
    "collect_backtrace": Optional<[bool] - 
        whether errors backtrace should be collected
}

Crypto API

The main purpose of changes is the support of Wire Messages described in AMES HIPE

Note: New functions are Experimental.

v1.7.0 - Crypto API v1.8.0 - Crypto API
Packs a message by encrypting the message and serializes it in a JWE-like format
NEW
indy_pack_message(command_handle: i32,
                 wallet_handle: i32,
                 message: *const u8,
                 message_len: u32,
                 receiver_keys: *const c_char,
                 sender: *const c_char,
                 cb: Option)
          
Unpacks a JWE-like formatted message outputted by indy_pack_message
NEW
indy_unpack_message(command_handle: i32,
                    wallet_handle: i32,
                    jwe_data: *const u8,
                    jwe_len: u32,
                    cb: Option)
          
Encrypts a message by anonymous-encryption scheme
indy_crypto_anon_crypt(
            command_handle: i32,
            recipient_vk: *const c_char,
            msg_data: *const u8,
            msg_len: u32,
            cb: Option)
          
DEPRECATED
Use `indy_pack_message` instead
Decrypt a message by authenticated-encryption scheme
indy_crypto_auth_decrypt(
            command_handle: i32,
             wallet_handle: i32,
             recipient_vk: *const c_char,
             encrypted_msg: *const u8,
             encrypted_len: u32,
             cb: Option)
          
DEPRECATED
Use `indy_unpack_message` instead

Ledger API

  • Added NETWORK_MONITOR to list of acceptable values for role parameter in indy_build_nym_request API function.
  • Implemented automatic filtering of outdated responses based on comparison of local time with latest transaction ordering time.

Libindy 1.8.1 to 1.8.2 migration Guide

v1.8.1 - Ledger API v1.8.2 - Ledger API
Builds a AUTH_RULE request to change authentication rules for a ledger transaction
NEW
indy_build_auth_rule_request(command_handle: CommandHandle,
                             submitter_did: *const c_char,
                             txn_type: *const c_char,
                             action: *const c_char,
                             field: *const c_char,
                             old_value: *const c_char,
                             new_value: *const c_char,
                             constraint: *const c_char,
                             cb: fn(command_handle_: CommandHandle,
                                    err: ErrorCode,
                                    request_json: *const c_char))
      
Builds a GET_AUTH_RULE request to get authentication rules for ledger
NEW
indy_build_get_auth_rule_request(command_handle: CommandHandle,
                                 submitter_did: *const c_char,
                                 txn_type: *const c_char,
                                 action: *const c_char,
                                 field: *const c_char,
                                 old_value: *const c_char,
                                 new_value: *const c_char,
                                 cb: fn(command_handle_: CommandHandle,
                                        err: ErrorCode,
                                        request_json: *const c_char))
      

Libindy 1.8.2 to 1.8.3 migration Guide

Updated behavior of indy_build_auth_rule_request and indy_build_get_auth_rule_request API functions:

  • new_value can be empty string for ADD action.
  • new_value can be null for EDIT action.
  • old_value is skipped during transaction serialization for ADD action.