Add SignMessageObject to signMessage function

[DOBEN]

Purpose

The browser wallet can now sign bytes as well. Expanding the library to enable passing an object (with schema) to be signed.

Checklist

• My code follows the style of this project.
• The code compiles without warnings.
• I have performed a self-review of the changes.
• I have documented my code, in particular the intent of the
  hard-to-understand areas.
• (If necessary) I have updated the CHANGELOG.

[bisgardo]

It looks like this upgrade necessitates changes to signAndSendTransaction:

Argument of type 'Record<string, unknown>' is not assignable to parameter of type 'SmartContractParameters'.

[bisgardo]

@DOBEN I've found that doing this part properly is a bigger change that I've done separately. Please see #34.

[bisgardo]

Please add this interface change to the changelog. Is it a breaking change @shjortConcordium ?

[shjortConcordium]

The "new" types are what the parameters can actually be, so while this change is breaking, it is only breaking for inputs that wouldn't work, so it is more a bugfix than an actual breaking change 🤔

[bisgardo]

Does the mobile wallet support the new types? @shjortConcordium If not, I think we should only include the parts of the union type that are supported everywhere in the interface. I assume the browser wallet implementation could extend this to the full type.

[shjortConcordium]

The mobile should "support" these types, but the parameters are serialized before sending them to the MW.

[bisgardo]

I can't get the call with a primitive string type to work with the mobile wallet: The parameter serialization fails as boiled down to the test

const { Buffer } = require('buffer/');
const { serializeUpdateContractParameters } = require('@concordium/common-sdk');

test('serialize plain string parameter', () => {
    const contractName = 'test';
    const receiveName = 'string';
    const parameters = 'xyz';
    const schema = 'FgI';
    const schemaVersion = 2;
    const res = serializeUpdateContractParameters(
        contractName,
        receiveName,
        parameters,
        Buffer.from(schema, 'base64'),
        schemaVersion
    );
    console.log({res});
});

which fails with the error

unable to deserialize parameters, due to: Parse error

@concordium/common-sdk is at version 6.4.1 which is the current version.

To run the test, add the test file to the project root, install jest (yarn add --dev jest) and run jest.

The test is based on the following example contract written by @DOBEN (deployed on testnet with index 4239):

use concordium_std::*;
#[derive(Serialize)]
struct State;
/// Init function that creates a new contract.
#[init(contract = "test")]
fn init<S: HasStateApi>(
    _ctx: &impl HasInitContext,
    _state_builder: &mut StateBuilder<S>,
) -> InitResult<()> {
    Ok(())
}
pub type Number = u64;
#[receive(
    contract = "test",
    name = "number",
    parameter = "Number",
)]
fn number<S: HasStateApi>(
    ctx: &impl HasReceiveContext,
    _host: &impl HasHost<State, StateApiType = S>,
) -> ReceiveResult<()> {
    let _ = ctx.parameter_cursor().get()?;
    Ok(())
}
pub type Bool = bool;
#[receive(
    contract = "test",
    name = "bool",
    parameter = "Bool",
)]
fn bool<S: HasStateApi>(
    ctx: &impl HasReceiveContext,
    _host: &impl HasHost<State, StateApiType = S>,
) -> ReceiveResult<()> {
    let _ = ctx.parameter_cursor().get()?;
    Ok(())
}
pub type St = String;
#[receive(
    contract = "test",
    name = "string",
    parameter = "St",
)]
fn string<S: HasStateApi>(
    ctx: &impl HasReceiveContext,
    _host: &impl HasHost<State, StateApiType = S>,
) -> ReceiveResult<()> {
    let _ = ctx.parameter_cursor().get()?;
    Ok(())
}

which produces the schema

{
  "contractName": "test",
  "entrypoints": {
    "bool": {
      "parameter": "AQ"
    },
    "number": {
      "parameter": "BQ"
    },
    "string": {
      "parameter": "FgI"
    }
  }
}

@shjortConcordium @abizjak is there something wrong with the way I call serializeUpdateContractParameters? What should be done to make the test pass?

[shjortConcordium]

If you want to use serializeUpdateContractParameters you need to supply the schema for the entire module. (Not the schema for the parameter itself, like "FgI" is)
Otherwise you can use serializeTypeValue(parameters, Buffer.from(schema, 'base64')) .

[bisgardo]

If you want to use serializeUpdateContractParameters you need to supply the schema for the entire module. (Not the schema for the parameter itself, like "FgI" is) Otherwise you can use serializeTypeValue(parameters, Buffer.from(schema, 'base64')) .

How does the implementation tell which kind of schema is supplied? What does the browser wallet do? Try both and see which one works?

[shjortConcordium]

If you want to use serializeUpdateContractParameters you need to supply the schema for the entire module. (Not the schema for the parameter itself, like "FgI" is) Otherwise you can use serializeTypeValue(parameters, Buffer.from(schema, 'base64')) .

How does the implementation tell which kind of schema is supplied? What does the browser wallet do? Try both and see which one works?

For sendTransaction, it now takes a SchemaWithContext, which specifies which type. (If given only a string as the schema it assumes the old format, for backwards compatibility)
In the SignMessageObject, it should always be the type specific schema.

[bisgardo]

I don't understand this SignMessageObject type:

type SignMessageObject = {
    /** as base64 */
    schema: string;
    /** as hex */
    data: string;
};

What is schema? What is data? Why is one base64 and the other hex? @shjortConcordium

[shjortConcordium]

The schema is the schema that should be used to deserialize the message data, and we usually encode schemas with base64.
The data is the message data, as hex because we usually encode stuff other than schemas as hex 🤔

[bisgardo]

Is this the same kind of schema used to serialize parameters? Used for the wallet to display what you sign decoded to a string? What if you want to sign arbitrary bytes that don't look like a parameter?

Is there a reason for data not being a Buffer?

[shjortConcordium]

I don't think we'll allow arbitrary bytes that cannot be displayed using a schema.

The BW API does not include buffers, seeing that they are not a "native" type in a web environment.

[shjortConcordium]

I don't think the Mobile wallets support the signMessageObject API yet, so maybe we need to have some handling for that, otherwise we are relying on the current MW versions to gracefully handle the unexpected format 🤔
(Otherwise LGTM)

[bisgardo]

@DOBEN I'm suggesting a different approach in #35 which is consistent with #34, which was just merged.

[DOBEN]

Closing this MR:

Changes that were implemented in
#34
#35
were tested in and satisfy the requirements so that this MR is obsolete.