When we talk about messaging there is always three different types of messages users send: public, group and private.
Private:
Tribute-to-talk would be required to message a user which does not have you in their contact list. I see it as “please, add me as contact, I pay your fee.”.
When someone sends a valid payment and other user accept payment (or we could just add automatically?) then the messages from that contact would appear in the messages list.
The smart contract we have ready accepts some captcha or some sort of challange from the receiver to be accepted, e.g. the same captcha would be shown to both users but the requester would solve it first.
Group:
Spam in group chats can be easily mitigated if administrator removes them. But the Spam feature can actually be used to spam against users by joining them in groups.
Tribute-to-talk can prevent it as it would do for private messaging, and the group invitation would be considered a private message.
We could discuss how to make the moderation of group chats a democratic process based on any type of token. It’s possible to create “Public Private Groups”, where joining requires the payment to the democracy (or a single individual).
Public:
Spam in chats can be prevented with a visibility stake, which user needs to lock some amount of SNT for some time to users/nodes consider the message valid. A moderation using democracy could be implemented to slash deposit of “bad behavior, such as scammers”, but is not necessary.
Would be possible to allow PoW messages without stake. The PoW should be accounting for the message size, so big messages would require a bigger PoW.
This preventions are “end user”, however status-nodes should not relay invalid messages, and delete messages as they become invalid (user removed deposit)
Transport layer incentivize
This ideas can work together with a incentivize on the transport layer, as
which prevents spam in a lower level and provide incentives in the protocol that would guarantee the availability and continuity of the decentralized service.
I see that all this ideas together would provide a very robust spam protection, better then competitor’s solutions, and accidentally provide income to famous people that use Status…
On the topic of the smart contract we already have… I think the Tribute to Talk swarm should take prior work on TtT into account during research, but define specs for the feature independent of previous designs.
It’s possible that the smart contract may require changes, and I could definitely use a refresher on how it works and the features it supports.
Good point, that should be used, would be nice if someone share the links of those UI design as they are now owned by slack. @rramos should join the swarm because of his expertise on whisper communication, which is used on TtT.
Regarding the concept of current TtT implementation:
Status Chat would be configured to accept or auto reject message from non contacts. TtT acceptance would make user add unknown user on contacts and accept receive messages.
The agreement is done offchain, and the smart contract is only used to settle the agreement. The agreement process is handled automatically by the client in backgroud.
Bob set TtT fee and listen to TtT contract (blockchain)
Alice is an unknown user to Bob, so it sends a payment signature,
Bob validates and answers with a acceptance signature.
Alice submit to TtT contract her payment signature and Bob acceptance signature.
Bob receives event of TtT and start accepting messages from Alice
Another flow for TtT would be blocking
Alice don’t likes what Bob said and set an arbitrary value TtT for Bob by sending transaction to contract
Bob notice the block by event
Bob feels Alice is important and sends the signature of payment
Alice verify payment signature and sends an acceptance signature
Bob submit to contract both signatures
Alice receives event from contract and accept Bob message
There is an optional captcha solution that will be studied, which I think the correct way is payment sender should also solve a puzzle (as captcha) sent by payment receiver,
This also could be used the other way, but I think the captcha should be an alternative to accepting free tribute to talk with no spam risk.
Thanks so much @rramos. FYI @yenda and @vitaliy—I think as an output of the TtT research phase, we should have a list of user stories that the current contract supports, as well as any constraints or shortcomings. I can help with this but would be great to have you both review the contract against MVP user stories.
The auto accept of fee is being considered because the reply can be easily automated, it brings additional final user steps and additional complexity for a unconventional use-case, as we expect all users to accept the tributes to talk because they are incentivized to.
Also accepting or not user would have to dismiss the message anyway, so accepting it automatically makes more sense, as the dismiss would be also just deleting the user again.
In talk we decided to first try using the smart contract only as “value setting”, and try use a normal transfer. This is interesting because it gives a bit more privacy to this process, as they are not obviously revealing the purpose of Tribute to Talk, and uses less gas.
For blocking/resseting tribute to talk a specific user would be by auto reply message requesting payment would be given, and all messages are deleted/filtered until not (re)paid.
A default fee is shown necessary to automatically protect users from spam.
The designs need to be updated to reflect those changes.
