Add API method for address translation between public key, base32 address, and hex address

[orisdorch]

As it stands, the standard 'address' output in Symbol/NIS1 API responses is encoded in hexadecimal - sometimes with private key also provided. NEM/NIS tended to output more user-friendly base32 encoded addresses, which is broadly used in the UI and real world use (i.e. end users will likely never see their hex encoded address).

API calls using address appear to be universally require a Base32 address, which seems to be a functional and logical disconnect in that:

1. I cannot take the address from an API response and use it in a subsequent API call without intermediary translation
2. I have to translate a base32 address to hex before I can use it to parse data retrieved via an API call.

Perhaps the ideal solution would be to provide a base32 address in addition to the hexadecimal address any time the address is provided. Another option would be to add a new API function that translates between the three address equivalencies:
API Call Arguments: public key OR base32 address OR hex address [one required]
Output: public key, base32 address, and hex address

There are several ways this could be resolved, this is simply one of them.. Perhaps simply replicating NEM's /account/get/from-public-key where the output contains both hex and base32 encodings- https://nemproject.github.io/#retrieving-account-data

Would save developers from requiring CLI / coding their own conversion.. Worked around this in python 3.6.4 using:

import base64

### Translate between hexidecimal address (used in the API responses) and Base32 (used in the UI)
def hexToAddress(hexKey):
    return base64.b32encode(bytes.fromhex(hexKey)).decode("utf-8").replace("=","")

def addresstoHex(address):
    address.replace("-","")+"="
    return bytes.hex(base64.b32decode(address))

[orisdorch]

The function addressToString() in catapult-rest/catapult-sdk/src/model/address.js seems designed for conversion from hex to base32 -- addressToString(convert.hexToUint8(decodedAddress)); - Couldn't this be used to produce an additional 'end user readable' address output in API Responses?

Maybe there was an optimization from NIS to NIS1 - shifting DB address storage from base32 to Hex to save 15 bytes per address? If so, you wouldn't have needed to translate NEM's DB addresses before sending them in responses.. Would also mean NIS1 DB interactions would use hex addresses, so the base32 address wouldn't be particularly useful from a development perspective - just prettier to end users / a NEM throwback..

[fboucquez]

You don't need to call a remote rest API to convert a public key to base32 and hex addresses. You should use the SDK available for python. https://github.com/symbol/sdk-python

Having said that, we want to convert the hex addresses in Rest payloads to the base32 encoded addresses

#604

[gimre-xymcity]

@ZachAmo can you provide sample, where is address returned in hex?
(if that happens, that's probably bug in REST layer). Addresses should always be returned in base32.

However: if the response includes public key not address it should be in hex.

[fboucquez]

@ZachAmo can you provide sample, where is address returned in hex?

Atm all the addresses rest returns are the hex of the raw addresses.

There is a serie of PRs to fix this , like #604. They need to be released and upgraded in order. It's a breaking change the current SDK can absorb but apps like explorer, wallets, clis, etc would need to upgrade.

[fboucquez]

However: if the response includes public key not address it should be in hex.

public keys have publicKey suffix in the attributes, like signerPublicKey

[orisdorch]

The main reason for this is the hex addresses returned in rest responses. I was able to convert in python and posted the code in another thread for anyone else having issues.. Don't recall seeing a python sdk. If I remember correctly, For publix key it's possible to resolve address via rest. I was trying to see what I could do with a pretty vanilla python install, as this is how some folks are liable to tackle small projects. A shift from hex to base 32 in the rest response effectively resolves this issue.. That said, it will break what I built, and goodness knows who else had to work around this.. The change is liable to break code unless you add a new value to the response rather than change the encoding of the existing value..