Heartbeat data

[vponline]

Closes #1411

[aquarat]

Looks good but two comments.

(And of course it lost my other comment):
The airnode address shouldn't be necessary because it can be extracted from the signature:

            const msg = "Hallo Welt";
            const signature = await owner.signMessage(msg);
            const signer = ethers.utils.verifyMessage(msg, signature);
            expect(signer).to.equal(owner.address);

maybe @aTeoke can comment on where the requirement came from/if there's a specific reason the airnode address is needed in the payload too? :)

[vponline]

Looks good but two comments.

(And of course it lost my other comment): The airnode address shouldn't be necessary because it can be extracted from the signature:

            const msg = "Hallo Welt";
            const signature = await owner.signMessage(msg);
            const signer = ethers.utils.verifyMessage(msg, signature);
            expect(signer).to.equal(owner.address);

maybe @aTeoke can comment on where the requirement came from/if there's a specific reason the airnode address is needed in the payload too? :)

I might be misunderstanding what you mean, but won't chainAPI need the airnode_address field to verify the signer? Or do you mean that their API will have access to the mnemonic to extract it directly from there?

[aquarat]

I might be misunderstanding what you mean, but won't chainAPI need the airnode_address field to verify the signer? Or do you mean that their API will have access to the mnemonic to extract it directly from there?

Their API can extract the airnode address from the signature, so you don't need an extra field.
ChainAPI uses the Airnode mnemonic via Metamask for the initial user to log in, so from that process they'll have the airnode_address which they can compare against the recovered address when they verify the signature.

To rephrase: ChainAPI will receive a heartbeat containing a heartbeat payload and a signature. They'll start by verifying the signature against the payload and in the process they will also recover the signer. If verification succeeds they check for an integration that has that signer as it's airnode_address with a matching cloud, stage and region and assuming they find a match they update the last received heartbeat for that deployment. They can't trust the contents of the payload until they've checked the signature and if they've checked the signature they would have already recovered the airnode_address.

const ethers = require('ethers');
const msg = "Hello world";
const randomWallet = ethers.Wallet.createRandom();
const signedMessage = await randomWallet.signMessage(msg);
const recoveredKey = ethers.utils.verifyMessage(msg, signedMessage);
// recoveredKey here was '0x36e56E09214926aF279ce1a6392d58e246538afa'
if (recoveredKey === randomWallet.address) console.log('Addresses match');

[vponline]

ChainAPI uses the Airnode mnemonic via Metamask for the initial user to log in, so from that process they'll have the airnode_address which they can compare against the recovered address when they verify the signature.

Thanks for explaining, in this case I am also not sure why it was originally included in the payload 🤔

[amarthadan]

Thanks for explaining, in this case I am also not sure why it was originally included in the payload thinking

I think I've created the confusion here. Sorry about that 😅