Following the publication of our roadmap, we’ve been inspired to prioritise the development of messaging (encrypted discussions) to ElectrumSV (ESV).

This document is intended to explore some of the thoughts that have come up, while doing some other exploratory design of our messaging UI. Some of these things, particularly those related to general discussion presentation, will even be solved problems in normal chat applications which you might want to point out.

#disclaimer — I do not know everything or what is best, this is proof of words.

What identity systems will ESV support?

We will also be open to supporting multiple identity systems, but what we want to avoid is technical debt or adding every protocol someone came up with, and having to carry them onward and maintain backwards compatibility. It is very possible that we will come up with our own system that meets the needs we find we have, as we build this feature.

What is an identity?

What exactly is that identity they give you?

At the very least it is going to have to include an identifier for the identity system it uses, and the identifying reference for that user within that system. We can probably also include a requested display name. We might consider this the core identity protocol.

Make it JSON and it’s easy to wrap and overlay extension data, and easy to read and parse. Much like BIP270.

What if we do not support an identity system?

But what if their identity system is not supported by ESV? What do we do then? Do we still allow them to join and just display them in a way that indicates the problem, like “Unknown#1”, “Unknown#2” …? I’m not sure it’s possible for a discussion to enforce that only some identity systems are allowed.

Sure we can’t verify their identity, should they join a discussion. And we can’t add them as a contact that can be verified, whether using a blockchain indexing service and lookup of signed CRUD records, or however any of the identity systems we do support work.

One option might be to extend the core identity protocol with a lowest common denominator fallback public key. Then all the other details besides the requested display name, can be ignored.

Avoiding contact confusion?

So we should differentiate between the contacts you have named, and the contacts who provided a name that they request you use. The simplest two aspects we will differentiate between, to begin with, are:

  • Between known and unknown contacts. The known you will have altered in some way that indicates you accept them as their name. This might be changing your mother’s contact name from her full name “Hyacinth Bucket”, to be something else, like “Mumsy.” Or it might be that we add a tag system, and you tag your mother “Hyacinth Bucket” with “Family.”
  • Between duplicate display names. You are in a discussion with “Bob” and “Bob” and “Alice” and “Alice”? Nope, you’re probably in a discussion with “Bob#1” and “Bob#2” and “Alice#1” and “Alice#2”, who get an altered display name from their requested one for the sake of sanity. Or maybe we just alter the colour of each participant’s name so that there is no close colour and naming combination.

For the most part, this is ESV user-interface polish. It isn’t that important, just that we remember to keep it in mind and make the best decision regarding the long term maintenance cost and usability of whatever we do.

There might be a larger concern about a standard approach to display in these cases.

Contacting someone for the first time?

An extension to the core identity protocol might be one which defines a first contact protocol. This might say that first contacts will be ignored unless they accompany a payment of an attention fee of a certain amount. It might say that you need to get a mutual contact to sign and vouch for you.

We’re more than likely going to build in the attention fee.

Signing and vouching?

Should other discussion participants be able to send vouches to the some or all of the participants, perhaps as a public statement or even as a private action? Should ESV collect these and build a web of trust?

Should it be possible to do a qualified act of vouching — in that you say this is someone I know, but I take no responsibility for them and do not consider this communication to carry weight?

ElectrumSV developer