JSON-RPC WG - 16 Sept 2024

[bumblefudge]

16 Sept

• agenda?
  • caip2 defined two different ways- creates ugly merge case
  • naming convention: jiexi's PR

What to do with the following ambiguous request:

requiredScopes: {
    'eip155': {
        references: ['1', '10', '1032', '0x00'], //<-- 0x00 is invalid acc to eip55
        methods: [
            'eth_sendTransaction',
            'eth_accounts',
            'eth_blockNumber',
            'eth_getBalance',
            'personal_sign',
        ],
        notifications: ['accountsChanged', 'chainChanged'],
    },
    'eip155:1032': {
        methods: ['l2SpecificMethod'],
        notifications: ['specialSnowflakeEvent'],
    },
},

Option 1: wallet cleans up request and sends "postel's law" response

sessionScopes: {
    'eip155': {
        scopes: ['1', '10'], //<-- 1032 removed to disambiguate
        methods: [
            'eth_sendTransaction',
            'eth_accounts',
            'eth_blockNumber',
            'eth_getBalance',
            'personal_sign',
        ],
        notifications: ['accountsChanged', 'chainChanged'],
    },
    'eip155:1032': {
        methods: [ //<-- methods moved from above
            'eth_sendTransaction',
            'eth_accounts',
            'eth_blockNumber',
            'eth_getBalance',
            'personal_sign',
            'l2SpecificMethod'
        ],
        notifications: ['accountsChanged', 'chainChanged', 'specialSnowflakeEvent'],
    },
},

Option 2: Throw error 5204 (everyone's allowed to do it, but what if they want to give the req the benefit of the doubt, postel-wise?)

Option 3: Be chill, let it ride (i.e. merge but don't tell the dapp you did so)

Option 4: Least privilege, NOT union-of-requests/additive

return

requiredScopes: {
    'eip155': {
        scopes: ['1', '10'], //<-- i.e. 1032 removed
        methods: [
            'eth_sendTransaction',
            'eth_accounts',
            'eth_blockNumber',
            'eth_getBalance',
            'personal_sign', 
        ],
        notifications: ['accountsChanged', 'chainChanged'],
    },
    'eip155:1032': { //<-- least authority, only what they _might_ have been requested
        methods: ['l2SpecificMethod'],
        notifications: ['specialSnowflakeEvent'],
    },
},

MM is breaking up eip155 object into multiple single-chain namespaces anyways, that should probably be legalized explicitly (and the ambiguous case explained )

PRs to refine/move to close

Ongoing issues/topics

Next Steps

• BF will open a PR legalizing "merge requiredScopes" object?
• separate or same PR to redefine 5203 as "reference invalid for this namespace";
• to ponder: should error messages maybe be more explicitly pick-and-choose, recycled as warnings instead of errors, etc.? or is that implicit in the implementation of any spec of this na?