Secret Network Permits Support

[luca992]

Permits support

• Determine if permits are supported after the user enters a certain contract address.
• If it has permit support - create a permit instead of a VK.
• If it has permit support - under (Advanced), let the user switch back to VKs if they want.
• If it has permit support - under (Advanced), also keep the current option of importing an existing VK.
  If not permit support - keep current behavior.

Note:

• To check if a contract supports permits, I am querying the contract with a fake permit and parsing the returned error to see if the its a deserialization error (no permit support) or an invalid permit error (has permit support).
  • Decoding errors was broken, and I had to fix the regex.
• I did not hide away viewing keys as the spec asked. Instead I just displayed whether or not permits are supported and disabled the permit button accordingly. I just think it will cause confusion for users if viewing keys are hidden under advanced (at least in the transition period where apps will have to add support for loading permits from keplr)... Maybe in a month or two once apps support loading permits it would be more appropriate to hide it away imo. However, if you want exactly what the spec says I'll change it no problem.
• Users can specify the permit permissions by typing the permissions in a comma/space separated list
• Loading a suggested viewing key wasn't actually implemented before. It now does load a suggested viewing key.

Examples:

API suggestToken()

Add another option that is on by default for creating a permit instead of a VK:

Old:

suggestToken(chainId: string, contractAddress: string, viewingKey?: string): Promise<void>;

Spec New:

suggestToken(chainId: string, contractAddress: string, viewingKey?: string, createPermit: boolean = true): Promise<void>;

// if viewingKey is set, store it as a VK
// else if createPemit == true, create a permit and store it as a permit
// else if createPemit == false, open the AddToken screen

New actual implementation:

suggestToken(chainId: string, contractAddress: string, viewingKey?: string,  suggestViewingKey: boolean = true): Promise<void>;

// if suggestViewingKey is set, store it as a VK
// else if suggestViewingKey == false, open the AddToken screen with create a permit option selected.
// else if suggestViewingKey == true, open the AddToken screen with the viewing key option selected

Note:

• I set suggestViewingKey: boolean = true by default because if it were false to instead suggest creating a permit it would basically be incompatible with all current apps. Since all current apps expect a viewing key to be made when suggestToken is called, not a permit.

API getSecret20ViewingKeyOrPermit() (name TBD)

Spec:

// Deprecate this in the future (with proper notice):
getSecret20ViewingKey(chainId: string, contractAddress: string): Promise<string>;

// Add this API function:
getSecret20ViewingKeyOrPermit(
  chainId: string, 
  contractAddress: string
): Promise<{permit: object | undefined; viewing_key: string | undefined;}>;

// Return both permit & VK if any of them exist

Actual implementation:

• Instead of getSecret20ViewingKeyOrPermit I think getSecret20QueryAuthorization might be better. Because to me, using a viewing key or permit in a query is similar in concept to adding a authorization header to a rest call. That way instead of listing all the authorization types in the name it just broadly imply it can return any kind of authorization object. I am pretty sure authorization is the correct terminology of what a viewing key or a permit does.

getSecret20QueryAuthorization(
  chainId: string,
  contractAddress: string
): Promise<{ permit: Permit | undefined; viewing_key: string | undefined }>;

// Returns permit or VK if either exists. (only one or the other can be stored)

• Note: instead of returning { permit: Permit | undefined; viewing_key: string | undefined } I could expose the internal QueryAuthorization class and return that, which would debatably be cleaner. But up to you guys, just something to think about.