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?
There are none currently available publicly, that we are comfortable adopting. We will be adopting the wallet workshop identity system, which is professionally designed, documented and will likely come with a reference implementation.
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?
So you support multiple identity systems, you have a contact system which processes someone’s identity and on-boards them as a contact, and presents them to the user in a consistent and flexible way.
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?
Someone gets added to a discussion you are part of. As part of the discussion protocol, their identity is required to be included. This means that ESV is going to get it, process it and display them in a useful way as a participant in the discussion.
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?
As you interact with other people and acquire their identities, you are going to accrue contacts. But there’s a difference between your mother and someone who requests to use the name “you mother”. If you get a payment request from one of these it matters which one.
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?
So you obtained someone’s contact information and you want to engage in a one-to-one discussion with them. Maybe they accept unsolicited messages, maybe not.
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?
So you enter a discussion with someone you already know. Then they add someone they know. Are they required to vouch for them by signing their identification? If they do vouch for them, what are they 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?