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

[davidtavarez]

@gene

Ultimately, bikeshedding over terminology is not the most productive thing to do, in my opinion. I think as long as terms are used consistently, and there is an accessible/known place that defines the terms, people will catch on.

Grin Community is diverse and multi cultural, words are meaningful and important, I’m supposed to read something and instantly understand what it means. After hours and hours offering support to the average joe in the Grin++ Telegram support channel, I realized that people are not getting how Grin works. We’ve been trying to simplify things, and probably it is not that bad these days, but still people are not getting it. Picking the right words seems to be trivial but it is not.

@gene

For example, the discussion over changing “slatepack” to something else. While some people might not understand what it means, someone with the context that the name derives from Keybase’s “saltpack” would likely have an easier time.

I’m sorry if that was the idea that you got from reading this thread; let me be clear: this is not about replacing the term slatepack for something else. The RFC 0015 defines what Slatepack is: Slatepack is a universal transaction standard for Grin. I’m just trying to find a better way to explain this to average joe. The majority of the Community hangouts in Telegram, so the reality is: most people are not familiar with Keybase, we should not assume that people are familiar with Keybase in order to understand Grin.

@gene

Technical jargon can make things harder to understand for people unfamiliar with the terms, and simpler for people that are familiar. Also, if you change fundamental technical terms, there is either going to be a lot of churn in the code to update words, or a mismatch between explanatory terms and the code.

It is important to remember that this is not about changing fundamental technical terms; now, my question is: are we afraid/against of changing the code in order to make things easier for the users? if the answer is: yes, you know what? Grin is dead, let’s turn off the lights because the show is over; but… I don’t think the answer is yes, I think the answer is: no, we are not against of making things easier for the users.

@gene

After working on wallet code and transaction building, I don’t think it’s worth it to try to make Grin transactions non-interactive (in the traditional sense). It would require fundamental changes to the cryptography used in Grin, and likely isn’t even possible to be fully non-interactive like other coins. Two-round transactions might be possible, but would likely require a significant amount of work (probably not worth it).

Great, that’s interesting, so it is not that crazy to say that interactivity is a feature, not a bug; and I want to take a step further, if the interactivity is a feature, let’s embrace the interactivity then, and with this I mean:

• Let’s take advantage of it by adding manual_confirmation and reusable addresses, for example.
• Let’s educate our users by letting them know what is really happening during the transaction building process.
• Let’s make it clear what exchanging the Slatepack Messages means, and why.

After learning what and why, Grin users will find ways to exchanges Slatepack messages in ways that we haven’t heard of yet. We won’t need to add anything else, they will realize that they can use any means they want to perform the exchange. We just need to build a scalable, solid, clean and robust Mimblewimble implementation, and if Mimblewimble is meant the be successful it will be, our duty today is to fully embrace Mimblewimble capabilities, and take the best advantage of them.

I wanted to set a common ground on what Grin is, this also could be seen as something trivial and/or silly but it is neither. If we agree with the next statement that says: Grin is to be used by anyone, anywhere, we should always have that in mind. One of the reason why Ubuntu was so successful is because they wanted to bring Linux to the hands of average joe. I’m personally fine using Gentoo or Arch Linux, but regular joe will go with Ubuntu immediately, I can ask regular joe to read the documentation and watch videos in YouTube but he won’t do it, but even if he does he will go with Ubuntu because neither Gentoo or Arch Linux are meant to be used by regular joe, Ubuntu is. If we believe that Grin is for anyone, anywhere, we should do more than just write a ton of documentation. Ubuntu did not rewrite Linux, they just took Debian and improved the experience, and we can do the same, we can improve the Grin experience

I’m inviting the Community to improve Grin experience.

[oryhp]

I’d go as far as calling the current auto-receive “auto-sign receiving transactions” feature and I know it’s convenient, but I’d leave it as something a user needs to explicitly toggle, so that the first transaction they make, they learn that the transactions are signed by both parties. The purpose of this is to know that the flows are no different behind the scenes. The current auto-sign when being the first transaction user makes, hides the signing process of the receiver which could suggest that the auto-sign and manual_confirmation are different transaction types - I’m afraid nontechnical users will call the former noninteractive transaction and the former interactive. The two are not different at all, the question is just if the receiver reviews the transaction contract before signing it. There are plenty of ways to educate people about this flow.
But don’t worry, I don’t plan on pushing making the manual_confirm the default flow. I just want to make sure everyone understands that the understanding of transactions might depend a bit on which flow is the default. The fact that we’re moving in this direction brings a smile on my face as it is.

[oryhp]

I’d like to point another advantage of manual confirmation. Manual confirmation makes the transport process asynchronous, which allows the receiver not only to check the contract and sign it, but to also manually pick the inputs if they want to make a payjoin transaction. We currently don’t support payjoins, but we definitely will in the future. Having a choice to pick the inputs sounds like a good idea even in the SRS flow.

[david]

@oryhp

Having a choice to pick the inputs sounds like a good idea even in the SRS flow.

You can already pick the inputs in the SRS flow with Grin++'s coin control feature.

[oryhp]

I’m assuming you’re talking about the sender doing that while I’m referring to the receiver doing so at step2 in the SRS flow.

[davidtavarez]

Well… meanwhile I would like to see if we could came with a good RFC to add the Manual Acceptance of incoming transactions feature.

Here’s the link of the PR: Manual confirmation of an incoming transaction by davidtavarez · Pull Request #84 · mimblewimble/grin-rfcs · GitHub

I appreciate the feedback. I think it would be easier to follow the conversation about the proposed RFC on Github.

Thanks!

[paulchinky50]

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”

[davidtavarez]

@paulchinky50

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”

Yes.

@davidtavarez

I appreciate the feedback. I think it would be easier to follow the conversation about the proposed RFC on Github.

While automatically adding the recipient’s signature data is convenient, it takes away users’ freedom to have full control over their own wallets. The ability of refusing incoming transactions is only possible when transactions are interactive, like in Mimblewimble.

Manual acceptance incoming transactions also adds:

• Protection of an Output Injection (or Dust attack) in users’ wallet.
• Consistency between Sender-Receiver-Sender (SRS) flow and the Receiver-Sender-Receiver (RSR) one.
• The ability of both parties involved in the transaction to confirm the amount of the transaction.

Manual confirmation helps users understand the interactivity of Grin and are a unique feature that is only possible in protocols with interactive transaction. We also gain the ability for both the sender and the receiver to commit to an arbitrary statement/document with our transaction. This is because they both can read what they’re commiting to before they confirm (sign) the transaction.

A potential flow could look like it is describe above: Let's create the ultimate Grin Wallet experience! (Grin++ UX/UI) - #34 by davidtavarez

If someone wants to read the complete RFC can go here: https://github.com/davidtavarez/grin-rfcs/blob/manual-confirmation/text/0000-manual-confirmation.md

[Spinflight]

I would have thought the best way of making Grin easily useable and and understandable is by mimicking current behaviour. I agree on the slatepack naming thing though, I didn’t get it.

So I’d think the most important function here for a wallet was NFC. Just as people tap their phones or cards on readers currently, whether Visa or Apple pay etc. Is there any technical reason why rin wallets couldn’t also use Near Field Communication?

I suspect Apple and Google would be a bit sniffy about it, direct competitor, though Linux phones are maturing and deAndroid ones are a thing now. That’s if they even noticed that the apps accessed NFC…

So I guess the flow would ideally be… Vendor enters a price and confirms, likely showing this to the buyer. Buyer taps his phone on Vendor’s phone, which recognises that it is a Grin transaction so opens his wallet, shows the price, and asks for confirmation or alternatively merely signs the transaction on the intial tap. Vendor then broadcasts the transaction.

The selling point for this is not just anonymity. It’s cheaper ( 2-3% compared to Visa ) and just as convenient as a bank card. Saying that I’d expect you could add 20% VAT as a saving in many cases…

Is this possible?

[oryhp]

@Spinflight

or alternatively merely signs the transaction on the intial tap

You’re describing RSR (invoice) flow which can’t be automated at step2 today. If the sender merely signs, then the receiver can just input more than they said in real life and they trick the sender into sending them more. The amount must be checked by the sender in this case.

I don’t know much about NFC and its spec, but it seems possible. The only issue I see is that you’d need people near you to use Grin. It’s unlikely a vendor close to you will accept Grin in the next years so probably focusing on protocols that allow distant communication e.g. Tor, would make more sense today. But NFC is probably possible and is similar to the QR code exchange from the user perspective.

[satoshocrat]

“If the sender merely signs, then the receiver can just input more than they said in real life and they trick the sender into sending them more.”

What if the sender signs from a wallet that only has that balance in it? If the receiver changed it to hire it wouldn’t go through, and there would be no incentive to change it lower?

[vegycslol]

@Spinflight

Is there any technical reason why rin wallets couldn’t also use Near Field Communication?

I don’t think there is any. NFC is just one of the ways to transfer data afaik

@Spinflight

Buyer taps his phone on Vendor’s phone, which recognises that it is a Grin transaction so opens his wallet, shows the price, and asks for confirmation or alternatively merely signs the transaction on the intial tap. Vendor then broadcasts the transaction.

That’s RSR flow where the vendor creates an invoice, sends it to buyer (one of the ways is through nfc), he sees the content, clicks pay and sends it to vendor to finalize. That’s imo the best flow for buying stuff from vendors

[oryhp]

This would mean that you’d need to know the amounts of future transactions to prepare the outputs of child wallets in this way, but you can’t know what txs you’ll be doing. If you decided to prepare the outputs later, it would require a new transaction on the chain to create an output in a wallet that only has that specific balance.

[Spinflight]

@oryhp

It’s unlikely a vendor close to you will accept Grin in the next years so probably focusing on protocols that allow distant communication e.g. Tor, would make more sense today. But NFC is probably possible and is similar to the QR code exchange from the user perspective.

I’d think build it and they will come… There’s myriad uses for NFC based transactions, functions just as people are used to using their cards currently, literally digital cash. It then simply becomes a case of persuading the hubs to accept and people will see the value.

As a use case think sex shops. There aren’t that many of them but people who buy whatevers from them would rather it was private. Yes they can order such things through the internet cheaper but then your postman and bank knows about it. If setting up to receive Grin payments was merely downloading the Grin++ app… The value proposition is saving fees on every transaction and being entirely anonymous. Only cost would be maybe having a Grin sign on the counter.

So… Get down to your local sex shop, pick up a 14" double whammy purple butt plug and ask the owner whether they accept Grin. For the… erm… good of the project.

On a more serious point NFC transactions takes the geekiness and useability / education problems away almost entirely. Lots of other use cases, ticket touts ( called scalpers in the Colonies?), massage parlours etc. And eventually paying for a coffee.

[satoshocrat]

Oh right, makes sense; I was just trying to conceptualize a clunky “in theory” method where the receiver (merchant) would have no means or incentive to “cheat” the sender.

If the balance were adjusted at purchase, could it be done as two transactions essentially?

-Wallet balance is 20 grin,
-Invoice/purchase price is 8 grin,
-Wallet sends 12 grin remainder back to sender’s wallet as tx 1
-Signs invoice for 8 grin proposed by R w/o fear of cheating

Do I have this right?

[vegycslol]

@satoshocrat

If the balance were adjusted at purchase, could it be done as two transactions essentially?

That requires a manual interaction from the sender and this interaction is worse than manual confirmation of the transaction. Sender will always need to do an action per each transaction, either by some magic in advance or by manually confirming the transaction

[satoshocrat]

Yea, I just see the balance adjustment (1st tx) as being rather automatic by the wallet when hypothetically doing it this way. If it’s sending back money to the user’s own wallet, then why would it need to be manually confirmed? It would just create and resiolve the pair? thus the user would only be troubled with the friction of manual confirmation anyway?

[vegycslol]

@satoshocrat

Yea, I just see the balance adjustment (1st tx) as being rather automatic by the wallet when hypothetically doing it this way.

The sending from one wallet to another can be automatic but the sender would still need to tell the wallet how much to send to another wallet. So he either needs to input the amount before the transaction starts (this costs fees for another transaction and makes it impossible to make another transaction from this wallet since it only holds funds for this transaction) or manually confirm the amount on step 2 of RSR

[satoshocrat]

Ah yeah, That’s what I meant also by the wallet would do it automatically. It’s simple subtraction. What I’m thinking is, when the invoice is rendered, the amount is known at that time. Wallet or user sees it’s an RSR flow, and initiates a subtraction of the balance as one transaction (automatically) before and in conjunction with signing the transaction from the receiver.

Anyway, it seems if the mechanics were smoothed in whatever way, in theory, it would protect the sender from exploitation of overcharge by the receiver.

[Neo]

As @oryhp mentioned we need people willing to spend Grin in real life first.

@Spinflight

I would have thought the best way of making Grin easily useable and and understandable is by mimicking current behaviour.

Alipay/ WeChat pay could also be something to mimick.

@Spinflight

I’d think build it and they will come

I like this attitude. It’s just currently we don’t even have a nice UX flow for web-based transactions, let alone tx in a real-world point of sale environment(POS). So, we probably need to focus on becoming internet money first.

@Spinflight

On a more serious point NFC transactions takes the geekiness and useability / education problems away almost entirely. Lots of other use cases, ticket touts ( called scalpers in the Colonies?), massage parlours etc. And eventually paying for a coffee.

Flea Markets where vendors only typically accept cash could be a good use case. Keep in mind others have tried to tackle the POS market, most notably https://pundix.com/, they built their own POS terminals but I believe you can also integrate into late model Verifone terminals. Verifone allows you to build your own payment apps.