Decentralized Social Graphs (CyberConnect) vs Federated Social Graphs (Mastodon) for Spam Analysis

On-chain identity & social graph: User connections and interactions are recorded on the blockchain (e.g., Base, Optimism). This creates a tamper-proof, portable reputation that can be analyzed across dApps. Spam accounts cannot scrub their history. This matters for building Sybil-resistant algorithms that leverage historical on-chain behavior.

Blockchain data indexing overhead: Real-time spam analysis requires querying decentralized nodes or indexers like The Graph. This introduces latency (seconds to minutes) and can incur RPC/data query costs at scale. Analyzing millions of social actions for spam patterns is slower and more expensive than querying a centralized database.

Server administrator sovereignty: Each instance (server) runs its own rules and moderation tools (e.g., Akkoma, Pleroma plugins). Admins can blacklist domains, defederate, and apply real-time filters. This allows for immediate, tailored spam response based on local community standards without waiting for a global protocol upgrade.

Lack of global graph visibility: Spam analysis is siloed per instance. A spammer banned on one server can easily migrate to another. There is no unified reputation system or shared blacklist (beyond manual admin coordination), making cross-instance spam campaigns difficult to track and mitigate at the network level.

Specific advantage: Single, global graph state on Ethereum L2s (Base, OP Mainnet). This provides a unified data layer for analyzing cross-platform spam patterns and sybil attacks across apps like Link3, Mask Network, and Galxe. This matters for protocol-level threat intelligence where spam rings operate across multiple frontends.

Specific advantage: On-chain EssenceNFT and SubscribeNFT interactions create immutable, composable reputation signals. Spam accounts cannot scrub their history. This matters for building persistent, portable reputation scores that dApps can query directly via the CyberAccount smart contract wallet, moving beyond simple follower counts.

Specific advantage: Each server (instance) admin has full autonomy to define, detect, and ban spam using custom rules (e.g., keyword filters, IP blocking, moderation plugins). This matters for communities with highly specific, contextual norms (e.g., art vs. tech instances) where spam definitions vary wildly.

Specific advantage: Centralized database per instance enables sub-second SQL queries for pattern matching and real-time action (shadow banning, silencing). No gas fees or blockchain confirmation delays. This matters for high-velocity public timelines where spam must be killed within seconds, not minutes.

Specific weakness: Reading graph data requires indexing blockchain events (via The Graph or custom subgraph) which adds latency and complexity vs. a direct database query. Real-time spam scoring on every post is currently impractical. This matters for consumer social apps needing instant feedback loops.

Specific weakness: No global view of spam campaigns. A spammer banned on mastodon.social can immediately operate on infosec.exchange. Federated blocklists (like the Mastodon Blocklist project) require voluntary adoption. This matters for coordinated cross-instance attacks which are harder to trace and mitigate holistically.

Specific advantage: Each server (instance) has a local admin with full authority to ban users, filter content, and implement custom anti-spam rules (e.g., keyword filters, rate limits). This matters for rapid, decisive action against coordinated spam campaigns within a specific community, as seen on instances like mastodon.social.

Specific advantage: User identities (DIDs) and social graphs are stored on-chain (e.g., Ethereum, Polygon). This creates a globally verifiable reputation layer where spammer addresses can be blacklisted across all dApps using the same graph (e.g., Galxe, Mask Network). This matters for sybil resistance and preventing bad actors from easily hopping between platforms.

Specific weakness: Spam analysis must be performed per-instance (over 15,000+ servers). There is no global view of the network, and policies vary wildly. A spammer banned from one instance can immediately rejoin another. This matters for scalable, network-wide threat intelligence, requiring analysts to build custom scrapers for each federated API.

Specific weakness: Reading on-chain data for real-time spam detection incurs RPC costs and latency (block confirmation times). Analyzing relationships for millions of profiles (CyberConnect's 2M+ user graph) requires indexing complex smart contract events. This matters for budget-conscious projects needing sub-second spam scoring, versus Mastodon's simpler REST API polling.