Design Session 8.10.2018

[jamaalm]

TLDR: The goal of this post is to get feedback on our first user-flow models on synchronous and asynchronous transactions. This will help move our wallet design forward. We’re specifically looking for feedback on:

• UX assumptions (cc @lehnberg @mslipper @sdtsui)
• Evolving design principles (cc @lehnberg @sdtsui)
• Transaction assumptions (cc @quentinlesceller, @mslipper, @ravidio)
• Open questions (cc @mslipper @sdtsui @bladedoyle @yeastplume)

Thanks everyone for your help and engagement. We’re excited to move the project forward.

Schedule Note: We'll get into a regular posting rhythm within the next week or so.

---

@gavinmcdermott and I have been working on a user interaction model for the Grin wallet. We’re focused on designing a desktop wallet for the “next 10%” of users. These people may have a light technical understanding but are not necessarily developers, and they’re people that may have completed a cryptocurrency transaction in the past.

Early Design Principles

1. Abstract away complexity. Grin transactions are actually quite complex compared to Bitcoin transactions, but most users don’t need to be exposed to the details.
2. Design for the next 10% of users. Enable others that may not be as technically competent to transact in easy, seamless ways that are still trust-less.

Practical Assumptions (that impact UX)

1. Most transactions will happen asynchronously. (Implications: this will require an external transaction relayer service)
2. Accepting inbound transactions should happen automatically.

The user-flow diagrams (below) surface the minimum required user inputted information and actions to complete a transaction. There’s a lot of assumptions we’ve made here and many questions we have. We'd appreciate your feedback and questions.

Transaction 1: Synchronous transactions. Both sender and receivers wallets are online.

Transaction 2: Asynchronous transactions.

We believe most transactions will happen this way because sender and receiver may not be online at the same time, or users don’t have access to static IP addresses, and firewalls or secure networks getting in the way, etc. All that is to say, asynchronous transactions require a relayer between the sender and receiver.

Questions

1. Are there any other types of transactions that we should consider in the design?
2. For the two transactions we’ve illustrated, are some of our assumptions correct? Are we any data at any step that a user would be required to input?
3. Are our assumptions correct? Where are there gaps in our understanding?
4. The fact that there are relayers required for asynchronous transactions, makes us think now is the time to settle on a standard for relayers? Should we set a standard for something like a Grin Relay Interface (GRI)?
   • How can we engage in setting this standard?
   • There are important user-centered questions for the GRI, such as:
     • When a user opens their wallets, can it poll relayer for any partially completed transaction sent from that wallet that are still in a pending state?
     • Can a user cancel a pending transaction that’s sitting at the relayer?
     • Can (and should) a wallet interface with many relayers?

[lehnberg]

Nice, thanks a lot for sharing this!

For the two transactions we’ve illustrated, are some of our assumptions correct? Are we any data at any step that a user would be required to input?

• Nitpicking now, but you would probably want the wallet to validate Sender has enough grin to send as a first step before doing anything else, as this is the most severe error. You wouldn't want the user to get thrown a bunch of network connectivity or pub key errors etc only to address them and then realise they don't have enough funds to spend regardless.
• In synchronous mode, you are also making the assumption that Bob remains passive throughout the transaction process. This is in a way desirable, I think, as it would be quite a nice experience for Bob. On the other hand, there is an active effort that Bob's wallet needs to be doing in order to participate in the transaction building process, and Bob's wallet is signing stuff on Bob's behalf. So there's a rationale for why Bob may want to be able to confirm this. Or at least be made aware that it is happening. Perhaps this is something that can be handled via default settings etc (auto-accept any incoming transaction). Don't really know. Just raising this as a point to think about.
• On a similar note, in asynchronous mode, you would want Bob's wallet to be notified about a pending transaction, in order to draw Bob into opening the wallet, completing his part of the tx building process and passing it back to the Sender via the relay service for completion.

[gavinmcdermott]

Relevant note: Today there is also a bit of talk in the Gitter /dev channel about how to handle exposing auth vs non-auth APIs.

[jamaalm]

@lehnberg thanks for the response. On your first point, you're absolutely right. These diagrams are just to confirm the minimum information and action required on the part of a user for a transaction. The flow for these diagrams is likely not optimal.

On the second point, I think it's a great idea to visualize the transaction as it's composed.

Lastly, on the third point, I'm also in agreement with you here. It'd be ideal to have a notification for inbound transactions.

[gavinmcdermott]

@jamaalm @lehnberg - Agreed on the principle: I always want to know before I sign anything.

[lehnberg]

FYI a working (albeit manual) transaction relay service is now up and running:
https://github.com/vault713/grinbox

There's been some early discussions around phases and functionality.

Protocol feedback is welcomed on the repo or in the gitter channel.

[gavinmcdermott]

Recent relay thoughts posted from the Grinbox project

[noahyeh]

Hi guys what is the status on this? We like the simplicity and may want to get involved in development if it hasn't been done