I asked 5 Thinking (rarely use) bout spam optimal solution, it’s funny cause it goes through your GitHub stuff when reasoning that is way over my head. Cute that it does that. This is what it said: Today(no code) -use password channels for real conversations (interesting but like I’m sure spam will keep getting access to unless changed daily, maybe tire it out :) -Use built-in/block @name for obvious spam and keep local blocklists. Building tomorrow -layer 1: simple flood & duplicate control with token-bucket rate limits and as mesh already uses TTL routing, in busy venues, reduce hop TTL to shrink the attack surface. Layer 2: -Require tiny POW per public message. Layer3: -Per-key trust scores, new keys start in probation(slow rate) and include relay policy where nodes deprioritise or refuse to forward from low-reputation keys (oof hope that’s not my key) Layer 4 -First-time posters must complete in-room handshake 🤝 like your QR idea or get a trust reaction from non-newbie before normal rates apply. -Invite links for channels with password + short-lived QR code for events. Layer 5 -ship a tiny Core ML text model to score spammy patterns which works for offline damping of bots (be interesting if you can get this embedded into iOS bitchat app) How to geohash without doxxing: -Channel geofence where rooms require senders to be inside target geohash cell (e.g., precision 6 ≈ ~1km, 7 ≈ ~150-200 m) -witness attestations from nearby devices with truncated geohash, not raw coordinates. -pop-up room with rotating QR or 6 digit code as proximity ticket, first time posters scan or enter, afterward post for grace period 24hr. Ok, well that’s it from me, hope it helps. P.S. I swear I am not spam. Cc @calle

Replies (1)

the only decentralized anti-spam measure that is long term workable: 1 make identity costly (no the per message cost is retarded) 2 get blocked before full propagation if you spam this is very hard to implement well, especially point 2