| id | title | status | lead-contributor | contributors | budget | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tribute to Talk |
research |
Eric/Rachel |
|
|
The Tribute to Talk swarm will deliver SNT based anti-spam mechanisms in accordance with the white paper.
It allows individuals to monetize their time and attention by setting minimum required deposits to message them.
- Eric
- Vitaliy
- Maciej
- Richard
- Tetiana
(+ Janitor swarm)
status channel: #314-tribute-to-talk
sync schedule: weekly, during core chat sync
Pivotal link: https://www.pivotaltracker.com/projects/2231830
Meeting notes: https://notes.status.im/weekly-chat-sync-agenda
Research notes: Research notes
Timebox: wrap by 21/12/18
Previous work:
An initial version of Tribute to Talk was partially developed and designed back in April/May.
The existing smart contract documentation is here. Written by Richard Ramos (@rramos).
The previous designs were shared in these github issues.
Ongoing design exploration available here
Changes to the smart contract may be required in order to meet specs defined in this swarm.
Potential user stories for MVP:
- As an influential person, I want to set a minimum required deposit to speak with me on Status.
- I want to review incoming requests from people who have made deposits.
- I want to read the sender's message before accepting or ignoring their request.
- I want to receive payment from the sender when I respond to their request.
- I want the option to close the line of communication again afterward.
- I want the option to waive the deposit and still accept the message. --
- As a fan of some influential person, I want to offer an SNT deposit in order to message that person.
- I want to be notified when the person has accepted my message and sent a reply.
- I want to receive my SNT back if the person does not respond to my message.
Research questions:
- 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?
- Identifiy incompatibilies with other features/issues—e.g. inability to remove contacts once added, overlap with core issues, etc.
11/2/19
- UI bug fixes complete
- Second half of UI (chat side) underway
1/2/19
- First version of UI is complete and design reviewed
- Changes required here: status-im/status-mobile#7304 (comment)
7/1/19 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
User B = Person accepting/rejecting chat request
21/1/19
- Design review complete
- Product spec complete
- Includes contract functional requirements, migration strategy & risk assessment
- UI implementation in progress
- Tangential—contact list w/ “remove contact” WIP
4/2/19
- Settings UI design reviewed
- Changes required
[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.
Copyright and related rights waived via CC0.