New /send and /request flows to facilitate seamless token transfer

[rachelhamlin]

User Story

As a member of the Status community team, I need an easy means of distributing SNT to new users when the product launches.

As a user of Status, I want to seamlessly exchange funds with others without sacrificing my privacy.

Description

Summary: As a result of this RFC and the discussion in #9108, we've decided to support the transfer of tokens to new users (and between users) by re-enabling chat commands.

We'll facilitate the sharing of a wallet address from within the /send and /request flows, so that wallet information is exchanged in context of a user's intention to send/receive tokens, and so as to limit the exposure of their wallets to the general public.

/request flow designs
/send flow designs

Acceptance Criteria

All users see the /send and /request options in 1:1 chat with all other users.
Update 11/11/19: We are experimenting with the GUI drawer. Users will see Send transaction and Receive transaction buttons.
The chat command icon is updated (new arrow icon to right of sticker icon).
The chat command icon will be changed to a +.
Pixel perfect design implementation.

Note: This implementation should not affect the wallet flow in any way.

Scenario 1: sending tokens

• User A selects Send transaction and decides how many tokens they want to send to User B.
• User B receives a request to share a wallet address with user A, who wants to to send them 50 SNT (for example).
• User A receives a system message notifying to say that they are awaiting wallet information from user B.
• User B selects a wallet to share with user A. Or, user B rejects the wallet request.
• If approved, user A can complete the transaction. User B receives the tokens.

Scenario 2: receiving tokens

• User A selects Receive transaction and specifies how many tokens they want from user B.
• User A chooses which wallet they would like to share with user B in order to receive the tokens.
• User A sees a system message representing their request.
• User B chooses which wallet to pay user A with and completes the transaction.

Notes

The specific user actions and mechanics of the exchange can be refined based on feedback from @yenda and @errorists.

[3esmit]

Would be nice if the /request command generates a EIP681 link.

I see that this is might not be so simple because all the implications that EIP681 brings, however the rendering of request box could be limited to ERC20 and ETH transfers.
In future a better support for any type of request box using EIP681 would be implemented.

So sending a message with this exact content: ethereum:pay-snt.thetoken.eth/transfer?address=unicorn.stateofus.eth&uint256=1e16 would render an ERC20 payment box of 0.01 snt.thetoken.eth to unicorn.stateofus.eth.
For ETH payments: ethereum:pay-unicorn.stateofus.eth?value=1e15 would render a payment box of 0.001 ETH to unicorn.stateofus.eth.

When the link is within a message, it could be opened by the wallet (just like scanning a qr code).

[yenda]

I agree with @3esmit on generating an EIP681 link, so I'll look into it for the completion of phase 1 as described in the RFC:

Enable request command flow under a flag in 1-1 chat, using a default wallet address. Does not include design.

Bob sends request command by selecting asset and amount
A request command is sent to Alice with Bob default account
Alice taps on the request, it opens her wallet, and she signs the transaction.
The sent transaction notice appears on both sides.

[rachelhamlin]

Update: Just had a call with Eric, Andrei and André to discuss option to implement GUI style commands in this go-around. Because there are several bugs that need to be fixed with the legacy commands to support their basic function, and the GUI option simply requires a new UI to change the entry point to commands—we've decided to green light the GUI option.

@andmironov will update the GUI designs to integrate the wallet share flow. No changes will be made to transaction detail or signing screens (although there are future enhancements to those screens ready).

[andmironov]

Current state of the GUI https://www.figma.com/file/XUehMnhyD1FGcWzvGz6SXqvh/Wallet?node-id=4520%3A37198

[rachelhamlin]

Thanks @andmironov!

@yenda do we have existing implementations of the amount input and network fee adjustor for the bottom sheet? Wherever possible in the I would like to reuse existing components and functionality.

We have an issue open for the network fee slider because it's not yet implemented in the regular Tx flow. If we do it here, it also needs to be updated elsewhere.

[rachelhamlin]

Update: I understand we are implementing the all-in-one modal version of the designs. No need to display Add extensions @flexsurfer.

[yenda]

Update follow up on RFC, we are implemting the GUI commands rather than fixing the text based ones as it will be faster, and preferable from a UX perspective.

• @flexsurfer is implementing the simplified all-in-one modal version of the GUI commands based off existing components
• we will remove the old commands (code was already commented out)
• https://github.com/status-im/team-core/blob/d8f08de522c10e94f1e9528a9aedb2123b72878f/rfc-001.md

[rachelhamlin]

Hey @yenda - would you mind posting a progress update here? :)

[rachelhamlin]

Hey all, can we get an ETA on this story? I'd appreciate some updates on the issue 🙏I've seen it mentioned in standups but don't see any PRs. Marketing team needs this so we can produce assets, and we are of course in the final countdown here. @yenda @andremedeiros @cammellos

[cammellos]

@rachelhamlin The status-go/protocol is implemented here status-im/status-go#1731 , everything is ready to be integrated. I believe @yenda is finishing off some other task, in the meantime I am taking over the status-react part to make sure all the endpoints developed work fine and there are no integration issue.

[rachelhamlin]

Cool. Thanks @cammellos. @yenda could you prioritize this today?

[rachelhamlin]

Oh, sorry guys, I can't read. Will you be completing all remaining work then @cammellos?

[cammellos]

@rachelhamlin Not sure, I have some other things that needs finishing, (moving installation messages to protobuf), but should not take me long, as it's fairly easy.

I'd say I keep on working on this until @yenda is finished with his stuff, after that he can take over, as this has more unknowns then moving that message to protobuf.

[rachelhamlin]

Agreed! Would love to unblock @j-zerah here. Especially as this is a 'killer feature' - we want to feature it in marketing promos.

[rachelhamlin]

I'm struggling to connect to mail servers and test this feature today so I'll just ask - can I close this @yenda @cammellos?