Goal
The goal of this document is to classify and describe known spam vectors, and to describe mechanisms that can be employed by the protocol and ecosystem participants to mitigate spam.
Preliminary
This document uses the concept of an inbox to represent the location where a user’s conversation and invite messages are delivered by the network.
Conversation messages for a specific topic flow to the user’s conversation inbox, and invite messages flow to the user’s public inbox.
This document refers to the sender and recipient apps in the diagram above as “inbox apps”.
Spam classification
Network DOS
- Garbage conversation message DOS: An attacker sends many conversation messages to one or many existing conversations that they are not a part of, from one or many attacker identities. The messages cannot be decrypted by the conversation participant’s inbox app, and can be considered garbage. This can potentially overwhelm the network.
- Sybil conversation message DOS: An attacker sets up multiple identities, creates conversations that the identities are a part of, and spams messages back-and-forth. This can potentially overwhelm the network.
- Public inbox message DOS: An attacker sends many invite messages to many public inboxes, from one or many attacker identities. This can potentially overwhelm the network.
User Inbox DOS
- Targeted public inbox message DOS: An attacker sends many invite messages to one targeted public inbox, from one or many attacker identities. This can potentially overwhelm the user’s inbox app.
- Targeted garbage conversation message DOS: An attacker sends many conversation messages to one targeted conversation that they are not a part of, from one or many attacker identities. The messages cannot be decrypted by the conversation participant’s inbox app, which will then attempt to filter the messages. This can potentially overwhelm the user’s inbox app.
Phishing
- Phishing: An attacker sends many invite messages to many different public inboxes, from one or many attacker identities. The attacker only needs one recipient to open the message and sign a transaction to get a payoff. The attacker can increase its ROI by sending a high volume of messages.
- Spear phishing: An attacker customizes fraudulent invite messages to appear as if they are from a trusted source, often someone the victim knows or interacts with. The goal is the same, get the recipient to open the message and sign a transaction with their wallet. The attack is personalized, sophisticated, and often relies on social engineering techniques to exploit the victim’s trust and familiarity with the sender.
Phishing mitigation is difficult because attackers have a known bounty (i.e., the recipient wallet balance).
Spam defense classification
- Network gossip: Individual nodes in a p2p network receive messages from senders or peers, locally execute the message to ensure validity against non-arbitrary predefined rules, delete invalid spam, and gossip valid messages to their neighbors for inclusion in the mempool. The mempool allows nodes to collectively compile a queue that consists only of valid messages. When a transaction is widely recognized as spam by the nodes, it is less likely to be included in the network.
- Network messaging fee mechanism: A per message fee that fluctuates with network demand, paid by the sender. Financially disincentivizes spamming the network with messages, as well as provides some sybil-resistance by preventing malicious actors from overwhelming the network with fraudulent phishing messages.
- Inbox messaging fee mechanism: A per message fee that fluctuates with demand for a user’s inbox, paid by the sender. This fee may further be segmented by a user’s conversation and public inboxes. Financially disincentivizes spamming specific inboxes with messages.
- Post delivery filtering: Inbox apps are able to view message metadata, such as sender, as well as decrypt the message contents. They can use this knowledge to develop filtering algorithms that choose which messages to display for end users.
- Post delivery indexing: Inbox apps can use their knowledge of message data to choose where and how a message is displayed to the end user.
How can the protocol help mitigate spam?
A mechanism is considered a good candidate to be elevated to the level of the protocol if it enhances coordination among ecosystem participants, avoids any intentional or unintentional discrimination against specific ecosystem actors or participants, and achieves a majority social consensus.
Network gossip
Network DOS
- Garbage conversation message DOS: Sender is not part of the conversation. Network nodes consider the message spam and drop it from the mempool.
- Public inbox message DOS: As long as the attacker sends valid invite messages the network will deliver them to the intended public inboxes. An example of an invalid message could be lack of recipient inbox destination in the invite message’s payload. In this case, the message would be considered invalid and dropped from the mempool.
User Inbox DOS
- Targeted garbage conversation message DOS: Sender is not part of the conversation. Network nodes consider the message spam and drop it from the mempool.
Messaging fee mechanism
Network DOS
- Garbage conversation message DOS: Sender must include a sufficient network fee for the message to be considered valid. If a sufficient fee is not included, network nodes consider the message spam and drop it from the mempool. Of course, this message would be dropped as invalid by gossiping nodes regardless of the fee attached.
- Sybil conversation message DOS: A conversation inbox specific fee (local fee market). Fees to write messages to a conversation are determined by the volume of messages requiring access to the conversation within a short amount of time. The fee can be deterministically defined by the protocol. Inbox specific fees seem reasonable since there is no interdependencies between conversations and the messages can be executed on separate threads. Note, a resource auction may not make sense because there should not be competition to write messages between the participants of a conversation.
- Public inbox message DOS: A public inbox specific fee (local fee market). Fees to write messages to a user’s public inbox are determined by the volume of messages requiring access to the public inbox within a short amount of time. The fee can be deterministically defined by the protocol. Inbox specific fees seem reasonable since there is no interdependencies between public inboxes and the messages can be executed on separate threads. Note, an auction may not make sense, since a specific public inbox is only likely to see heavy demand under attack. The attacker would likely easily outbid other invite senders.
User Inbox DOS
- Targeted public inbox message DOS: The same mechanism mentioned in the previous bullet, Public inbox message DOS provides DOS protection for targeted user inboxes.
- Targeted garbage conversation message DOS: Sender must include a sufficient network fee for the message to be considered valid. If a sufficient fee is not included, network nodes consider the message spam and drop it from the mempool. Of course, this message would be dropped as invalid by gossiping nodes regardless of the fee attached.
Phishing
- Phishing: Post delivery filtering by inbox apps makes the attacker’s expected payoff unpredictable. A messaging fee pushes the expected payoff towards zero, and hopefully negative. Additional fee mechanisms, such as a credibly neutral reputation fee can help inbox apps determine which message senders have high conviction in forming a meaningful relationship.
- Spear phishing: This attack is likely not deterred by a simple messaging fee mechanism, as the attacker can be more confident about payout expectations, and is only required to pay the fee for a small number of messages.
Post delivery filtering and indexing
Protocol post delivery mechanisms primarily fall into the category of reputation signaling. That is, inbox apps would be better able to protect users if the protocol can somehow signal sender reputation.
As a credibly neutral coordination point, the protocol is a natural place to administer reputation.
There are various mechanisms the community is considering:
- Staked sender: A protocol staking contract that honest professional senders can use to signal their reputation by staking a minimum amount.
- Reputation fees: A protocol bribe that is attached to each broadcasted message from a professional sender
- A crowdsourced consensus mechanism like MobyMask can be used to track spammer addresses
Staked sender
Professional senders stake to get reputation bandwidth.
The existence of stake informs inbox apps of the broadcaster’s intent to form a meaningful relationship.
How staking reputation is used in filtering strategies will likely vary across inbox apps. The ability of inbox apps to separate 1:1 vs 1:many senders will impact the effectiveness of the staking signal.
The protocol staking contract is the most legitimate and agreed upon location for stake.
Constrain invite messages:
- The honest path requires a capital commitment
- Spam message broadcasting is crowded out by honest professional senders
- Provides a credibly neutral signal for inbox apps to filter anything that looks like invite spam
Reputation fees
Honest professional senders can include a reputation fee that signals their intent to form a meaningful relationship. The fee is not bounded, and can be thought of as a credibly neutral protocol bribe.
The fee is escrowed until one of three events occurs: (1) the sender replaces the message with a higher reputation fee; (2) the recipient accepts the invite; or, (3) 30 days (in epoch time) has passed since the message was first sent. The fee is sent with partial key material that is required to unlock the fee. In all outcomes, the event generates the remaining key material to unlock the escrowed fee.
Reputation fee destination
Reputation fee destination is outcome dependent. If the invite is replaced by the sender or expires, the fee is refunded to the sender. If the invite message results in a conversation, the fee is burned by the protocol.
Burning reputation fees has the nice property of aligning protocol revenue with professional sender activity—assuming the majority of reputation fees come from professionals.
More work is required to understand if the proposed reputation fee mechanism is incentive compatible and if it is vulnerable to attack.
Protocol level list of attacker addresses
Design a process for ecosystem participants to flag spam address.
The mechanism must incorporate a robust consensus process and incentives in order to protect protocol users from being improperly labeled, either intentionally or unintentionally.
Post delivery inbox apps can use the list to filter reported addresses.
Post delivery filtering effectiveness
All three solutions presented above become less effective in the presence of sybil.
An attacker can seamlessly spin up many XMTP contacts to:
- Spam as 1:1 invite messages, which inbox apps may not expect to have staked reputation or fees attached
- Easily send invite messages from fresh addresses that are not currently in the protocol block list
Questions
- What are the primary objectives and constraints of a sybil resistance mechanism for XMTP?
- Can we design safe spam mitigation mechanisms that scale with balance held in the wallet?