Paymail, Identity and ElectrumSV

Overview

These are just notes on my current thoughts on how we would integrate both on-chain and Paymail identities into ElectrumSV. In theory it is a proof of concept for how we might fit them into ElectrumSV, but as I am not in the near future going to be working on this, the value of it is more in sounding out the approach it outlines for the purposes of reaching consensus.

Our logo, because Medium like you to bung this sort of thing in there.

Why not the current Paymail?

The existing Paymail extensions are oriented towards hosted wallets where the wallet provider is already trusted to a degree. ElectrumSV will allow users of our wallet to choose their own hosting services, or even the hosting services of parties who might look legit, but may not be secured well even if they have the best of intentions. It is very likely that we will curate the experience for regular people and only offer as visible options services we have more faith in — the minority of people who want to manually enter an alternative would do so through the wallet settings.

  • Value added services like acting as a point of contact for establishing an end-to-end connection to the identity owner, providing a mailbox for the owner should they be unavailable and in the event they are unavailable facilitating the ability to do things like unsolicited payments in a way that the owner will accept.

A case for unique naming

There are numerous proposals for systems where people buy or claim a name and then supposedly everyone adopts this system and that name can be assumed to be a way to look up and find an exact identity. I do not believe that the ability to find a contact by name and obtain their identity, has to be intermixed with the identity itself. We can have multiple ways to find a contact and obtain their identity, some from Paymail, some from trusted on-chain indexers, some indirectly from other contacts, information sources or even directly from the contact themselves.

The user experience

Our use case is outlines the various ways you might add Alice as a contact in ElectrumSV.

  • You can get the identity metadata directly from Alice.
  • You can get the identity metadata indirectly from another party or resource.

The on-boarding process

When a user on-boards a contact, they might look at it’s claims and verify them, perhaps change the name they want to see the contact as, and then formally add it. This will then cache a pinned version of the identity and it’s metadata as a contact in their wallet. I expect we want to prevent our users sending money to non-contacts, because there is no reason they should not have a record of who they paid along with what they paid.

On-boarding via Paymail

The first problem is that you, like most of us, are potentially ham-fisted. You might very well type “alice@smitt.com” and not realise it. So now you add this as “Alice”, and might proceed to assume it is Alice, and send them money. This might be someone typo-squatting, or it might just be another person legitimately named “Alice Smitt” and you have unwittingly just been careless.

On-boarding directly

There are numerous ways this might work. It might be that Alice has some physical thing that encapsulates her identity metadata and she can use that to load it into your wallet. It might be printed out as a QR code on a card, and she gives that to you to hold in front of the screen. Or she might send the QR code as an image in an email to you. Or your wallets might establish direct connection and exchange it directly.

On-boarding indirectly

You might also obtain Alice’s identity metadata indirectly. This might be from a third party who happens to be nearby and might be a friend or family member. In the same way that Alice might share her identity directly, the third party might share it indirectly with you. It might also be that you go to Alice’s website or an email you think is from Alice, and scan the QR code you find there.

External identity verification

The user is on-boarding a contact, and they ultimately have responsibility for their choices and decisions. But to not help them detect or avoid mistakes where possible, is to create a poorer user experience. So we come to the question, given that we have obtained identity metadata for a potential contact, how can we check it is who they are looking for?

From a Paymail address

In this situation you entered Alice’s Paymail address and ElectrumSV is attempting to verify it in order to provide you with the best on-boarding experience. It is expected that you have entered it correctly, and where possible we aided you in doing so.

Including a Paymail address

Verification of identity metadata that contains a Paymail address follows much the same process that obtaining it from the Paymail host directly does.

Without a Paymail address

In this case, the lack of a reputable Paymail host and a unique name for the identity, means that the verifiability of the identity metadata relies on the nature of the source and perhaps whatever the verification services claim about the corresponding on-chain identity for the given public key.

Nature of sources of identity

Direct word of mouth

If you know and trust Bob and Bob knows Carol, and Bob hands you Carol’s contact packet which includes his record of her identity, this should be a trustable contact. You will have onboarded Bob to your satisfaction and where possible ElectrumSV will have highlighted both successful verification and glaring problems along the way. So now when Bob signs Carol’s contact packet and gives it to you, you have a way to check that what you receive is what he is giving you. ElectrumSV will again engage in verification and highlight both the success or glaring problems, but generally unless there are glaring problems this should be a “green tick” process.

Anything else

If we have no direct source we trust, we can simply flag it and tell you, and leave it up to you to make the decision.

Purely on-chain identities

From our perspective, what an on-chain identity has to encapsulate is not much more than what a hosted identity has to encapsulate. It can be the same core identity metadata. The difference becomes that a purely on-chain identity is not addressable. This means you cannot simply use a globally unique name that regular people can look at and understand, to find them and reliably obtain their identity metadata. This isn’t a deal breaker. I suspect that direct acquisition of contact metadata, whether as bulk lists from your employer of coworkers, or a family member of other family members, or even someone specific, should be trustable simply through obtaining them from an already trusted party. The nature of the source of the identity metadata should be more than sufficient.

Identity metadata and contact interaction

Unsolicited payments

In an ideal world you can connect to Bob and use BIP270 directly. But this is not always possible. If Bob and you cannot directly connect, then there may be a situation where you want to pay him immediately and not wait.

Other forms of contact

We’ve outlined that identity metadata can include a reference to a service that acts as a mailbox for the contact. Or that if addressable contact information like a Paymail address is included, that the service can be resolved from that. So we can expect to have a service that acts on behalf of the contact.

Conclusion

This document has covered Paymail, locating contacts by their ownership of a unique name, and how to make private payments between contacts. It is my belief that while it could likely be improved in a lot of ways, it forms a proof of concept and both covers the ability to access a new contact by their unique name (Paymail address) but also reasons out how on-chain identity can work both with Paymail and independently.

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