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