Define user flows for arbitrary message signing

[landitus]

Define real use cases for arbitrary message signing with real dApps. We'd mock the user flow with the app, the real message and action to be signed by the user.

Include

• Happy path
  • Confirmation step (if it's a transaction)
• Error states
  • The hash calculated by the Wallet is different from the hash the dApp provided: We block the flow as it could indicate a bogus action
  • There's an error in the the dApp: We show a generic error and provide instructions to open the console and read the actual error message (for advanced users).
  • Tracking events

Main issue: https://github.com/hirosystems/stacks-wallet-web/issues/1051

[landitus]

I've started a quick draft of the user flows here. These should cover the full scope of the Arbitrary Message Signing feature. Lmk what you think!

Figjam

• @markmhx I'd like to make the flow more concrete if possible, so it matches the rest of the flows. That would mean coming up with a use case for an app like Arkadiko.finance. Can you help me?
• @beguene, regarding the error "There's an error in the the dApp: We show a generic error and provide instructions to open the console and read the actual error message (for advanced users)." What's exactly happening here? What would the user need to know?

[markmhendrickson]

@MarvinJanssen mind providing a concrete cases here for @landitus given your interest in integrating arbitrary messaging signing soon (e.g. a description of the message to be signed, its purpose for the app, and mocked structured data with the types of attributes you expect the message to need)?

[beguene]

@landitus The error messages will be shown in the dapp itself, we only send to the dapp to different states: 1.the user has canceled the popup

2. the user has signed the message

[landitus]

Great, here's the updated user flow:

[castig]

Thanks @landitus! User flows are looking great. I'm working on MultiSafe.xyz (STX Treasury) and a UI for Voting Governance. For both project signing would be super beneficial. It appears that the lower level signing feature is ready, but that the user flow hasn't been adopted into the Hiro Wallet yet. Do you have a sense of when this feature will go live?

P.S. Happy to help beta test, or to dive into building our products w/ your signatures.

[landitus]

Hi @castig, thanks for the feedback. We are actively working on the feature now, and you can follow along here https://github.com/hirosystems/stacks-wallet-web/issues/1051 and it would be great to have you test it when it's ready. We are aiming for releasing it around May.

Do you mind sharing the UI you are working on?

[landitus]

Based on the conversations in https://github.com/hirosystems/stacks-wallet-web/issues/1051#issuecomment-1097925816, I've updated the user flows. They are much simpler without the transaction logic.

Also, here's a very simple Figma prototype (It's just a screen) of the Arbitrary message signing feature. I'll be happy to mock it closer to ALEX's use case once we get more details @MarvinJanssen. @castig, if you want to share some of the UI/flows you are working on, I'd be happy to mock something around MultiSafe.xyz as well.

[castig]

@landitus Looks good to me! Our simple UI is at app.multisafe.xyz/. But I can also share our high-fidelity Figma for Console, just DMed you on Twitter.

@talhasch and @faried are working with us and are also very excited to see the progress on this feature. Let us know how we can help.

[MarvinJanssen]

@markmhx @landitus here are some concrete examples: https://github.com/MarvinJanssen/stx-signed-structured-data/tree/main/contracts

The ALEX case is similar to 0xProtocol as found on EVM chains. Users sign structured orders which can be aggregated off-chain and then matched together later. The act of matching is submitting two signed orders to a smart contract which then makes an asset swap happen atomically.

Some more use cases:

• Oracle messages, example structure could be a tuple like this:
  • Oracle data, like a price point (buff)
  • Any metadata (various)
  • Signer (principal)
• Bridge messages:
  • Sender (principal / buff)
  • Recipient (principal)
  • Unique token identifier (principal / buff)
  • Amount / ID (uint)
• DAO votes:
  • Voter (principal)
  • Proposal ID (various)
  • For/against (bool)
• Multisig vault:
  • Signer (principal)
  • Recipient (principal)
  • Amount (uint)

And so on... if you want me to generate some mock CVs I can do that too but I think you get the idea.

[landitus]

Thanks @MarvinJanssen. I've mapped a simple flow to sign an order. Let us know if it's correct. Right now it's simple, but wanna keep this as a baseline reference as other features or edge cases may appear in the future.

Figma