Identity System UI exploration
#proof-of-words — design exploration of work required to support RyanPay which is coming out at CoinGeek Toronto.
The goal of this document is explore the current contact system, and with a picture of how that works in mind, try and flesh out the changes that need to be made to hopefully do a quality job of the task — to replace the existing contact system with one based on contacts with one or more identities.
This task has resulted in many other priorities being set aside. There’s a deadline ⏰ — which is the end of May. At CoinGeek Toronto then, Ryan X. Charles is launching his identity system. We’ll call it RyanPay in this document, for the lack of any other available name.
Feel free to comment below if you have any thoughts on the article, or perhaps if ideas and suggestions come to mind while reading it.
The existing contact system
It’s not shown by default, but ElectrumSV has a simple contact system. You can toggle the display of the “Contacts” tab by selecting a menu option.
Selecting the “Show Contacts” adds a new tab to your user interface.
When you make the “Contacts” tab the active tab, you can access a context menu, giving you options for adding new contacts.
Then you can assign a name to an address.
And it will be added to the list contained in the “Contacts” tab. Accessing the context menu on Alice’s address gives you a few handy options. In our case, we’re going to pay Alice and select “Pay to”.
This switches to the “Send” tab, and populates it with the right combination of text to represent Alice and her reusable address, so that the payment process can resolve it to that address when building the sent payment transaction.
This is actually a unpassworded wallet for testing the Digital Bitbox hardware wallet, so I’ll have to switch over to a wallet with an available balance as I move onto showing the existing payment process.
The existing payment process
To begin with, I have created two contacts, Alice and Bob. I’ll be making a joint payment to both of them.
I’m pretty sure that the following mumbo-jumbo means that Bob and Alice are being paid, via their contact address, 0 satoshis each. If you set a value for each but don’t select specific coins to spend, it’ll use the default coin chooser you normally use.
Let’s see what we have in the Coins tab, and spend one in this payment.
Now we can see more mumbo-jumbo, including the specific coin or UTXO we are spending.
Here we set an amount for both Bob and Alice, which is less than the coin we are spending from.
If we preview the transaction, we can see in the “Outputs” area that Bob (green) and Alice (green) get their pittance and the rest goes to a change address (yellow).
If we change Alice’s amount to a “!”, this specifies that she should get what is left over from the other payments (which is the one to Bob).
Let’s take a look and verify this by clicking the “Preview” button. What it shows is that after Bob gets his pittance, and the fee is accounted for, the rest goes to Alice. There is now no change, which was previously highlighted in yellow, and would be still if present.
There are some nuances to this, like you can autocomplete based on your contact’s name, in the “Pay to” text area. Here I’ve added a third contact, named Claire, and started typing her name. This allows easy addition of a payee contact, to a payment transaction.
And that’s pretty much all I know about ElectrumSV’s payment process, where contacts are involved. There’s very likely more arcane things, or variations you can do. Maybe my fellow developer Kyuupichan, who has been using Electrum for much longer than I, will point some out to me.
I have so many ideas for how to make this less of a UI for programmers by programmers. So many..
Replacing the contact system
We are no longer going to support contacts that are a specific address. Address reuse is going to be discouraged. In the longer term, we want to provide the best wallet experience we can, and doing so will mean that we won’t have to check all of the addresses that a user has ever used, until the end of time. Instead we’ll just check the addresses we have related to pending incoming payments, outgoing payments, and other variations on these two cases.
The work to refactoring the contact system to be based around supporting multiple identity systems has already been completed. The UI has already been altered to work with the new contact system, but because no identity systems are hooked up, no payment involving contacts will work until the system they rely on is. This is however irrelevant, we can do both the contacts and payments user interfaces for pretty much all uses of contacts, without needing to actually pay one.
Contacts are going to be named, and identities will be able to be attached to them. The current prototype code just maps one identity to a contact, but that’s just the UI, not a limitation of the system. Here I have copied a public key from one of my addresses, and using the “OnChain” system where identity is defined by public key, I am creating a new contact. Note that it this will not be the way public keys are imported, that will be done through some system where the user never sees the public key — remember our goal is to do away with the programmer UI.
Now we can see Bob in the contacts list. It’s also still a variation on the original programmer UI.
Here I whip out my degree in programmer art, self-awarded, of course. This is the contact card view, and it primarily displays the avatar (or a placeholder), the name of the contact, and other stuff. What other stuff will come out in the wash, but I’ll start with what identity systems we know them under and the guessed to be useful age and when they were last active. There are lots of variations we could do on this. I’m already thinking of some, are you? Add them in the comments below or discuss on one of the Slacks.. 👍
Click on Alice’s avatar and you get the UI to change it, right in the part where you actually change it. Click on Alice’s name and you get the UI to change it, right in the part where you actually change it. Click on an identity system and you get the UI to change it. One thing we’ve lost in the switch from a table to a list of contact cards is sorting, but we can add some UI to toggle that somewhere, and even the ability to easily search and filter the entries.
The adding and editing of identities has some nuances. If you add and edit them yourself, you are taking the risk they belong to separate people and you’ve made a bad decision. So if we’re going to allow this, we’d want to internally track payment metadata that could be used to split a contact, if it did turn out they were unrelated. It might be that we’d want to indicate contacts who were provably correct linked identities, and those who were not, as a warning to the wallet owner. Let’s say that Alice had two identities added manually by Wallace, the wallet owner, and her card had some element of danger highlighted — perhaps an alert icon, perhaps a reddish background colour or border.
A correct contact might be one where they have signed the bundle of identities, where every bundled identity can be mapped to the signatures of the whole bundle and verified. At this point it is provably the contact’s problem if this is not representative.
We’ll worry about the adding and editing UI some other time, let’s move onto the payment UI.
Replacing the UI for the payment process
Let’s illustrate the problem again. Roughly speaking, it looks like this..
I’d change everything, even the buttons. But I’m not going to change any of it, I’m going to leave it exactly where it is, working the way it is.. but not working with contacts.
What I will do, in the interests of not losing sight of the woods for the trees, is to add a new tab — which we’ll call “Payments” at least for now. This will bring together a lot of the concepts I’ve been working on in the development branch for the last month or so, even if they are only shown in a cosmetic fashion for the time being, because RyanPay is being added in the stable branch.
So let’s mock it up.. it’s going to present to the user the state of their unprocessed payments, both not yet processed and not yet broadcast. This will benefit the long term development branch, but be “Coming soon..” in the stable branch.
All the panels of the different kinds of transactions need further thought and will only be there to begin with to pad out the tab. Even the drafts tab won’t be used in the stable branch, and has will be added in the long term development branch. So what happens when you click “New Payment”?
It will open a popup window. For the stable branch, we’d likely prevent more than one from being opened, but the long term development branch we’ll take it further. We want to be looking at the woods and not the trees, so we need to draw lines in the sand all around us.
Let’s be very clear. This is a simple payment dialog. It might allow a subset of the functionality in the “Send” tab, but it won’t allow coin selection or multiple payees. The user should be able to tab through it and quickly fill it out.
The user would enter the name of a contact and use autocomplete to select them. This would perhaps display a styled contact badge with the contacts name, which when the user clicks on them, popup their contact card or is interactive to adjust the contact identity, which in turn would update the badge when it was closed.
There’s probably a better way of doing the batch, which indicates the identity system visually, than colour. Let’s try again..
That’s a bit too prominent, but it’s an improvement. With some switching around of colours, and a bit of tweaking, I think we can do the job. But getting it perfect isn’t to be done here.
The only initial option would be “All available funds”. But in the longer term it is envisioned that users may be able to select from accounts, which are isolated coins — either in the same BIP32/44 pool — or from other keys.
Experimentation would need to be done to work out how to best integrate fiat and BSV amounts in this pane. A simple approach would be to put the missing value in grey after the currency dropdown — so if the user selected UKP, it would show the BSV value after the dropdown. And if the user selected BSV, it would show the UKP value after the dropdown.
Your payment note would be the “Description” that is currently associated with a transaction in the history.
Their payment note would be initially disabled, but may optionally encrypt a message to them, to be attached as an op-return in some future update using some standard format.
In the longer term, we might consider adding a tags section where the user can tag the transaction with keywords, and use it for searching their records.
This would show a summary of the resulting payment, and transaction, and ask the user to confirm the payment.
This is loosely envisioned to be both a summary of the transaction, as well as the current state of the transaction.
When we have dispatched, settled, cleared, received and so on as transaction states, what is displayed would vary.
This took me ages to write up and mock up the screenshots, redoing them, and tweaking them. But I think it was very helpful to set the scope for the task, and to consider it in the context of the longer term road map.
This task goes against the ideal approach by requiring feature work to be done in the stable branch, because the changes in the development branch will not be ready by Coingeek Toronto, for the RyanPay launch. I think for the most part that’s okay, as these changes can be provably isolated and constrained.
In summary this is what needs to be done:
- Change the contact list to show contact cards. Look into filtering and sorting functionality, given that the table view will be gone.
- Leave the “Send” tab as is, with no contact integration. It will be phased out in the development branch, as we work out how to do that and what parts of it to feature and hide.
- Make a new “Payments” tab.
- Add a “Make a payment” toolbar button.
- Make a simple “Make a payment” popup dialog, and create a contact badge to feature there.
- Fill the gaps with some “coming soon” and disabled bits and pieces, ready to be hooked up and linked in when the code is merged into the development branch. Stable branch users are going to have to either ignore them or find them tantalizing.
- Add a “Profile” tab. It should be enabled by default. At a minimum it should allow an ElectrumSV user to register as a RyanPay identity, however that needs to be done. It was outside the scope of this document, so isn’t addressed above.
- Oh, and of course, prepare to hook up RyanPay ASAP.
Well, if you made it this far congratulations. These documents are primarily for me to plan things, and communicate them to my fellow developer, but I share them in the hope someone will join in and help me do it better. I hope you add some comments about how you think this could be made better, or good examples of things I have touched on in other software you use.