Create an end-to-end substrate connect prototype

[raoulmillais]

Introduction

Create an end-to-end prototype to get more insight into this:

@gavofyork:matrix.parity.io
so whether it's substrate-lite or substrate --light, i don't really care, but what it should be doing is running either:
in-browser (in a site's instance, this should allow completely new users to use the site without needing to go to (RPC) servers)
in-browser-extension (better, since it's stateful between restarts and across sites)

This is an umbrella ticket to describe the architecture and design needed to have a working end-to-end prototype. It is a migration from #82

All tasks are tracked under the v0 Milestone

Theory

We can make a polkadot-js API provider that makes the use of an extension transparent to the application developer.

Proposed API for using the extension from a web page

A page exists in a browser tab and a page may instantiate multiple UApps to talk to the extension. Each UApp may talk to multiple networks (blockchains).

Proposed flow:

Substrate-connect tries to detect the availability of extension on browser that uApp runs on:
Extension installed: Web page -> sc.detect -> ExtensionProvider (extension) -> smoldot
Extension not installed: Webpage -> sc.detect -> SmoldotProvider -> smoldot

Proposed developer experience - public API for substrate connect

import { UApp } from '@substrate/connect';

// Create a new UApp with a unique name
const app = new UApp('burnr-wallet');
const westend = app.detect('westend'); 
const kusama = app.detect('kusama'); 

const chain = await westend.rpc.system.chain();
westend.rpc.chain.subscribeNewHeads((lastHeader) => {
  console.log(`${chain}: last block #${lastHeader.number} has hash ${lastHeader.hash}`);
});

const ksmChain = await kusama.rpc.system.chain();
kusama.rpc.chain.subscribeNewHeads((lastHeader) => {
  console.log(`${ksmChain}: last block #${lastHeader.number} has hash ${lastHeader.hash}`);
});

// etc ...

westend.disconnect();
kusama.disconnect();

// Create another UApp
const sbd = new UApp('smoldot-browser-demo');
const sbdWestend = sbd.detect('westend'); 

// interact with chain

sbdWestend.disconnect();

The UI

Designs for the extension UI

How will the extension UI integrate with the connection management

The ClientManager of the extension is primarily concerned with managing communication ports from UApps and the smoldot clients and brokers communication between them.

In contrast the UI is primarily concerned with what apps are on which browser tab (and URL) and which networks those apps connect to.

To achieve this the background will also maintain and expose a shared state data structure as a tree that groups the apps under the browser tab where they were instantiated, the URL of that tab and their connections to networks . It will also be responsible for triggering events when the state associated with a tab changes.

How will the UI interact with the state?

const manager = chrome.runtime.getBackgroundPage().manager;
const state = manager.getState();

manager.on('stateChanged', () => {
  const newState = manager.getState();
  // update the UI with the new state
});

What is the shape of the shared datastructure

The UI should not try to update the datastructure - the background will always return a new representation when asked for one (frozen, immutable?)

[{
  tabId: 0,
  name: 'burnr-wallet',  // unique name supplied by developer
  networks: [{name: 'westend'}],
},
{
  tabId: 1,
  name: 'smoldot-browser-demo',  // unique name supplied by developer
  networks: [
    {name: 'westend'},
    {name: 'kusama'}
  ],
}]

Task tracking

All tasks are tracked under the v0 milestone

The non UI extension tasks are labelled extension-bg

The UI extension tasks are labelled extension-ui

[wirednkod]

Prototype is created and PoC phase is behind us - so I will close this