[question](snap): Why doesn't Snap support `sign_typedData`?

[pauldesmondparker]

Summary

From Masca Desgin:

Why doesn't Snap support sign_typedData?

[!Note] I realize this is a Snap question, but I couldn't find any reference to the constraint or decision that dictates this behavior with them.

Expected behavior / User Story

When interacting with a web interface that is open-source and common to multiple entities, if everyone acts in good faith then the web agent will build objects for signing faithfully. However, in the real world we can expect these entities to modify the code for their own benefit, and unless the user is very vigilant then they may sign something that is not as presented by the web interface.

We'd prefer the snap to create the object for signing and then sign it from the snap context.

[martines3000]

@pauldesmondparker Hi. We don't support signing typed data inside Masca, as it is not allowed by the MetaMask Snaps execution environment. The code that disallows it, can be found here: Blocked RPC Methods.

For this to work, we sadly need to wait for the Snaps team to allow these methods.

I also tested it and created a PR for Masca, which we will revisit some time later when the methods are enabled.

Thanks for asking and showing interest in Masca. :rocket:

May I ask what you are building with Masca?

[pauldesmondparker]

Thank you @martines3000. This is exactly what I wanted to know.

The MVP we're working on at present is a telecommunications-based DAO that allows data connections to be made collaboratively between data centers, I.e., a telecommunications service provider can become a link in a much longer data connection, thereby increasing their commercial reach without the need for a direct relationship with every other involved party.

Some of the more interesting parts of the project include:

1. DIDs for identification
2. Snap for displaying sensitive information to the end customer without revealing it to the UI provider (service provider portal). Achieved through DIDComm and the protocol coordinate-mediation v3 (we contributed a PR of this version of the protocol at Veramo).
3. zkEVM (ConsenSys Linea) for producing escrow contracts that are fully private (layer 2), yet provide proofs to layer 1 that enforce commercial transactions.
4. Tokenomics that emphatically does not allow any windfall mechanics. All tokens are minted to member service providers (SPs) as IOUs (allocations) in proportion to SP escrow activity (with built-in decay), thereby making service providers liquidity providers of the token while they are active. The intention is to build on this MVP to create a open standard for tokens firmly backed by real world goods and services. Conforming tokens would then become a mesh of tokens that can support a world economy with meaningful and appropriate overlapping optimal currency areas, and strong resistance to asymmetrical shocks (given that currencies would no longer be national and/or amorphous baskets of uncertain value).

[martines3000]

@pauldesmondparker Sounds awesome, a lot of state-of-the-art technologies combined. Good luck with the project :100:. If you encounter any extra issues with Masca, feel free to contact us.