Compatibility of Blinks and Actions

[tsmbl]

Context & Problem

Based on sRFC https://forum.solana.com/t/srfc-31-compatibility-of-blinks-and-actions/1892

Response headers are proposed to be set by Action developers:

• X-Action-Version to show what spec version the action API server is using
• X-Blockchain-Ids to list blockchains the action supports.

In the future request headers are proposed to be set by Blink clients:

• X-Accept-Action-Version to show the max spec version the Blink client supports.
• X-Accept-Blockchain-Ids to list blockchains the client supports.

Response headers should be used to decide if Action supported by client.

Solution

1. Allow specifying action adapter metadata, this data can be used in default supportability checks and later can be used to set X-Accept-Blockchain-Ids` request header.
2. Parametrize action with supportedBlockchainIds strategy
3. Provide utility functions for supportability checks by comparing action & blink metadata:

• Semver versions: action is not supported if action provider spec version > blink library spec version, patch version is ignored during comparison.
• Blockchain IDs: action is not supported if there's at least one blockchain id that is not supported by blink library client

4. Provide default implementation for metadata and supportability in ActionConfig

Breaking changes

• move isSupported from ActionAdapter, to Action and to ObserverOptions correspondingly

Example adapter initialization

1. Default settings in ActionConfig: in this case client supports solana mainnet & devnet + spec version from package.json

const defaultActionConfig: ActionConfig = new ActionConfig(
  'http://localhost:8080',
  {
    connect: async (c) => {
      return 'connected';
    },
    signTransaction: async (tx, c) => {
      return { signature: 'signed' };
    },
  },
);

2. Configure metadata in ActionConfig: in this case client supports supportedBlockchainIds + spec version from package.json, supportedBlockchainIds can be later used to set X-Accept-Blockchain-Ids request header

const actionConfigWithMetadata: ActionConfig = new ActionConfig(
  'http://localhost:8080',
  {
    metadata: {
      supportedBlockchainIds: [BlockchainIds.SOLANA_MAINNET],
    },
    connect: async (c) => {
      return 'connected';
    },
    signTransaction: async (tx, c) => {
      return { signature: 'signed' };
    }
  },
);

3. Overriding default supportStrategy in useAction

 const { action } = useAction({
    supportStrategy: async () => ({
      isSupported: false,
      message: 'Message to be displayed.',
    }),
    // ...rest
  });

4. Overriding default supportStrategy in setupTwitterObserver

setupTwitterObserver(
  null as unknown as ActionAdapter,
  {},
  {
    supportStrategy: async (a) => {
      const versionSupported = a.metadata.version === '2.2.8';
      if (!versionSupported) {
        return {
          isSupported: false,
          message: 'Version not supported',
        };
      }
      return {
        isSupported: true,
      };
    },
  },
);

Related PR in actions spec: solana-developers/solana-actions#21
Related PR in actions-proxy: https://github.com/dialectlabs/actions-backend/pull/2

[zhelezkov]

this is really good job
Love the documented code and tests!

[zhelezkov]

why 2.0.0? shouldn't it be 2.2 or smth?

[tsmbl]

was a question of release sequencing, I think ok to use 2.2 now since chaining and inputs are merged

[fsher]

amazing job! minor comments