Hello,

I would like to ask a few questions and I think those points should be made clear in the proposal.

• how do you plan maintenance: keeping up with Jaco's pace is no simple story and the extension will need frequent updates to keep up. Do you plan on requesting more funding to keep the extension Ad and Referral free ? Or do you plan on going the Ad / Referral route ?
• do you plan a dark theme ? :)
• In your proposal, the solution to garanty a good security is to encrypt the secret with a user password. I think you could extend on the topic.
• Do you plan on supporting the Parity Signer as well ? You mention "hardware wallet support" without much details.
• in a wallet project, I think it would be good to include some auditing or testing solely dedicated to the security aspects. You mention that the project will be open source and you welcome external help but this is a rather weak plan to ensure security.
• Why restricting to Polkadot and Kusama only ? And not including at least testnets such as Westend ?
• Could you mention the licensing scheme you are planning ?

Checking out the proposal, I see:

• Sending and receiving funds
• Address book
• Multi-wallet support - with the goal of having a single wallet focused UI
• Realtime fiat balance with multiple fiat currency options
• Access management for apps using the extension
• Developer documentation for integrating the extension
• Built in support for staking
• Hardware wallet support
• And much more…

However, a big part is not part of the milestones. So it appears that the deliverable for 200K are:

• Sending and receiving funds
• Address book
• Multi-wallet support - with the goal of having a single wallet focused UI
• Realtime fiat balance with multiple fiat currency options
• Access management for apps using the extension
• Developer documentation for integrating the extension

Which does not bring much compared to the current extension beside seeing the balances while being restricted to Polkadot and Kusama.

Hey @chevdor

Thanks for all the questions. The following points should answers all of the points you've raised and we will make sure we also update the document accordingly based on these discussions.

how do you plan maintenance: keeping up with Jaco's pace is no simple story and the extension will need frequent updates to keep up. Do you plan on requesting more funding to keep the extension Ad and Referral free ? Or do you plan on going the Ad / Referral route

I've just added a section for maintenance in the document that goes over the entire aspect of maintenance. I would just like to iterate those points here.

• Bugs and vulnerabilities: The main goal of maintenance would revolve around looking out for bugs and various vulnerabilities that the community might stumble upon.

• Keeping up with the core extension: Since we would be building on top of the current extension, we have to be quite proactive in getting all the core changes in polkadot extension and including them into this extension.

• Feature requests: Since this project would be built in an open environment, feature requests are something that’s bound to happen. We will keep a track of those requests and implement them based on community requests.

• Upgrades: Fast moving technologies also come with a lot of changes both in terms of the libraries we use as well as the protocols we build upon. Regular upgrades to those would be critical in keeping the longevity of the project.

As you said to keep the extension ad free would require sourcing funds that can help us keep up with maintenance. We plan on doing a quarterly cycle to ask for funding from the treasury.

do you plan a dark theme ? :)

We didn't think of this but it seems like a really good idea, and since we are building a design system adding a flow for a dark theme shouldn't be too cumbersome.

In your proposal, the solution to garanty a good security is to encrypt the secret with a user password. I think you could extend on the topic.

The way we would approach this is based on a keyring model that's used in the metamask wallet. Instead of me explaining and essentially plagiarising the whole thing, you can take a look at this example that provides a good explanation of this.

Do you plan on supporting the Parity Signer as well ? You mention "hardware wallet support" without much details.

We are basing our hardware wallet support on the current extension. Parity Signer would require some additional support so we'll have to add it to our backlog.

in a wallet project, I think it would be good to include some auditing or testing solely dedicated to the security aspects. You mention that the project will be open source and you welcome external help but this is a rather weak plan to ensure security.

We wanted to get started with building the extension with a basic set of security in mind. These revolve mostly around generic security measures like click jacking and xss that happen in chrome extensions. Once we have some traction and by that I mean a few beta users, we'll move to either an external agency or hire someone who can audit the extension from a security standpoint. I am more than happy to discuss if there is something that you'll like to expand on.

Why restricting to Polkadot and Kusama only ? And not including at least testnets such as Westend ?

We should've been more clear about this, we would have both Rococo and Westend in the list of options. I'll add this in the document too. For other networks, we wanted to get started with Polkadot and Kusama first since it would keep the issues limited while we built and tested the extension. Once we have something more battle-tested we'd open up for other networks.

Could you mention the licensing scheme you are planning ?

We would be going for an Apache License, same as the current polkadot extension.

For the things that are included in the current milestones, we would add hardware wallet in the milestones too. Apart from that the costing also including building the website and the documentation website along with. The only thing that's not there is staking, which requires a good amount of effort from what I can envision.

Do let me know if you want me to expand on any of the points I mentioned. I'll also be updating the document to include the changes I mentioned here so that there is no discrepancy.

Can you make it clear that this is not associated with the older speckle wallet extension that is built?

You should change the name to avoid this confusion

Hey @umapr

Thanks for the heads up. Yup we came to know about this fairly recently and we are not related to the older speckle extension. We've changed the name to just Speck so it doesn't conflict.

voting aye because it's good to see some comittment to multisig support, something I really want to see other takes on than we currently have available - I somewhat share chevdor's concern though, that it

does not bring much compared to the current extension beside seeing the balances while being restricted to Polkadot and Kusama.

especially since you'd be building on top of the current extension. I'd be significantly more excited if you had said you were building on top of substrate-connect.

Does this mean that users will require both extensions installed and yours will just call the other one (in which case it doesn't make sense to launch an extension, we could probably do with more simple webuis to use with the extension after all)? or do you mean that your codebase will be built on top of the existing extension and will be inheriting its features and expanding on it?

I will point out that where previous efforts to develop alternative extensions have failed pretty fundamentally is in tailoring their user experience to the fact that they are building on blockchain, and in reliability of their "online" functionality (ie, having a limited or hardcoded set of backend nodes to communicate with the network, or poor error handling when interactions fail or rpc nodes are being unreliable).

That said, I do hope that in the longer-term this project sticks to the philosophy that the Polkadot js extension and apps ecosystem has pioneered, wherein we have not seen centralization of rpc infrastructure due to not having a central rpc endpoint in the most widely used browser extensions as Metamask provided with Infura in the early days, even if this extension will be "online" and allow users to make extrinsics themselves. In my opinion we should stick to the story where app devs provide their own endpoint(s), and extensions only respond to signature requests, until we have a stronger story around extension-embedded light clients.

As a power user I would be incredibly grateful to have a tab or experience similar to the developer>extrinsics tab in the apps UI, available on any network with Metadata, or at the very least, inheriting (from polkadot js) the ability to inspect raw extrinsics that the extension is requested to sign, but expanding upon it with a way to submit raw extrinsics for signing and broadcasting manually, or editing the extrinsics passed to the extension for signing prior to doing so (maybe decode the raw input in real time?) because that is a deep gap in the third party wallet ecosystem - everyone does staking and transfers - users will just use Fearless or Nova or Polkawallet - give us some flexibility that the rest of the ecosystem does not provide, and let users do what can currently only be accomplished in the apps UI, and your extension will be something I might actually use myself 😅.