Proposal: Integrating Spam Filter with Runtime Responses (User Metadata Needed)

[rferrari]

Hi everyone 👋

I've been experimenting with integrating a spam filter directly into Eliza's runtime response flow, especially for handling scenarios where users mass-tag others (mainly tested on Farcaster so far). The idea is to gently flag or ignore suspected spammy messages.

I hit a blocker though — without access to username or userId at the time of the runtime response, it's hard to make meaningful decisions (e.g., tracking abuse or rate-limiting per user).

Here's a rough outline of the SpamFilterManager class I'm using:

class SpamFilterManager {
    private blockedUsers: { [key: string]: { username: string; count: number, lastBlockedTimestamp: number } } = {};
    // ...methods to add, check, cleanup, log
}

Idea:

• Add a setting in elizaOS (off by default) to enable spam filtering per platform (Farcaster/Twitter/etc).
• Use the senderId and username if available to apply light filtering logic.
• Minimal false positives so far, but it's still early testing.

Would love help on:

1. How/where to reliably access senderId or similar metadata in runtime responses.
2. General thoughts on whether this fits the architecture and any caveats you foresee.

Happy to open a PR if there’s a clear path forward.

Thanks! 🙏

https://github.com/rferrari/justtom-eliza-starter/blob/SpamFilterManager/packages/client-farcaster/src/spamFilterManager.md
https://github.com/rferrari/justtom-eliza-starter/blob/SpamFilterManager/packages/client-farcaster/src/spamFilterManager.ts