An initial version of Tribute to Talk was partially developed and designed back in April/May.
The existing smart contract documentation is [here](https://github.com/status-im/contracts/blob/096-tribute-to-talk/TributeToTalk.md#deciding-the-outcome-of-a-chat-request). Written by Richard Ramos (@rramos).
The previous designs were shared in these [github issues](https://github.com/orgs/status-im/projects/27).
*Top line: The Tribute to Talk MVP will deliver 1:1 spam prevention. The contract will manage tribute settings only. There will be no escrow; payment will be handled through a normal SNT transaction. There are constraints that force this decision, but it's also the simplest possible implementation.*
User A = Person sending tribute<br>
User B = Person accepting/rejecting chat request
[Eric]
So far we have discussed 2 different options:
- contract 1 is a very simple contract that is only used as a index of tributes required to contact users. The tribute is payed with a regular transaction which is slightly better for privacy but requires A to pay before talking to B without an escrow. I don't think there would be a need for a security audit for this one because the contract itself doesn't handle any value.
- contract 2 is more complex and acts as an escrow. B needs to accept the tribute to be paid. However this just look like an additional step in the UX flow that doesn't really bring any guarantees because it can't be proven that the B actually replied or provided a meaninful reply.
