first pass

docs/pages/consent/filter-spam.md

@@ -8,11 +8,15 @@ In any open and permissionless messaging ecosystem, spam is an inevitable realit
 
 Implement [user consent preferences](/consent/user-consent) in your app to allow only conversations with approved contacts to display in a user's main inbox. Approved contacts include those the user initiated the conversation with or explicitly approved.
 
-<block-approve>
+<div>
+<img src="https://raw.githubusercontent.com/xmtp/docs-xmtp-org/refs/heads/main/docs/pages/img/block-accept.jpg" width="500" />
+</div>
 
 While the user's main inbox only displays conversations with approved contacts, you can then handle contact requests from unknown contacts in a separate UI.
 
-<requests link screenshot>
+<div>
+<img src="https://raw.githubusercontent.com/xmtp/docs-xmtp-org/refs/heads/main/docs/pages/img/requests-link.jpg" width="500" />
+</div>
 
 These unknown contact requests may include:
 
@@ -29,7 +33,9 @@ You can then filter these unknown contacts to identify:
 
 To identify contacts the user might know or want to know, you can look for signals in onchain data that imply an affinity between contacts. You can then display those messages on a **You might know** tab, for example. 
 
-<you might know>
+<div>
+<img src="https://raw.githubusercontent.com/xmtp/docs-xmtp-org/refs/heads/main/docs/pages/img/you-might-know-tab.jpg" width="500" />
+</div>
 
 For example, you can look at:
 
@@ -60,33 +66,32 @@ For example, you can look at:
 
 ## Identify contacts the user might not know, including spammy or harmful requests
 
-To identify contacts the user might not know or not want to know, which might include spam, you can consciously decide to scan messages in an unencrypted state to find messages that might contain spammy or harmful language. You can also look for an absence of onchain interaction data between the addresses, which might indicate that there is no affinity between addresses. You can then filter the appropriate messages to display on a **Hidden requests** tab, for example. 
+To identify contacts the user might not know or not want to know, which might include spam, you can consciously decide to scan messages in an unencrypted state to find messages that might contain spammy or harmful content. You can also look for an absence of onchain interaction data between the addresses, which might indicate that there is no affinity between addresses. You can then filter the appropriate messages to display on a **Hidden requests** tab, for example. 
 
-<hidden>
+<div>
+<img src="https://raw.githubusercontent.com/xmtp/docs-xmtp-org/refs/heads/main/docs/pages/img/hidden-requests-tab.jpg" width="500" />
+</div>
 
 The decision to scan unencrypted messages is yours as the app developer. If you take this approach:
 
 - Handle unencrypted messages with extreme care and don't store unencrypted messages beyond the time necessary to scan them.
-- Consider telling users that your app scans unencrypted messages for spammy or harmful language.
+- Consider telling users that your app scans unencrypted messages for spammy or harmful content.
 - Consider making spam and harmful message detection optional for users who prefer to not have their messages scanned.
 
-You might also consider using spam management tools to detect and filter out spammy contact requests to display in a spam inbox.
+## Why is content moderation handled by apps and not XMTP?
 
-## Spam management tools
+XMTP is a decentralized, open protocol built to ensure private, secure, and censorship-resistant communication. As such, XMTP can't read unencrypted messages and therefore it also can't scan or filter message contents for spam or harmful material.
 
-Experiment with these spam filtering tools provided as public goods by members of the XMTP community.
+The protocol can analyze onchain data signals, such as shared activity between wallet addresses, to infer potential affinities between addresses. However, because all XMTP repositories are open source, malicious actors could inspect these methods and develop workarounds to bypass them.
 
-- [Malicious Ethereum addresses](https://github.com/3numdao/dsbdao)  
-  Decentralized Spam Bustaz DAO (DSBDAO) is a database of known malicious Ethereum addresses. Use this information to create sender address-based client-side filtering criteria. Created by [@boscolochris](https://twitter.com/boscolochris) and [@dawufi](https://warpcast.com/dawufi) and hosted by [3NUM](https://3num.co/).
+Additionally, applying spam filtering or content moderation directly at the protocol level would introduce centralization, which goes against the decentralized, permissionless, and open ethos of XMTP and web3. A protocol-driven approach could limit interoperability and trust by imposing subjective rules about content across all apps.
 
-- [Web2 spam domains](https://github.com/chainjet/xmtp-denylist)  
-  `xmtp-denylist` is a public repo that lists web2 domains used in phishing spam. Created by [ChainJet](https://chainjet.io/).
+Instead, content filtering and moderation should be implemented at the app layer. Apps can decide how opinionated or lenient they want to be, tailoring their filtering approach to the needs of their users. For example, one app may choose to aggressively scan and block spam to provide a highly curated experience, attracting users who value more protection. Another app may opt for minimal or no filtering, appealing to users who prioritize full control and unfiltered communication.
 
-- [Unstoppable Domains spam report](https://docs.unstoppabledomains.com/openapi/messaging-v1/#tag/Chat/paths/~1xmtp~1spam~1%7Baddress%7D/get)  
-  A public API endpoint to query whether Unstoppable Domains users have marked an Ethereum address as a source of unwanted spam. Use this information to create sender address-based client-side filtering criteria. Created by [Unstoppable Domains](https://unstoppabledomains.com/).
+This flexibility enables different apps to serve different user preferences, fostering a ecosystem where users can choose the experience that best suits them. Whether an app scans messages or not, XMTP ensures that developers remain free to build in line with their own values, without imposing restrictions at the infrastructure level. This separation between the protocol and app layers is crucial to maintain XMTP’s commitment to openness, interoperability, and user choice.
 
 :::tip
 
-Is your app using a great third-party or public good tool to filter spam and keep inboxes safe? Open an [issue](https://github.com/xmtp/docs-xmtp-org/issues) to share information about it.
+Is your app using a great third-party or public good tool to help with spam and keep inboxes safe? Open an [issue](https://github.com/xmtp/docs-xmtp-org/issues) to share information about it.
 
 :::