Encrypted messages, hosted services and ElectrumSV

Over the past couple of months Kiwi AustEcon and I have been working on the hosted services support for ElectrumSV. But there’s still a final part to be done before it’s ready for integration into the wallet user interface, and that’s the structure of messages that your wallet sends to another person’s wallet via the service. In order to get the hosted service code to a level where it is used, I have selected encrypted wallet to wallet messages as the way to do that.


Many things need to fall into place before the building blocks are present to start creating some of the fun and interesting things in future for Bitcoin SV users. For ElectrumSV, a few of these are:

  • Pushdata-based indexing. The way that Electrum-based wallets currently work is that they do scripthash-based indexing, and this does not have the flexibility to build interesting things on top of. In the air: At least three parties that I know of have said they are working on pushdata indexers, and we’ve started discussing whether we can standardise the way they are accessed with Tokenized developers.
  • Hosted services. IPv6 is not a reliably usable thing, users need a representative service through which they can be contacted and who does some limited operating on their behalf. This not only allows messages to be sent to them in a private way, but it allows messages to be sent to them while they’re offline. And further down the line it can allow proxied direct connections between wallets via the service and so on.
  • Peer to peer identity. When we have hosted services that can serve indexed identities, obtaining that information from pushdata indexers, then we can have on-chain peer to peer identities. But those pieces need to be in place first.
  • Reliable wallet backup. If we add new features, the user needs to know what is backed up and that they won’t lose data.

For now, I am going to dedicate a week or so to fleshing out our open source hosting project to the point it is integrated into an alpha release of ElectrumSV. At that point it will be a usable building block that we can extend with indexer access, and external Paymail interoperability layered over the top and so on when the time arises.

Instant messaging

This will be in an alpha release of ElectrumSV. The encrypted wallet to wallet messaging will be an interesting prototype, but it won’t be throwaway work. The user interface and integration will be there to be modified for any final feature in any later proper public release. And it will push the open source hosted services code to a point where it is more ready to be built upon.

The majority of the work involved in this is defining how the messaging looks, and how it’s packaged.

  • Contacts and identity. This will be the current contacts UI and identity that we already have. You add a contact with a identity public key. It is a very raw abstraction of any later identity systems we support.
  • Notification center. We will show a per-sender based notification in the notification center we added in a recent release. As a new message comes in, it will be updated accordingly and re-featured if it has been previous read or dismissed.
  • Message UI. Clicking on a incoming message notification will display an email-client like display, where a message history is displayed for each contact who has sent messages. Maybe it will be in the messages tab, and will switch from the last viewed message.
  • Message format. We will define a instant message communication protocol format. Then we will put inside it some structured data for actual formatted messages. It makes a lot of sense to look at just using the “message” XMPP XML document structure.

We will also add some very simplistic way where people can change the public key and URL of the initial hard-coded service. If people do want to run their own servers they will be able to do so. But this is alpha-level code, and no guarantees are made about support for it.

There are a large number of complications, but to some degree these can be ignored for the purposes of this proof of concept.

  • Unwanted spam. If someone gets your public key, someone can send you messages and you get them displayed immediately. There are ways to address this later on.
  • Server abuse. If someone knows a hosted public key identity, they can just keep on pumping data as messages to that identity to the service. There are ways to address this later on.
  • Message backup. Any messages sent through this feature, will not be persisted. They might be retained in your wallet until we add cloud-based backup of wallets, and once that happens we might support these messages, or we might just delete them and maybe allow export before that happens. In the longer term, in a final version of this feature these would definitely go into the wallet backup.

Final thoughts

Some of the things we’ve been working on are also things that Tokenized have created versions of, but their model is not our model and it remains to be seen if we can work out some mutually acceptable common set of protocols. Some of their directions are not the same as ours, and some things have to differ, but this is a good thing and expands the range of interesting things in the Bitcoin SV ecosystem.

This release will not be intended to set a standard for others to use, it will be proof of concept of our current work, and motivation to flesh out our the hosted services protocol to the point it can be used. We currently publish this as a Python package, it is very doable for us to change that package to a variation of that protocol and require all ElectrumSV wallets to be updated if they want to use the services which use any new common set of protocols that other wallets and applications use.

If you think you are working on a wallet or application that would benefit from using our hosted services model, or wish to participate in any standardisation process — please join metanet.icu and go to the #electrumsv channel where we do most of our development discussion.

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