Notes on an web-based ElectrumSV wallet

I occasionally think about adapting the Telescope browser extension for ElectrumSV. Telescope is a Bitcoin Cash browser wallet, which integrates with web pages and allows direct payment to QR codes in web pages and also addresses. I have a suspicion that the quickest way to extend the ElectrumSV desktop wallet into the browser, is to base it on Telescope.

This article is just me solidifying my thoughts in terms of when the best time to do a web-based ElectrumSV wallet is.

What does a browser extension like this give us?

Telescope is basically an existing working code base for a browser wallet. It’s comparable to Moneybutton in the sense that it provides access to your funds in the web browser. This is something that ElectrumSV by itself cannot do.

How does it compare to Moneybutton approach wise?

Moneybutton embeds it’s widget in an iframe if I recall correctly, and provides management of it’s wallet state through it’s own website. The actual wallet, like with Telescope, is in the user’s browser. But the widget is hosted from the Moneybutton web site, which means if the web site goes down, so does Moneybutton. Given that it is a reasonable expectation that the Moneybutton web site won’t be down in reasonable circumstances, this is an unreasonable concern that does not warrant consideration. But there’s also other benefits from a server that are easy to see in hosted wallets.

The browser extension approach, like ElectrumSV, lacks a hosting server. It also requires the user to go away and install some third party extension in their browser — which is a cumbersome requirement in and of itself. It also probably won’t work on mobile browsers, as those do not as far as I know support extensions. And this is a problem that pushes towards the Moneybutton approach. And let’s face it, browser extensions are dodgy, you never know what they are doing with all those permissions.

But the Moneybutton approach, while superior in terms of user access, adds burden in terms of requiring a host to be provided and secured. This is something we already do not have the time (or perhaps the expertise to do) when it comes to a site that represents users and where their funds go.

However, the same code that would have to be developed for the browser extension would be to a large degree presentable hosted through a javascript widget like that of Moneybutton’s. So the real value is perhaps starting with something that works with the extension, and moving to a hosted widget at a later stage.

What can we do with it?

Let’s say that I am developing a web site that offers a service of some kind. I want a way for the user to login with their BSV identity. And I don’t just want them to login with the identity, I want them to be able to interact with a remote identity. If you know that the identity of the remote party, then you can in theory use the whitepaper 42 technique, with that remote party to generate a sequence of mutual keys for communication and interaction. Encryption, signing and so on.

I wouldn’t want to build a wallet into the web site, if the web site gets compromised then the wallet can be compromised. A better approach is to integrate an external wallet like Moneybutton, or extension like Telescope. This stores the wallet and it’s keys in a user controlled location, where the user has to explicitly allow any interaction from the web site.

With the Moneybutton approach, you might not just have a payment button, but instead a range of widgets like login, and approval of various actions with modification of metadata. I have a suspicion the iframe-based embedding comes with some limitations in terms of what can be done with it.

With the browser extension, I suspect the integration can be a lot more flexible. Telescope does popup widgets, which is likely something that the iframe approach wouldn’t be able to do. But again, the same problems, some insurmountable, from above.

So what next?

Nothing.

I thought about this, and then I looked at the Telescope source code and realised that I would have to rewrite that source code in much the same ways that I need to already rewrite the existing ElectrumSV code. We’re also moving to BIP270 and Paymail and so on, and Telescope lives in the naive past with addresses and QR codes. How the extension would work would completely change with those upgrades. Until the specifications for them are finalised, it’s hard to see how.

This would be a delegated sub-account from a main ElectrumSV wallet. This means that until we have that sub-account support done in ElectrumSV itself, it can’t be properly integrated with the main ElectrumSV desktop wallet.

There’s also some overlap with other plans for ElectrumSV. In the longer term there’s a desire to rewrite the desktop wallet front end in Javascript (but not the backend which would remain in Python), using Electron, for the desktop wallet. If we did this, we could do it in such a way that we could try and share code between it and any external Javascript project like the extension or a Moneybutton-style approach.

It’s not the right time to spend any time on this, and it’s too much work that would take away from the main work on ElectrumSV. I also need to think more on how it can be integrated with a web site, with that ability to login as your BSV identity (likely Paymail).

Written by

ElectrumSV developer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store