Proposal: Internal use of RPC API

[kyranjamie]

Try out Leather build c77bc37 — Extension build, Test report, Storybook, Chromatic

This PR proposes that we utilise our RPC API internally. Rather than building some flows internally (send form signing step, sending inscriptions etc) we run actions exclusively via our API.

Demo

2025-09-05-000510.mp4

2025-09-05-000512.mp4

https://trustmachines.slack.com/archives/C05LRS7G44R/p1757059108955959

Motivation
Leather currently has a several ways of doing the same thing. Consider signing a tx. This is currently done in three places: legacy JWT flows, RPC API, and actually in the extension (send form). This is very costly to maintain and just not a particularly efficient way of building a wallet. We need to move quickly, and this slows us down.

Using the RPC API exclusively has several benefits. First, we'll be more efficient as we build one flow flawlessly and reuse it everywhere. Second, as we build our features for ourselves, we can also expose them as an API. Consider inscription sends. This can be done in the wallet, but there's no API for it. If we'd built this as an API from the start, we could've exposed this as an API for apps to use as well, slowly growing a more compelling suite of tools for builders.

Some changes to the message passing are made here. This is the existing behaviour: we pass the RPC events around, then the popup returns it directly to the tab.

Existing flow

Mermaid

sequenceDiagram
    participant App
    participant ContentScript
    participant Background
    participant Popup

    App->>ContentScript: new CustomEvent()
    ContentScript->>Background: chrome.runtime.Port
    Background->>Popup: chrome.window.open()
    Popup->>ContentScript: chome.tab.sendMessage()
    ContentScript->>App: window.postMessage()

Loading

Here, this changes such that the RPC result is returned via the background script.

Proposed flow

Mermaid

sequenceDiagram
    participant App
    participant ContentScript
    participant Background
    participant Popup

    App->>ContentScript: new CustomEvent()
    ContentScript->>Background: chrome.runtime.Port
    Background->>Popup: chrome.window.open()
    Popup->>Background: chome.runtime.sendMessage()
    Background->>ContentScript: chome.tab.sendMessage()
    ContentScript->>App: window.postMessage()

Loading

The reason for this change is that, if the extension can also trigger the RPC APIs, then it isn't necessarily a tab we need to send the result to. It could be the action popup that has no tabId. I've baked in some conditional logic that changes the transport depending if the origin is the extension. I'm not 100% on this change, as it does add an additional dependency on the background script, that has revealed some race condition behaviours (e.g. the closed window listener returns an error event as it's detected before the success result). Either these need to be fixed, or the conditional logic should happen in the popup.