Let's create the ultimate Grin Wallet experience! (Grin++ UX/UI)

Development and Technical Discussion
1

Grin++ experience is good but not perfect, and I want it to be perfect. I’ve been thinking how we can improve the Grin experience in general.

First, I’m going to start with a bold statement to set the baseline: Let’s stop trying to shape Grin to be like another coin, and let’s fully embrace our uniqueness. Grin is not Bitcoin, Grin is not Ethereum, Grin is not Beam, Grin is Grin. This sounds obvious but from time to time it is good to say it as a reminder. My intent is not to start another long discussion but to brainstorm what would the perfect experience for Grin be.

I know, I know, we want to make Grin usable, we want to be able to buy a beer using Grin, at least that’s what I want, after that I’m out, I’ll close my account and no one will see me again around; meanwhile… let me offer two easy examples…

Better wording (?).

Example: Slatepack

We have a comprehensive transaction building flow: Slatepack, but what that heck does that even mean?! I can’t even pronoun Slatepack 10 times in a row without making a mistake; is Slatepack “a pack of slates”? I honestly don’t know, I was not invited to the party when the Community decided to use that word, but even “slate” does not make any sense. I’m not a native english speaker, but neither “pizarra” or “Schiefer” makes sense to describe the transaction process. In Grin, a basic transaction looks like this:

Maria provides the amount, fee and her signature. Juan joins by adding an output for the amount, adds his signature and shares this with Maria. Maria finishes the transaction (signs and broadcast it to the chain).

Reading the above I ask myself 2 questions: one, where are Alice and Bob? maybe on vacation; two, and more important, Why do we use the word “Slatepack” for this?! Some ideas could be:

  • Agreement
  • Deal

Why is this so important? Because we could say something like this then:

  1. The Sender create an agreement/deal to start the transaction and sends it to the receiver.
  2. The Receiver sends the signed agreement/deal by him/her to the sender.
  3. The Sender sign the agreement/deal signed by the Receiver.
  4. Transaction is broadcasted by Sender.

And this makes a lot more sense for everybody. My question is: what other words can we change?

Note: We also have Contracts, therefor I’m not sure if we should use “contract”.

Uniqueness

Example: SlatepackAddress aka Address (?)

People tend to associate Bitcoin addresses with something like a “bank account number”, but in Grin addresses are not the same, an address is literally that: an address, more like a Url. By definition: SlatepackAddress is a shareable bech32 encoded ed25519 public key that can be used both to route synchronous transactions and to encrypt asynchronous transactions.

We previously used Tor addresses along side HTTP and also Files, to transact, what a mess! But the truth is there is no such thing as address in Grin. Addresses in Grin are more like “listeners”. For me, having one-time addresses is really important, but also the ability of running multiple listeners at the same time, why? Because we can! I personally don’t want to reuse the same “address”, but also if you’re a miner you could use one address for each pool and one address for personal uses, and the uses case go on and on…

Next

The reality is that there is not a mass adoption of any crypto yet, not even a mass adoption of Bitcoin, why should we try to look like Bitcoin then? I’m not saying we’re better or worse, we are just two different coins. Another thing is that, because the lack of mass adoption, there is no such thing as a “standard ux/ui”, and even if there was, this is constantly changing, look what Android is today compare to what it was some years ago, for example.

I could go with a longer post, but I won’t, what I am going to do is to start sharing in this post a bunch of mockups with my ideas. This will be something long term, I want to make a Community driven effort to create the Ultimate Grin Experience and I need your help!

EDIT 1: Correction of the transaction’s steps.

26 Likes
2

Nice, in addition to the renaming of the transaction construction process, I really feel users would benefit from either numbers or color-coding of the process.

For example, give “slate” would be yellow, receive response slate blue, and then finalize green.

Or something like that that intuitively makes sense to both parties.

Or simply 1/3, 2/3, 3/3 with a gooey like both halves of a puzzle piece coming together, or a key turning a lock or something.

Also maybe there is already, but like a quick tutorial with a test transaction where it guide you on the screen?

Adding this example from the telegram, that would be cool for the visual example, “envelope” writing the letter putting the letter in and then finalize licking the envelope lol

Screenshot_20210704-161307
Screenshot_20210704-1613072048×775 130 KB

3

Maria doesn’t provide a signature at step1. What happens is much closer to this:

  1. Alice creates a transaction “aggrement/deal/contract”
  2. Bob signs
  3. Alice signs
  4. Transaction gets broadcasted

The finalize step has an unfortunate name, it’s really just a “sign + broadcast”.

I think it’s very important that users understand that there are 3 steps in transaction creation and that they are actually putting a signature on it because without this knowledge, you can’t understand what transaction cancellation means or which transactions you should cancel. I’m talking about safe-cancel that actually performs a transaction behind the scenes.

4

Damn… When I finally got used to the word “slatepack” it is about to change. Sweet…

( kidding… cheers @davidtavarez ! really well put! )

I like the initiative of going ツ to the maximum, or embracing our uniqueness. We do use a lot of complicated terminology, but it could all be simplified for the use of a common person with phrases like “sending ツ is sending encrypted text to your friend via your favourite messenger app”.

2 Likes
5

What about replacing the word “Slatepack” with “Trade” or “TradePack”
Essentially it is a trade of keys to complete the transaction… In anycase moving to something like agreement/deal etc would be more suitable then slatepack.

Is it possible in Grin++ to put a tutorial overlay on first use like some apps do, they guide you through basics of the application until you tick a box “don’t show in the future”

Multiple listeners does sound like a nice idea also

6

I imagined someday we could use “tradepack” for slatepacks that represent a multisignature escrow for trading as described in here.

7

Yes, the steps sequence was meant to be below (now labeled by 1,2,3 and 4). Thanks for the correction, stupid mistake from my side.

But what are we doing is a self-spend by sender before the transaction is broadcasted, right? I missed the purpose of that RFC draft.

Totally, and it get worse by “forcing” Grin to look like other coins.

Definitely, but what about simplifying terms and flows too? for example…

If a “Receive” action from a Receiver perspective truly means to accept (by signing) an agreement/deal sent by Sender, I think it would be better if we use “Accept” a transaction instead of “Receive”.

But now, we have an interesting scenario because when an user receives grins ツ via Tor, what is actually happening is that the receiver is automatically saying something like: “I’m accepting the transaction sent by Sender”. Maybe, the idea of manually accepting the transactions isn’t that crazy at all. It could be like cash, accepting the incoming transaction could be seen as putting the a bill into my pocket or wallet and letting you know that I certify the authenticity of the bill. To be fair, this could be confusing at the beginning, I think it is because we’re biased, we tend to think like “bitcoiners are doing this, then we should do the same”, but maybe we should not. Maybe the most natural flow is to manually accept the transaction.

Grin should be simple enough like cash but at the same time, it could be robust enough to attract advanced users.

It would be nice to travel to El Salvador and see what people are doing now. Which wallets are being used there? Are they using the LN? Are they using a commercial banking app? Will regular people care about privacy in a year of so when the mafia bosses aka the government, goes after them to collect the taxes? Could Grin be used by regular people of El Salvador in a year or so?

I don’t know, maybe I’m overthinking all these stuff :crazy_face:

8

How about the following approach. Let me call it “Colloquial Grin”.

  1. We write a very down to earth description of ツ. What ツ is and what ツ is not. How does ツ differ from other coins etc. The principal rule here is it must be written from perspective of completely non-technical person. Not for bitcoiner or other coin enthusiast, just regular person who knows nothing about crypto.
  2. We “illustrate” the concepts from (1) by defining usage scenarios, again from perspective of regular user who has zero technical knowledge.
  3. Using community fund, we could sponsor bounties for graphic designers to turn the scenarios from (2) into little comic books, just to make it more visual.
  4. In the future we could also use Community Fund to hire animators from fiverr to turn what has been done in (3) into videos. The rule here would be to make it language independent so that we could re-use this material and translate into more languages.

My motivation here is, the tech that makes ツ work is pretty complicated. Improving UX would help a lot, but at the same time I believe that no matter how nice we make the slatepack exchange experience, for someone who does not know why slatepack is necessary it would still be confusing.

1 Like
9

What is Grin (ツ)?

Grin is a privacy-preserving digital currency built openly by people distributed all over the world and launched in January 2019. Grin is community driven effort, which means that Grin is not controlled by any company, foundation or individual. Its purpose is to serve as digital cash.

Grin a light implementation of a protocol called Mimblewimble. Mimblewimble requires only about 10% as much data storage as the Bitcoin network. This makes Mimblewimble highly scalable for storing the blockchain, significantly faster and less centralized. Furthermore, the nature of the protocol allows for private transactions that are highly anonymous.

Grin is designed for the decades to come, not just for tomorrow. To be used by anyone, anywhere.

What is not Grin (ツ)?

Grin is not Bitcoin, nor Bitcoin 2.0, Grin is Grin.

How does ツ differ from other coins?

Grin requires interaction between parties involved in the process of building a transaction. Well, addresses in Grin are used for two things, one, to encrypt the transaction information and two, to determine the Tor Urls of the parties involved in a transaction; this Tor Url is used to establish a secure and anonymous communication.

Grin scales mostly with the number of users and minimally with the number of transactions. Past transactional data can be pruned, making grin drastically lightweight compared to other blockchains.

6 Likes
10

Nice! I think it would also be good to mention the advantages of ツ fair distribution for an average person, any experts on that here ready to add their few words?

I would add the following:

Grin is not another commercial project. It is built by a community for the community. It has no CEO and no investors.

11

Great initiative @davidtavarez.
I agree with many of the suggestions above. I do think we can simplify the naming of the transaction flow while still showing clearly where we are in the process and where signatures are made.
To give some examples:
We can use:

  1. Propose transaction
  2. Sign/Accept transaction
  3. Finalize/broadcast transaction.

Now here is what I think is important for users is to show in a very simple way where we are in the process, so either 1/3, 2/3, 3/3, or use a double check mark just like most messaging APPs, where the color indicates if that step is finished. E.g. you have two grey check-marks on step 1/3, 1 green check mark the first signature in step 2/3, and you have 2 green checkmarks for the second signature in step 3/3 when the transaction is broadcasted.

By having checkmarks, we will still show if someone signed, just in a language that any user can understand and relate to. We could alternatively use two grey keys that turn green upon signing, but even there I think the user would much rather see two check-marks that are 1) both grey, 2) one green for signing, and 3) Two green check-marks for a double signed and broadcasted transaction.
What I like about this is that the checkmarks perfectly correspond to the number of signatures, so it is also respecting and showing the user how many signatures are there which is unique part of Grin that we should not hide but embrace @oryhp.

1 Like
12

Send : No need to explain :stuck_out_tongue:
Accept : grin users needs to understand that when using an interactive protocol you are not just receiving you are accepting to receive, you literally give your consent (except if your wallet is online :face_with_raised_eyebrow: )
Complete : Complete seems to be a more common word to me than Finalize

what if we replace slatepack message by grin message ?
we would have grin address replacing slatepack address, and grin message replacing slatepack message

to Summarize :

a user is sending a grin message to another user
and the other user is accepting that grin message

13

Where does your 10% come from? I think that should be 25% as argued in https://forum.grin.mw/t/scalability-vs-privacy-chart

Also, no summary of Grin is complete without mentioning its purely linear 1 Grin per second forever emission.

14

My guess it depends on whether you include the witness data or not in the calculation.
When excluding it you would end up with 25%, when including it you get something like 10% if i am not mistaken. I am more inclined to say 25% since you do not need the witness data for old Bitcoin transactions that have already spend their funds. So Grin has 25% of the Bitoin transaction size for historic transactions (400 bytes for Bitcoin, 100 bytes for Grin).

15

Yes, that’s exactly what it is. If you have a transaction you have signed that may or may not ever be published, you can resolve this “unknown” state by spending the same input - which prevents play attacks.

Agree. Grin is different because of its interactivity - I’m also of the opinion that we should take advantage of that instead of making a hybrid transaction building out of it. A hybrid doesn’t bring the benefits of ITX nor does it achieve NITX so you miss on the good parts of both world.

It’s probably safe to say that most of us believe the naming could be much better. There was a long discussion on the naming of rounds here Transaction Round Naming Challenge but we have yet to reach a conclusion.

I’m glad people want to improve this part, it’s something I was hoping more people would be interested in for a long time. I believe we could move the transaction building process to a higher level, but this requires us to think about safe-cancel, one-time addresses and possibly other things as well - to prevent creating a flow that looks good today, but when you want to make it safe it hold grounds. This is also the reason why I asked Gene if he would be interested in improving the wallet experience. We need to figure out what we would consider good though and for this we need discussions like this.

16

Offer/acceptance/deal

“Sending” can be perceived as a completed action on its own, whereas “offer” implies the next step - acceptance. Just my thoughts that may be biased ))

2 Likes
17

I really like this one, If I understand @oryhp correctly, the process doesn’t have the sender signature til the 3rd “finalize” step;

so it is like drafting the contract, sending it to the second party for review, they agree, and the drafter signs and seals.

Maybe propose/review/deal

18

Yeah, the finalize step is the “sign” step for the person that started the transaction. I really liked antioch’s steps here Transaction Round Naming Challenge - #52 by antioch

// SRS flow
send <addr> <amount> -o slate1.gtx       /* outputs 0/2 blank slatepack
sign -i slate1.gtx -o slate2.gtx         /* outputs 1/2 signed
sign -i slate2.gtx -o tx.gtx             /* outputs 2/2 signed

// RSR flow
receive <addr> <amount> -o slate1.gtx    /* outputs 0/2 blank slatepack
sign -i slate1.gtx -o slate2.gtx         /* outputs 1/2 signed
sign -i slate2.gtx -o tx.gtx             /* outputs 2/2 signed

It either:

  1. creates an empty “slate” or a “deal/offer” if we prefer to call it that or
  2. signs an existing slate passed through -i (input) to produce a new slate and save it to file -o (output).

If the output is not defined, the output slate is printed to stdout. I’m not sure if the above format is good, but we likely want to have small commands that are composable and do one thing only because these make integrations simpler and add flexibility to integrations - the alternative could be unix-like behaviour with expecting the input through stdin and doing cat slate1.gtx | sign > slate2.gtx but I’m not sure how this works on other operating systems.

Note that there is no broadcast in the above flow. This is because we want to clearly separate the signing from broadcasting. The two can happen even on different devices e.g. hardware wallet signs, but doesn’t broadcast because it doesn’t have a connection to external world e.g. a node.

Since signing of the last signature is often accompanied with a broadcast, an alias command composition sign -i slate2.gtx -o tx.gtx && broadcast tx.gtx would be available.

1 Like
19

Nice, yeah maybe the simplest verbally and represented by some kind of gui, would just be an old-fashioned contract with two signature slots.

Contract, sign, sign

Thinkibg about Adobe PDF forms; both parties sign the blanks, the initiator (like leasing office or hr) then has the form to process at its leisure (broadcast).

I think that could be representated easily graphically and cognitively

1 Like
20

I’m not familiar with Adobe Forms, but this contract, sign, sign idea has been floating around for quite some time e.g. Possible interactive transaction flow which was later implemented as a testnet exchange example (though it supported only rust wallet due to the RSR deposits).

I do agree that the word contract is scary though. On the plus side, it makes people more aware that signing in Grin matters for both sides.

1 Like