Hashiverse, an open-source decentralized social network in Rust

Hashiverse (https://github.com/hashiverse/hashiverse) is an open-source decentralized social network protocol where Sybil resistance, rate limiting, peer reputation, and content moderation all fall out of one design choice: every action carries a proof-of-work cost calibrated to how much abuse it could cause. No central servers, no DNS dependency, no registration authority, no moderation team. Rust core, WASM browser client, volunteers on $5 VPS machines.

Twitter-shaped (posts, follows, hashtags, timelines). The design problem that usually kills these projects on day one is Sybil resistance without a gatekeeper, so that is what I most want feedback on. Signatures and encryption are conventional (ed25519 + ML-DSA + FN-DSA, ChaCha20Poly1305, Blake3). The interesting surface is how every protocol action is priced in proof-of-work calibrated to its abuse potential.

Shared primitive: a data-dependent chain over 17 hash algorithms. 5 rounds, each selecting one of 17 algorithms (Blake2s/b, SHA-2/3 at 256/384/512, Keccak-256/384/512, Groestl-256/512, Whirlpool, Skein-256/512, Blake3) and applying it 1 or 2 times. The algorithm index and repetition count for round N come from bytes of round N-1's output, so dispatch is data-dependent and only resolved at runtime.

Honest prior art: Evan Duffield's X11 (Dash, 2014) chained 11 SHA-3 finalists with exactly this thesis. X11 ASICs (Baikal, iBeLink) shipped by 2016. Multi-hash chaining delays ASICs, it does not prevent them. What's different here is data-dependent dispatch (X11's pipeline is fixed) and variable repetition count. The honest question is not "is this ASIC-proof?" but "how much delay does data-dependent dispatch buy, and what software-update cadence should a protocol with no upgrade authority plan for?"

Layer 1: Server-ID PoW (DHT membership). Generating a server identity means grinding a salt with the server's public keys through the chained hash until the derived 256-bit Kademlia ID has enough leading zero bits. Hours on commodity hardware per identity. Two compounding mitigations: bucket location IDs rotate on a monthly time epoch (the keyspace region around a user shifts deterministically), and prolific users fan across more buckets as the hierarchy subdivides under load. An attacker pays admission PoW against a moving target whose surface grows with the target's prolificness.

Layer 2: RPC PoW. Every RPC carries a PoW over (timestamp, salt, payload, client ID, destination server ID). Under-threshold requests are rejected before payload parse. Timestamp pinning prevents replay; ID pinning prevents reuse across (client, server) pairs. Knock-on: because the destination server's ID is in the PoW, servers handling real load accumulate a routing-table reputation. A fresh Sybil has no traffic history; to affect the routing table they must either be useful or grind their own fake reputation by paying RPC PoW for every fabricated client request. Useful work becomes a Sybil deterrent.

Post submission is a sub-case: two-phase Claim/Commit so one cheap PoW cannot deliver a huge payload. Submission difficulty scales with recent posting frequency.

Layer 3: Per-feedback PoW. No central tally. Every signal (like, dislike, hate speech, spam, CSAM, etc.) is a PoW-stamped entry over (post_id, feedback_type), so a PoW cannot be reused across signals or posts. We use straightforward statistics to infer the total number of feedback submissions as the reciprocal of the unlikelihood of the globally-maximum PoW per (post_id, feedback_type) pair. That maximum is healed by clients noticing discrepancies, not by server-to-server gossip.

If any of this resonates, or you spot something I've gotten wrong, I would love to hear it. PRs welcome.

-- Jimme Jardine