314-tribute-to-talk is nearing completion; the designs are implemented and the contract is currently in audit by a third party firm. The MVP is an anti-spam mechanism, which enables stakeholders to set a minimum amount of SNT that must be paid in order for someone outside their network to contact him/her directly.

Summary

Inspired by one of Satoshi Nakamoto’s original suggested use cases for Bitcoin, Tribute to Talk will introduce an economics-based anti-spam filter – in our case for receiving messages and “cold” contact requests from users.

While the white paper calls for a deposit to be made and stored in escrow until the recipient accepts the tribute, the team has opted for a simplified MVP for the initial release of this SNT utility feature. In the MVP, users will bypass a tribute ‘paywall’ by making a transaction, without any participation required from the receiving user. Once the tribute is paid, the line of communication will be opened. This choice was made as a means to give plausible deniability of the transaction as opposed to an on-chain event. Future iterations of the feature aim to implement an anonymous deposit to an escrow contract.

This is the lightest version of the feature possible, but also a response to technical constraints. Ultimately, the team sees the greatest value in users being able to not simply filter spam, but also monetize their time and attention through a more feature-rich escrow version of Tribute to Talk.

Goals

MVP: Deliver an SNT based anti-spam mechanisms in accordance with the white paper.
Roadmap: Allow individuals to monetize their time and attention by consciously accepting/ignoring tribute requests, in exchange for access, in escrow.

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

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

Current Status: Design are implemented and UI is in testing. Contract in audit.

Team: Eric, Vitaliy, Maciej, Richard, Tetiana

Status Channel: #status-core-chat

Intro

The Tribute to Talk swarm feature has made significant progress in 2019. While early versions on this SNT utility feature and contract were designed and developed in April and May of 2018, the feature was previously de-prioritized as a matter of poor timing.

The initial contract details (written by Richard Ramos) can be found here.

After an initial research phase, the MVP was scoped to rely on instant transactions between the paying user and the receiving user. The team identified two layers to Tribute to Talk:

Anti-spam 1:1 economic filtering. This is what we are building in the MVP.
Monetization of a user’s time & attention with added features such as escrow, conversation time-out/limitations, etc.

Anyone can set a tribute to talk. In the MVP, others pay this tribute via a normal wallet transaction, which instantly opens up a conversation with that individual.

MVP user stories are defined as:

User A = Person sending tribute. User B = Person accepting/rejecting chat request

User A
- As a user who values privacy, I would like to set a minimum required tribute to talk to me in order to prevent 1:1 spam.
  - I would like to change the tribute required to talk to me.
  - I would like to remove the tribute required to talk to me.
User B
- As a user looking to make new contacts, I would like to pay tribute so that I can message User A.

Research Phase

January was spent conducting research into the following:

Is this feature comparable to any other anti-spam mechanisms? Will people understand the concept? What UX references are relevant?
What features does the current smart contract support?
Do we need to conduct an audit on the contract before launch?
Identify incompatibilities with other features/issues—e.g. inability to remove contacts once added, overlap with core issues, etc.

During the research phase, the team landed upon 2 main options for contract implementation:

User A = Person sending tribute. User B = Person accepting/rejecting chat request.

Option 1: Use regular SNT transactions: A very simple contract that is only used as an index of tributes required to contact users. The tribute is paid with a regular transaction which is slightly better for privacy but requires A to pay before talking to B without an escrow. This route would not require a security audit because the contract itself doesn't handle any value.
Option 2: Facilitate transactions through contract: A more complex solution that acts as an escrow. B needs to accept the tribute to be paid. However this just looks like an additional step in the UX flow that doesn't really bring any guarantees because it can't be proven that B actually replied or provided a meaningful reply.

It was determined that the best path forward is to implement a simple solution in the form of option 1 with the following requirements:

Set tribute - take the tribute amount and sets for the address
Remove tribute - remove the tribute for the address
Check tribute - take an address and return the tribute amount

Key Considerations & Challenges:

Before jumping into design and implementation, there were a few questions to answer:

How can we mitigate the awkwardness of trying to contact someone you know, when they have a tribute set? Options: (1) Contact request feature to circumvent TtT; (2) Refund TtT fee for someone I know.

To mitigate this, we added a reminder to the paywall screen. If you know someone in real life and don’t want to pay tribute, you can share your contact info them outside of Status.

How can we ensure privacy for user A (person sending tribute) and user B (person accepting/rejecting chat request)?

Ultimately we decided to hash more of the data we store on-chain, so the least amount of data possible is transparent. For example, a user’s tribute amount isn’t visible in the smart contract. The data is instead stored on IPFS.

How do we prepare for the decoupling of a user’s Whisper key from their Ethereum address? This is planned, and the feature is currently predicated on their coupling.

Decoupling of the Whisper key and Ethereum address is still an open topic of discussion in the multi-account swarm.

Specification & Designs

A detailed Tribute to Talk Spec can be found in GitHub here. This detailed document outlines the following:

User Stories and User Flows
Naming and Branding Considerations
Open Questions (as outlined above)
Dependencies and Blockers
Measurement & Tracking Considerations
Contract Requirements (as outlined above) including potential risks & mitigation Strategies

Where we are now

Designs are complete and the UI is implemented and in testing.

While working on the payment flow, the team decided to further reduce data stored in the contract and add in an additional control to allow for contract versioning. Adequate versioning, and the ability to deactivate a contract, means that tribute settings for clients using older versions of the TtT protocol can be forcibly disabled. This means that a user receives all messages intended for them, and is encouraged to upgrade to a client with the current TtT implementation.

Having reduced the contract to a simple registry is also better for user privacy. The only data visible in the contract is whether a user has a tribute setting. There is no information about the amount, nor about transactions from other users. Tribute transactions are indistinguishable from other transactions passing through the SNT contract.

Next Steps

The contract and UI are being audited by third party firm Trail of Bits. Once any vulnerabilities or flaws are addressed, the feature will go into testing on testnet.

After that, it will be made available on mainnet in a public release.

We are also conducting research on the token model and the impact of transaction data and flow of SNT on the overall value of the feature. Stay tuned for more info on the crypto economic research.

Future Iterations

Once the MVP is released, the team would like to gather feedback from our community about Tribute to Talk.

There are two paths moving forward:

Tribute to Talk is developed into the white paper vision, with an escrow feature built in using a separate contract, to facilitate a more constructive value exchange between users.
Build out a subscription model in which TtT can serve as the basis for a Patreon-like feature, allowing users to follow or subscribe to donate to each other in Status in response to content created.

There will also be a need to adapt the feature for a new account architecture in which a user’s Whisper ID and Ethereum address are no longer coupled.

Get Involved

Check out the Repo in Github
Join the conversation in Status #status-core-chat

Need to Install Status?

iOS
If you don’t currently have Status installed, access via TestFlight here https://testflight.apple.com/join/J8EuJmey

Android
You can find Status.im in the PlayStore and click ‘Update’

Rachel Hamlin