Allow for smooth sending and receiving of SNT while maintaining privacy

andremedeiros commented 5 years ago

Stakeholder: @rachelhamlin, @carlbennetts Engineer: @yenda

Introduction

We want to make it easy & painless to send SNT via Status so our marketing team can welcome new users with tokens during launch.

Current Status

Chat commands are currently disabled, which means that we don't have a flow for users to send or receive funds in a structured way. Additionally, users have no information about each other's wallets in v1 (as we have decoupled them from the Whisper key.) Lastly, contacts never exchange wallet information with each other.

The Problem

To facilitate the smooth distribution of SNT by our marketing team, we want to re-enable chat commands. In a multi-account world, this is not a straightforward problem to solve. We have taken privacy and security considerations to heart in the following options.

Part of the beauty of multi-account and the decoupled keys is that the user has a higher degree of privacy. We want to uphold that as much as possible while still facilitating transactions between casual acquaintances or even strangers.

Why Don't We Just ...

... Share the Address as Text in Chat?

Sharing the wallet address as text in chat is very inconvenient, for multiple reasons, chiefly being that copying and pasting text in mobile isn't exactly smooth. The in-chat request solution is equivalent, but just much more convenient, and follows a curated flow.

... Share the Address in Every Message? (like we do with ENS name)

Sending the ENS name with every messages was already a discussion that we've had and wasn't something we were 100% sure about. As a result, wallet address seems even more at odds, as it isn't directly related to chat unlike the ENS name which is meant to be displayed, and was ultimately added to each message for the sake of simplicity (checking if a user has an ENS name would have required a reverse lookup and to be done on every message, when the current solution only requires to check the validity of the claim for names you don't already know.) It is also spammy, as it adds unnecessary bandwidth and storage for little return.

Not only that, we can't guarantee that the wallet information is up to date, and if we want to allow the user to choose which address to share, it would have to be stored as a preference, which then would have to potentially be synced across multiple devices.

Ultimately, we don't allow custom usernames. Why would we allow custom wallets to be defined in each message? If someone wants to define a wallet in each message, they can use an ENS name, which already binds to a wallet.

... Use Hot Wallet Using Chat Private Key?

Creating this wallet when creating/recovering an account is a low effort. However, this is already how the wallet was generated in beta. Now, wallets are generated from a separate derivation path than the chat key. The driver for this is so that users can have the chat key on the phone and keep their wallets on a Keycard.

Also, only the chat key is loaded in memory (to decrypt messages), which means that we would go back to square one and share again the same private key for the chat and wallet account (so they'd essentially be the same.) The biggest concerns with that are security and privacy. It will require us to think hard about the UX to help the users understand and maintain their wallet hygiene (too many funds and it becomes a target, no privacy as everyone can link this wallet to their chat account, risk of revealing other private wallets when making transactions from/to the hot wallet), so the effort isn't even that low, as there are so many issues to take into consideration if we open that door again.

One strong argument for this is that it would enable SNT reactions, however, this feature could be done with a contract so that isn't a requirement.

Note that the address of the wallet account that is used to register the ENS name is revealed publicly because it is directly associated with the ENS name in the contrac t(as warned in the ens registration process.)

... Profile Settings / Wallet Sharing?

When you add a user as a contact, you share your wallet address in the contact request. The wallet account that you share with your contacts comes from your profile settings.

The issue with this scenario is that the user will have to know that they need to add someone as a contact to share their wallet address, and to be able to receive funds from another user. They will also need to know that they need to be added back by that person in order to be able to send funds.

As such, this solution doesn't simplify anything compared to the in-chat wallet sending / requesting flow, but could complement it in the future. In the interest of time, we stand to gain more by focusing on the in-chat flow first.

Additionally, the fact that someone added you as a contact isn't necessarily information that is directly communicated to the user at the moment it happens, but rather something that can be inferred because of the informations that the user shares with you (profile picture, contact updates.)

Proposals

In-Chat Request (Request / Send Wallet Command)

The user selects the wallet they want to receive the funds into when sending a fund request
Requires some system messaging for the back and forth
More secure (because the wallet and chat accounts are different, and unlike the chat's private key, the wallet keys are not in memory) and private (because the wallet address cannot be inferred, the user has to share it) than a hot wallet.
Happens in the context of a conversation.
You pick which wallet to share with each person.
Not necessary for users who have an ENS name.
Does not enable us to send to people from wallet (unless user has an ENS name)

Ease of Use: High It is clear to the user that, when he wants to send funds, he makes a request and chooses a wallet. The sender signs the transaction that opens on the request. When the user wants to receive funds, the simplicity will depend on the variant.

Privacy: Reasonable You reveal your wallet address when you make a request, and since you are sending the request in a message signed with your private key (ie. you can't deny you asked me to send to this address.) It doesn't show that it is yours, but it does prove that you asked me to send funds there.

Effort / Complexity: Medium

Scenarios

Alice wants to send funds to Bob

Alice triggers a "send funds" action, select the asset and amount and send the command to Bob.
On the wire, this is a send command, without a wallet address
At this point Alice didn't sign a transaction yet because she doesn't know Bob's address
Bob receives the send command from Alice, which displays as an invitation to share his address with Alice so that she can complete the transaction
On the wire, this is the same send command, with the wallet address
Bob then sees the command as "waiting for Alice to complete the transaction"
Alice then sees the command as an action, tapping on it, she opens her wallet and signs the transaction
Bob then sees the usual command for when one receives a transaction.

Bob requests funds from Alice

Bob sends a request command by selecting the asset, amount, and the wallet address he wants to receive into.
Alice receives the command that displays as an action. Tapping on it, it opens her wallet and she signs the transaction.
Bob then sees the usual command for when one receives a transaction.

Stage 1

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.

Stage 2

Stage 1 + allow Bob to select an account.

Stage 3

Stage 2 + Design.

Stage 4

Send command flow, remove the flag.

andremedeiros commented 5 years ago

Couple questions:

What do the in-wire messages look like?
Do we generate a request / send intent ID so we can update the UI accordingly?
How will this look in older clients?
Do we want an option to decline, and another option to decline for 24h/7d/forever?

oskarth commented 5 years ago

Thanks for the write-up! I agree with proposed stages. The send command flow needs a bit more detail but this can come later.

For the system-messages, it'd be great if this was documented and pushed as a PR to relevant spec: https://github.com/status-im/specs/blob/master/status-payloads-spec.md

I also suggest we change the title to something more descriptive of the problem at hand, as this has morphed into something that has less to do with "Proof of Ownership" than it initially had.

(Changed title to clarify intent more, can probably be made more concise, feel free to edit)

yenda commented 5 years ago

Quick update for the dev call: as I'm diving into phase 1 and thinking about @3esmit proposal of using EIP681 for requests I propose the following:

requests contain an EIP681 URI in the text field of a regular message, so that any implementation of status chat protocol can at least display a payment request
sending intent (asking for user address) could be modeled after EIP681 URI, using "request-" instead of "pay-" prefix according to EIP831, the reply being a EIP681 URI. I don't know if it can get to an EIP as it seems hardly applicable to other use cases (alternatively we could just send a template "I want to send you X Y what is your address?", but to display an interactive command, it will make the parsing complicated as there will be translations).
sent transaction could be represented as an EIP831 with the format: tx-0xHASH (alternatively we could send a link to the transaction on etherscan until a standard emerges?)

The advantage is that you only need the capacity to show regular status chat to at least be able to see these message. The request being an EIP it is also understandable by any app that implements it.

yenda commented 5 years ago

Here is what it would look like:

under the hood there is an exchange of EIP831 URIs
for users it would be presented as enriched messages inviting the user to take action or displaying additional information.

Bob uses request command:

Bob selects his wallet, the asset and amount, it sends an EIP681 URI for paiment request in a text message to Alice, that's a simple URI in the form "ethereum:pay-XXXXXXX..."
Alice taps on the request message (it is displayed in a rich form with a pay action) and it opens the transaction drawer with a transaction already filled, she just has to sign the transaction
(optional: Alice sends a transaction URI following ERC831 in the form of "ethereum:tx-0xTXHASH", but later on we could ditch that in favor of in app transactions?)

Bob uses send command:

Bob selects the wallet he wants to send from, as well as asset and amount
if Alice has an ens name,
- Bob is asked if he wants to sign and send the transaction directly to Alice known address, and wants to request to Alice which address to use
- if he decides to use Alice known address, a transaction URI message is sent (as in the case above),
- otherwise same case as if he didn't know her address
if Alice doesn't have an ens name,
- Bob sends a URI "ethereum:request-XXXXX" to Alice, modeled on EIP681
- After tapping on the message, Alice is invited to choose which wallet to request the funds on, when she chooses, a payment request URI is sent to Bob, the flow is the same as using request command from there

yenda commented 5 years ago

If we want the request and transaction URI to be a proper standard we need to propose EIPs for them. We should discuss what these URIs have to include.

For transactions:

prefix would be "ethereum:tx-"
chain-id
transaction hash

If we make an EIP for request based on EIP831 and EIP681 the idea would be that it can be used for uses cases other than the send command within Status. An example would be a QR code that you would scan and that would contain the information to claim some reward after scanning them.

prefix could be "ethereum:faucet-"
same properties as EIP681 except that the recipient is unknown, which could be difficult to achieve because sometimes the recipient is in the contract parameters (for instance for an ERC20 token transfer)
a way to contact the recipient (which is not easy outside of Status context)

3esmit commented 5 years ago

/send

/send could deliver a textual based like this: ethereum:tx-0xa3c4f14e049a9994a6a8235615e5ac42a5f9abbfe92dbf0f821e5d841c3f12ac

Initially it would link to etherscan, but as this get more features it can start rendering inside clients.

For the standard we should provide a way of giving the abi for the transaction data and for events we want them other to render: ethereum:tx-0xe57f30f18c43c77a91c5ef68e95037bb2d48e912e52a5ffff92c18ab56f6397b?calldata="transfer(address,uint256")&events="Transfer(address,address,uint256)"

Rendering transactions

Transactions should show minimal information about them, which could be expanded (or linked to external service) for users wanting to inspect more. Etherescan screenshot: https://user-images.githubusercontent.com/224810/68128196-058c4700-fef6-11e9-8e44-c6299696a985.png

ERC20

Note that:

it should only render a box displaying ERC20 transfer (with token symbol, decimals, all beautiful) if the token address is an actual known token by user, otherwise it should only display a general box displaying the transaction details - this is crucial to avoid bad use of feature.
This detection should happen using event logs, so it supports any transaction. Using the transaction data is not reliable because of smart contracts, as account contracts and multisigs.

Fields known ERC20 should show:

Token Contract Address: Optional to display but bad if totally hidden. Loaded from event logs.
Token Symbol: loaded from ERC20 interface.
Token Name: loaded from ERC20 interface
Sender: loaded from event logs
Receiver: loaded from event logs
Amount: loaded from event logs

andremedeiros commented 5 years ago

@yenda @3esmit can we augment the original RFC comment with the added implementation details?

yenda commented 5 years ago

@andremedeiros yes shouldn't we make a PR rather than an issue to facilitate feeback integration?

@3esmit transaction URIs should include the chain-id otherwise you don't know which chain they are on, and also it will make it easier to warn the user when they are not on the same chain.

Regarding the calldata can't we always get it using the transaction and transaction receipt (or even etherescan api for simplicity)?

3esmit commented 5 years ago

@yenda agree with chainId.

I think is important to contain also the fields I mentioned, which is calldata and events. calldata does not contain the calldata itself, but the necessary data to decode the calldata (and events). Perhaps I named it bad and we can have it named method.

ethereum:tx-0xe57f30f18c43c77a91c5ef68e95037bb2d48e912e52a5ffff92c18ab56f6397b?chainId=1&method="transfer(address,uint256)"&events="Transfer(address,address,uint256)"

3esmit commented 5 years ago

Therefore with all this data, which is transactionHash, chainId, method signature and events signatures, you can decode everything related to the transaction.

Note that you should be able to describe multiple event signatures in the events field, as some events trigger multiple events. But a transaction can only call directly one method.

3esmit commented 5 years ago

The spec of /send output text is being written here https://notes.status.im/Mc8cH-HdS8qCIVd7fqetaA#

3esmit commented 4 years ago

EIP submitted as Draft. https://github.com/ethereum/EIPs/pull/2400

status-im / team-core