Accept `signature` value as `sg_`-prefixed string

[davidyuk]

Currently in readme

Sophia Type	Sophia Example	Javascript type	Javascript Example
signature	#001234d	BigInt	BigInt("0x001234d")

I propose to add an alternative way to provide signatures as defined in aeserialization https://github.com/aeternity/aeserialization/blob/270ebecc577f7043a0c5d771538a33a9c8040f48/src/aeser_api_encoder.erl#L222

[dincho]

Could you please share some hypothetical API examples?

[davidyuk]

Recently on sdk side I've added signDelegationToContract function that returns sg_-prefixed string. I was updating AENS delegation signature examples and find out that currently I need to decode the returned signature to pass it to contract. I'd like to avoid this step.

contract AensDelegation =
  stateful payable entrypoint signedPreclaim(addr: address, chash: hash, sign: signature): unit =
    AENS.preclaim(addr, chash, signature = sign)

const preclaimSig = await aeSdk.signDelegationToContract(contractAddress);
const preclaimSigDecoded = decode(preclaimSig);
await contract.signedPreclaim(owner, decode(commitmentHash(name, salt)), preclaimSigDecoded);

On sdk side I started to encode signatures as sg_-prefixed strings to be consistent with the node (signatures array) https://mainnet.aeternity.io/v3/transactions/th_2EVfeTs7sDasevvaA5V6ziifCvmHwfBVYjbmXWSx2NMGvvaHV9 Also, this kind of encoding is more developer-friendly because it keeps some kind of type information that can be validated even on TS level (in comparison with Uint8Array)

[dincho]

Okay, but doesn't this apply to all "API encoded" data? Accounts etc. ?

[davidyuk]

I think it does. Account address already everywhere encoded as ak_ strings 🤷‍♀️