Stacks-wallet-web: Expose method to sign arbitrary messages

Thanks for posting this! I think such a feature is crucial.

Thanks for posting this! I think such a feature is crucial.

I agree, and I think many on the team would agree, too 👍 I'll work to update this issue as we talk through it.

@MarvinJanssen Mind indicating the use case(s) you'd like to build in the short-term with this to help weigh priorities?

@markmhx talking short-term, there is really only one reason why I need it.

I am creating a server-side component that tracks user app bucket URLs (for zonefiles). In order to secure this API, the user should sign his/her bucket URL with Connect. The server then resolves the user's reported BNS name via the BNS contract and uses the corresponding principal to verify the signature. I basically need to verify that a specific message actually came from a principal who owns a name on BNS. If you have alternative solutions, let me know. My backup plan was introducing simple Clarity contract and having the user submit a proof via contract call, but that makes it a workaround for a workaround for a workaround...

there are 2 main other use cases I've seen signatures being used on Eth:

• prove you own an address and the site will reveal analytics only you can see about your address (which is nice)
• vote (unlike uniswap for example, which requires paying gas fee, synthetix only requires a signature per vote, costing you nothing, which sounds about right for governance voting)

@psq yep long term we need it for DeFi and DeX, and platforms that do server-side matching that require user signatures. (Like 0x Protocol and Wyvern on Ethereum.)

Thanks for the additional context 🙏 I'm assigning to Jasper so he can design.

I see this is in the icebox @markmhx does that mean it will be considered in a later sprint? @MarvinJanssen is awaiting updates 🙂

I've moved back this issue back into the Kanban backlog.

Note that we're no longer working against 2-week sprints but rather incremental delivery of priorities as reflected in the backlog from top to bottom.

I am totally on board with evaluating a system for signed typed data structures, but that's a much bigger engineering task that I don't think we should take on first. The main benefit of the structured data is to fee-less on-chain transactions with logic tied to the data in that signature. However, two things:

• Sponsored transactions make it such that any contract call can be fee-less. The only downside here is that you can't do batched signatures
• The ETH spec is very tied to how this data format can be RLP encoded and used in the EVM. We'd have to do a lot of work around determining how that might work with Clarity, and then we can make a spec out of that, and then we can add it to the wallet

Strings are the most obvious use case for Stacks at the moment. It would allow for the very common use case of providing off-chain access to a user that can prove they own an STX address. For example, a web app that gives specific functionality if you own an NFT.

To be more concrete about use cases:

• Sign into web app and prove you own a STX address
  
  
  
  • not technically solved by auth right now, because it signs with a different key from pre-2.0, but we can/should change that
  
  
• Share a specific message for off-chain that proves you own a STX address
  
  
  
  • sign a string, the "easy" version of this issue
  
  
• Fee-less token approvals
  
  
  
  • solved by post conditions
  
  
• Fee-less DAO voting
  
  
  
  • solved by sponsored transactions
  
  
• Batched fee-less DAO voting, or other complex batched on-chain fee-less stuff
  
  
  
  • needs ERC712 equivalent
  
  

It was determined during a conversation with @MarvinJanssen and @GinaAbrams yesterday that the .BTC app won't have an urgent need for arbitrary message signing unless two things happen sequentially:

1. We're unable to deploy Atlas fixes to mainnet within the next couple of weeks.
2. He's unable to implement the zonefile reporting mechanism he needs as a workaround using a custom Clarity smart contract and transaction signing and broadcasting with the Stacks Wallet extension.

The arbitrary message signing route is basically a fallback to the above routes, which are preferable in the order listed. It would involve sending signed messages with zonefile data to a centralized server, which would save the end user the cost of having to sign a transaction but also incur the undesirable involvement of a centralized party.

@agraebe @diwakergupta I'll check in with splat next week to see how the Atlas deployment plans are going so we can provide @MarvinJanssen with an update here in regards to timing and how it impacts his options.

He's happy to wait a week or two to see if we can get the fixes live on mainnet and save him the work of either workaround.

This is an invaluable thing to have, using signatures from the identity would prove the ownership of a name and a whole lot of things, especially when it comes to off-chain operations, 100% for this