idena-pocket as bridge signer

[menxit]

This issue is about to make idena-pocket able to be a bridge signer for external Dapps. The idea is to base the communication on window.postMessage. An external Dapp can open idena-pocket and send arbitrary messages:

const url = "https://pocket.idena.dev";
const pocket = window.open(url);
const message = "this is an arbitrary message";
pocket.postMessage(message, url);

On the other side idena-pocket should be able to manage these messages, accepting only the ones described by following protocol.

window.addEventListener("message", event => {
    // do stuff
});

Protocol

Protocol is based on three different type of messages:

• REQUEST: messages sent by external dapp
• RESULT: messages sent by idena-pocket
• ERROR: error sent by idena-pocket

Authorize

REQUEST -->
{
    request: "AUTHORIZE"
}

<-- RESULT
{
    action: "AUTHORIZE",
    result: true | false
}

Retrieve address

REQUEST -->
{
    request: "GET_ADDRESS"
}

<-- RESULT
{
    action: "GET_ADDRESS",
    result: "0x0000000000000000000000000000000000000000",
}

Send transaction

REQUEST -->
{
    request: "SEND_TRANSACTION",
    parameters: [
        nonce?: number;
        epoch?: number;
        type?: number;
        from?: string;
        to: string;
        amount: number;
        maxFee?: number;
        tips?: number;
        payload?: string | Buffer
    ],
}

<-- RESULT
{
    action: "SEND_TRANSACTION",
    result: "0x862ef761da421aa2331f2676ac1dec5ce64176f9f4b86b68ed5684e96da5ac39",
}

<-- ERROR
{
    action: "SEND_TRANSACTION",
    error: "insufficient funds",
}

[bingbinglee]

🔥

[idenatoday]

So, some sort of RPC to drive the wallet from local apps. Nice idea!

One thing we would be wary of is that this opens local exploits. maybe authorize is there for some mitigation, but as a minimum protection, we can think of:

• split commands between innocuous commands (get a balance, a status) and sensible ones (send a tx, read privkey, get local wallet address)
• have the user to systematically confirm any sensible command by a dialog showing the action to be executed (recipient address, amount, data load if any)
• potentially, have a pin code in the wallet to be typed in to confirm, to avoid an external malicious app also stealth click on the confirm dialog.

[idenatoday]

Another thing we can think of - nothing critical but thinking long term, maintainability, compatibility and less possible future technical debt - is look at what ETH uses for commands/methods name for such things. May seem silly, but if eth wallets or nodes have some similar commands, keeping the methods and param names the same means it's way easier to document, point to an existing spec, and easier for eth devs to jump in. Custom names will mean translation layers, incompatible implementations between wallets aso. Not sure if there are standard for this specifically, but worth looking at before defining custom commands. Just a hint to avoid future pain and lead the way.