Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Session 8.10.2018 #3

Open
jamaalm opened this issue Aug 10, 2018 · 7 comments
Open

Design Session 8.10.2018 #3

jamaalm opened this issue Aug 10, 2018 · 7 comments
Labels

Comments

@jamaalm
Copy link

@jamaalm jamaalm commented Aug 10, 2018

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:

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 1

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.

transaction 2

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

This comment has been minimized.

Copy link

@lehnberg lehnberg commented Aug 10, 2018

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 gavinmcdermott changed the title Design Session 10.07.2018 Design Session 8.10.2018 Aug 10, 2018
@gavinmcdermott

This comment has been minimized.

Copy link
Contributor

@gavinmcdermott gavinmcdermott commented Aug 10, 2018

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

This comment has been minimized.

Copy link
Author

@jamaalm jamaalm commented Aug 10, 2018

@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

This comment has been minimized.

Copy link
Contributor

@gavinmcdermott gavinmcdermott commented Aug 10, 2018

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

@lehnberg

This comment has been minimized.

Copy link

@lehnberg lehnberg commented Aug 13, 2018

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

This comment has been minimized.

Copy link
Contributor

@gavinmcdermott gavinmcdermott commented Aug 13, 2018

Recent relay thoughts posted from the Grinbox project

@noahyeh

This comment has been minimized.

Copy link

@noahyeh noahyeh commented Jan 22, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.