Extension refurbish - scope/specs

[wirednkod]

(Note: From Element's conversation cc @tomaka )

A summary of what should be in the extension's UI, I think:

• The status of the four well-known chains.
• The status of the chain connections from web pages.
• A way to ban web pages that have chain connections. Finish implementing possibility to ban tabs from the extension #738
• A way to see the list of previously banned web pages and unban them. Finish implementing possibility to ban tabs from the extension #738
• A way to customize the bootnodes of the four well-known chains.
• Some semi-hidden way to see the smoldot logs, and maybe show some kind of big popup if smoldot crashes so that the user sends a bug report. Smoldot - crash strategy #507 Fix extension logging strategy #429

Note that I'm not saying that the chains should be in a simple vertical list, I'm just saying that we want to show them in some way.
"status" is a bit vague, but includes:

• The name taken from chain spec.
• Networking status, such as a number of peers. This is also blurry. The user should have a way to understand why connectivity doesn't work, in case connectivity doesn't work.

We could eventually also add more information about chain connections, such as the current block number, maybe number of validators, etc. but not on the main screen. This kind of info should IMO be considered as technical details, and the extension is targeted at the average Joe and not at technical people

There's one thing I'm unsure of, which is whether to show relay chain <-> parachain relationships. For example if a website connects to Westmint (a Westend parachain), should the extension UI show that it's a parachain of Westend? IMO relay chain <-> parachain relationships are also technical details that don't need to be shown to the average Joe, but it could be shown as long as it's not confusing if you don't really know what a parachain is.

[wirednkod]

My PoV extending Pierre's wors (dont feel bonded on it):

View 1 (PopUp - Quick Access):

Title

• The status of the chain connections from web pages
• A way to ban web pages that have chain connections.
• Link to Options/Settings
• Link to Extension Page/Info

View 2 (Options/Settings):

Tab 1 (current view options):

• The status of the four well-known chains.
• A way to customize the bootnodes of the four well-known chains.
• More Info about Chain Connections (relation chains<->parachains, tab connected to which chain)

Tab2 (Settings/Configuration):

• Notifications Settings (on/off)
• A way to see the list of previously banned web pages and unban them.
• Some semi-hidden way to see the smoldot logs, and maybe show some kind of big popup if smoldot crashes so that the user - sends a bug report.

[tomaka]

Did some quick sketch of what I had in mind, of course this can be changed, I'm not a UI designer:

The list of all chains smoldot is connected to is displayed in alphabetical order.

The "gear" is clickable and would bring you to a screen that lets you configure the bootnodes of that "Default chain".
The connectivity icon (red or green) is also clickable and would show details about connectivity to the chain. Exactly which details to show is a very tough question, so initially this can be made non clickable.

I have intentionally not put "Statemine" under "Kusama" even though they're a relay chain <-> parachain couple, because the average Joe who will use the extension doesn't necessarily know the concepts of relay chain and parachain, and it shouldn't matter for him anyway.

[Goranch3]

A few questions @tomaka :

1. "The status of the chain connections from web pages"

• Should we show inactive state of networks (e.g. roroco network not connected) ?

2. "A way to customize the bootnodes of the four well-known chains."

• Can user choose multiple bootnode sources for a network, e.g network is Polkadot and users have choices: "Parity" and "Custom" can they select both?

Can you put a bit more context to the sketch you made, where does this live in the UI, to me it looks like a pop-up view of the extension where apps are grouped around networks?

[tomaka]

Should we show inactive state of networks (e.g. roroco network not connected) ?

Yes! Users need to be able to know that there's a not-connected network and understand why it's not connected.

Of course a network should only be visible either if it's used by an app or if it's a default network.

Can user choose multiple bootnode sources for a network, e.g network is Polkadot and users have choices: "Parity" and "Custom" can they select both?

Here's an example of what a list of bootnodes looks like:

substrate-connect/packages/connect/src/connector/specs/polkadot.json

Lines 6 to 21 in e4fb6e4

	"/dns/polkadot-connect-0.parity.io/tcp/443/wss/p2p/12D3KooWEPmjoRpDSUuiTjvyNDd8fejZ9eNWH5bE965nyBMDrB4o",
	"/dns/polkadot-connect-1.parity.io/tcp/443/wss/p2p/12D3KooWLvcA24g6sT9YTaQyinwowMbLF5z7iMLoxZpEiV9pSmNf",
	"/dns/polkadot-connect-2.parity.io/tcp/443/wss/p2p/12D3KooWDhp18HYzJuVX2jLhtjQgAhT1XWGqah42StoUJpkLvh2o",
	"/dns/polkadot-connect-3.parity.io/tcp/443/wss/p2p/12D3KooWEsPEadSjLAPyxckqVJkp54aVdPuX3DD6a1FTL2y5cB9x",
	"/dns/polkadot-connect-4.parity.io/tcp/443/wss/p2p/12D3KooWFfG1SQvcPoUK2N41cx7r52KYXKpRtZxfLZk8xtVzpp4d",
	"/dns/polkadot-connect-5.parity.io/tcp/443/wss/p2p/12D3KooWDmQPkBvQGg9wjBdFThtWj3QCDVQyHJ1apfWrHvjwbYS8",
	"/dns/polkadot-connect-6.parity.io/tcp/443/wss/p2p/12D3KooWBKtPpCnVTTzD7fPpCdFsrsYZ5K8fwmsLabb1JBuCycYs",
	"/dns/polkadot-connect-7.parity.io/tcp/443/wss/p2p/12D3KooWP3BsFY6UaiLjEJ3YbDp6q6SMQgAHB15qKj41DUZQLMqD",
	"/dns/p2p.0.polkadot.network/tcp/30333/p2p/12D3KooWHsvEicXjWWraktbZ4MQBizuyADQtuEGr3NbDvtm5rFA5",
	"/dns/p2p.1.polkadot.network/tcp/30333/p2p/12D3KooWQz2q2UWVCiy9cFX1hHYEmhSKQB2hjEZCccScHLGUPjcc",
	"/dns/p2p.2.polkadot.network/tcp/30333/p2p/12D3KooWNHxjYbDLLbDNZ2tq1kXgif5MSiLTUWJKcDdedKu4KaG8",
	"/dns/p2p.3.polkadot.network/tcp/30333/p2p/12D3KooWGJQysxrQcSvUWWNw88RkqYvJhH3ZcDpWJ8zrXKhLP5Vr",
	"/dns/p2p.4.polkadot.network/tcp/30333/p2p/12D3KooWKer8bYqpYjwurVABu13mkELpX2X7mSpEicpjShLeg7D6",
	"/dns/p2p.5.polkadot.network/tcp/30333/p2p/12D3KooWSRjL9LcEQd5u2fQTbyLxTEHq1tUFgQ6amXSp8Eu7TfKP",
	"/dns/cc1-0.parity.tech/tcp/30333/p2p/12D3KooWSz8r2WyCdsfWHgPyvD8GKQdJ1UAiRmrcrs8sQB3fe2KU",
	"/dns/cc1-1.parity.tech/tcp/30333/p2p/12D3KooWFN2mhgpkJsDBuNuE5427AcDrsib8EoqGMZmkxWwx3Md4"

Users should be able to customize this list, adding and removing individual elements.
There is a default list, but this default list exists only for convenience and doesn't have any special status.

In principle, "ideologically speaking", there shouldn't be any default bootnode, and users would have to configure bootnodes when they install the extension. But that would be very annoying and non-user-friendly, and for that reason we have a default list. The point again is that the bootnodes in a default list aren't special compared to the ones manually entered and are here just for convenience.

Can you put a bit more context to the sketch you made, where does this live in the UI, to me it looks like a pop-up view of the extension where apps are grouped around networks?

Yes!

[wirednkod]

Users should be able to customize this list, adding and removing individual elements.
There is a default list, but this default list exists only for convenience and doesn't have any special status.

While discussing with Goran - my proposal, was to have a grouping of bootnodes (and capability of adding groups) that user would be able to save in the extension and choose which ones to select - meaning:

• Parity:

["/dns/polkadot-connect-0.parity.io/tcp/443/wss/p2p/12D3KooWEPmjoRpDSUuiTjvyNDd8fejZ9eNWH5bE965nyBMDrB4o", 
 "/dns/polkadot-connect-1.parity.io/tcp/443/wss/p2p/12D3KooWLvcA24g6sT9YTaQyinwowMbLF5z7iMLoxZpEiV9pSmNf",]

• OnFinality:

["/dns/polkadot-connect-0.parity.io/tcp/443/wss/p2p/12D3KooWEPmjoRpDSUuiTjvyNDd8fejZ9eNWH5bE965nyBMDrB4o", 
 "/dns/polkadot-connect-1.parity.io/tcp/443/wss/p2p/12D3KooWLvcA24g6sT9YTaQyinwowMbLF5z7iMLoxZpEiV9pSmNf",]

• CustomOne:

["/dns/polkadot-connect-0.parity.io/tcp/443/wss/p2p/12D3KooWEPmjoRpDSUuiTjvyNDd8fejZ9eNWH5bE965nyBMDrB4o", 
"/dns/polkadot-connect-1.parity.io/tcp/443/wss/p2p/12D3KooWLvcA24g6sT9YTaQyinwowMbLF5z7iMLoxZpEiV9pSmNf",]

etc, etc
and user would be able to select (or deselect) 1 or more (and we would concatenate them to a list of bootnodes)

[tomaka]

I find this a bit overkill. The reason why you need to be able to customize bootnodes are:

• In case you are running your own node, which only very technical people would do
• In case the default ones go down, which is never supposed to happen

Bootnodes aren't something that you change every week or even every month. It's something that you do either once (and only if you're a very technical person), or temporarily in case of emergency.

Basically all we want is to give the users the possibility just in case. It doesn't need to be an actual feature.

[Goranch3]

The question on my side is strictly UI based, the "default" is one choice in UI, right? As a user you can add a new choice of bootnodes so now you have 2 choices. Can user say I want to select both choices or does one exclude the other, @tomaka from your answer I would say they can use both, I am right?

[tomaka]

What I had in mind is that the user would be presented with one list. The list is initially filled with the default bootnodes, and you can add/remove individual elements from that list.
And next to the list, a "Reset to default" button in case the user fucks up.

Bootnodes don't need to be grouped into categories or multiple lists or whatnot. There can be only one list per chain and you modify that list.

[Goranch3]

OK that's easy from the UI perspective, on the other hand it's very user-unfriendly, basically we are spilling what's under the hood right in the UI. Might not be an obstacle considering the user profile, but Niko's solution is way more elegant, anyways question answered, thanks.

[tomaka]

we are spilling what's under the hood right in the UI. Might not be an obstacle considering the user profile

I'm not saying I'm correct, but that's intentional. We don't want users to think that they actually have to use that. Again, this feature is only either for very technical people or in case of emergency. And even in case of emergency the idea is that the average user would follow the instructions of someone technical.

There is no point in having multiple pre-existing lists of bootnodes that the user can switch between, because there is no advantage in leaving bootnodes disabled.
Bootnodes are simply a list of machines that we know are part of the chain. You need at least one functional bootnode for smoldot to be able to connect, but you can have as many as you want and adding more doesn't hurt in any way.

[wirednkod]

This can close due to deprecated specs (banned pages) and in favour of #975