Status-react: MVP 1 Tribute to Talk

[yenda]

Notes

https://github.com/status-im/swarms/blob/master/ideas/314-tribute-to-talk.md

Design

https://www.figma.com/file/aS1ct66VQ6V0cio7vSqS8UoG/Chat?node-id=1319%3A13403

[yenda]

@goranjovic do we already have a mean to watch for events emitted by a contract? The TTT contracts emits AudienceGranted(address from, address to) event when someone uses the payTribute(address _to) function.

[yenda]

@rachelhamlin should we explain somewhere in the UX the consequences of using TTT? It's leaving an on chain proof of A reaching out to B.

[rachelhamlin]

@yenda is it not something we could conceal? What unique identifier would be stored on chain, Whisper ID?

[yenda]

@rachelhamlin the ethereum addresses of both contacts

@richard-ramos I am wondering if it is really necessary to have payTribute in the contract, couldn't paying tribute simply be a SNT transaction, indistinguishable from a normal transaction at least. The transaction-id would be sent with the contact request directly to the contact.

[richard-ramos]

Yes, it should be possible. The contract will work in this case as a registry to only store the fee information. The advantage to having the payTribute function is that it emits the AudienceGranted(_to, requester) event that if subscribed to, could be used as a mean to notify the user that its request for audience was accepted.

If this is something that could be done without an on-chain operation, I see no issues with just handling it as a normal transfer (it would be even better for privacy purposes, since it would be seen as a SNT transfer and not as an operation related to communication between two actors), as well as making things slighty cheaper

[goranjovic]

@yenda yes, by parsing the event log, you can see get-token-transfer-logs in status-im.models.transactions

[yenda]

@richard-ramos both solution don't seem to fit the user story I want to receive payment from the sender when I respond to their request.. How could we achieve that? Seems difficult to determine if the recipient has responded to the message

[richard-ramos]

Yes, it's a disadvantage of autoaccepting the tribute. However, previous version of the contract has a grantAudience function that is supposed to be invoked by the receiver automatically when he replies back, and performs the transfer of SNT. which should fit this user story. (https://github.com/status-im/contracts/blob/096-tribute-to-talk/contracts/communication/MessageTribute.sol#L113)

@3esmit, what do you think if we move back to this version?, and then explore how to make the Tribute to Talk contract interactions use ZK to avoid revealing too much info of the interactions between participants?

GitHub

status-im/contracts

Contribute to status-im/contracts development by creating an account on GitHub.

[3esmit]

@yenda The contract allows the TtT user to set the value and automatically accept this transaction if correct value. A event is fired which can be watch.

The Tribute to talk contract don't needs to have "deposited tokens", users only need to approve token to it and call payTribute.
This function uses the allowance set to the contract to transfer from one user to other, so it never keeps any token, its a direct transfer guided by this contract, but its little more gas expansive because EVM need to read the value of tribute from storage and clear SNT allowance + move SNT balance, instead of simply move SNT balance.

It would be possible to remove the smart contract and set in the mailserver the value, so users can interact with this actors to process tribute to talk, or when both users are online they can interact directly.

@richard-ramos If we define the specs as it is there we can use this version but I think it have unnecessary stuff. For example: captcha, the value of tribute to talk is better than captcha, but I agree its useful when tribute to talk is not used.
I made the simpler version to MVP, and I agree that we can change it as we decide is better.
I agree that we should think about a next interation with privacy, which possibly can be done with a variation of miximus

Probably when moving to zk, mailservers would have to participate in the process, or another data-availability methods. Another interesting thing to research is plasma snapp

[3esmit]

Why we need the part of "when I respond request"? If user set tribute to talk is because they are willing to accept invitations by that price. Who would say no?
If thats needed I can include a simple signed message answering to the requestor, the problem is that this would need mailserver syncing - as the commitment can only be done by talk requestor when talk receiver sent a signed allowance, or allow talk receiver to accept the commitment, and make the requestor send a signed allowance to receiver.
I think this flow is odd, and that's why I removed it when rewriting the contract.

[3esmit]

New contract as we defined @yenda
https://github.com/status-im/contracts/blob/314-tribute-to-talk/contracts/communication/MessageTribute.sol

GitHub

status-im/contracts

Contribute to status-im/contracts development by creating an account on GitHub.

[errorists]

Why we need the part of "when I respond request"? If user set tribute to talk is because they are willing to accept invitations by that price. Who would say no?

I believe it's necessary for some of the use cases we're aiming for. What we're enabling here is a service that you can choose to monetise your attention, and the contract between two people should require a mutual agreement that one is willing to pay for this service and the other to actually provide it. If for some reason the recipient is currently not able to do so or otherwise doesn't feel like it, he should have the option to decline it and the tribute to be pending until his approval. So while I understand that for spam protection that may seem like overkill, for enabling services based on messaging, I see it as a good UX requirement.

[3esmit]

I see that tribute to talk is actually 1-1 spam filter.
Regarding providing a monetized attention service, I think that could be a different contract, as this services would probably need a periodic recharge or other rules, which might be custom to each provider.
For the case of providing service, as we are open source and extendable, should be easy to patch a client the automatically accept the TtT without any useful answer and actually not honoring the talk. .

For spam filtering the best UX would be auto-accept, as message receiver don't need to do anything different than they do now but they would see a transaction as first message from unknown contract. The message sender would be attaching a payment with the message.

The only advantage of requiring the both signatures is that prevents one user paying tribute to a "dead" address.

[errorists]

@rachelhamlin so should we treat the TtT work we're doing now as providing spam filtering or covering the SNT use cases outlined in the whitepaper?

[3esmit]

In case we decide going to not autoaccept in this MVP, I added a option of the contracts having the needed functions that require an agreement from both parties to execute tribute to talk.

I added two options:

1. sendTribute(address _to, uint256 _value, uint256 _ttl, bytes calldata _signature) which can be called (require tx, pays gas) by "message sender"
2. receiveTribute(address _from, uint256 _value, uint256 _ttl, bytes calldata _signature) which can be called (require tx, pays gas) by "message receiver"

We should select one of this 2 options instead of using the both (but wont hurt to have the two functions)

https://github.com/status-im/contracts/blob/314-tribute-to-talk-rejectable/contracts/communication/MessageTribute.sol

GitHub

status-im/contracts

Contribute to status-im/contracts development by creating an account on GitHub.

[oskarth]

Looking at this issue description, I don't understand what the acceptance criteria for it is.

[yenda]

@oskarth this is just an mvp item for TTT on the chat-team epic board so that we have the little card over all others when it's our turn to work on TTT. Regarding acceptance criteria they are not defined yet as this is still in research phase and the outcome will determine the acceptance criteria of this one.

@errorists the problem with pay on reply is that there is no way to enforce an actual reply. Also if receiving requires calling a contract call then there is a very clear on-chain trace of A and B having a communication.

[rachelhamlin]

Yeah, let's go with the simpler option—version 1 of the contract, 1:1 spam filtering. I don't feel that it really enables the use cases in the white paper, but given that we can't guarantee that User B replies to a message anyway (Whisper limitation @yenda?), it's truthfully the only option.

So basically, we drop a bunch of the screens from the MVP in support of the following @errorists:

Is that right @richard-ramos @3esmit?

Further questions:

1. Is a transaction required to set the tribute for User A (recipient)?

2. Can we make it possible to remove someone from contacts @yenda?

3. Is the contact exchange in this scenario mutual, A is added to B's contacts and B to A's?

4. If we want to support an escrow contract with reply required in the future, the receiveTribute function makes that possible @3esmit? What about grantAudience which Richard mentioned? In either case, User A (recipient) would need to spend gas to confirm their reply?

[richard-ramos]

@rachelhamlin , yes

1. Yes, since we would be using the contract as a registry for the required fees.
2. Both options require gas spent by UserA