Feature: User and Bot Verification #49

New issue

Open

opened 2026-04-26 16:46:07 +00:00 by icub3d · 0 comments

icub3d commented

2026-04-26 16:46:07 +00:00

Owner

Migrated from GitHub issue icub3d/decentcom#68
Original Author: @icub3d
Original Date: 2026-04-17T00:28:03Z

Feature: Identity Verification System

Overview

Design and implement a verification system for "Open" servers to distinguish between humans and automated bots, reducing Sybil attacks and spam.

Background

Decentralized servers with open membership are vulnerable to mass registration by bots. We need a way for admins to require "verification" before granting permissions like SEND_MESSAGES.

Requirements

Research decentralized/privacy-preserving verification methods.
Support for CAPTCHAs (evaluating privacy-friendly alternatives like Turnstile or hCaptcha).
Support for "Proof of Work" based challenges during the auth flow.
"Verified Human" vs "Verified Bot" badges in the UI.
Admin panel to configure verification requirements per server.

Design (Open for Research)

API / Interface Changes

POST /api/v1/auth/verify might require a verification token or proof.
GET /api/v1/server/info includes verification requirements.

Component Changes

client/src/pages/Setup.tsx: Add verification step to onboarding.
server/src/auth/: Integration with verification providers.

Task List

Research CAPTCHA providers and their Rust/React integration.
Prototype a Proof-of-Work challenge (client-side hashing).
Design the UI for "Verify you are human" prompts.

Test List

Integration test: user cannot join/send messages if verification is enabled and not completed.

Open Questions

Can we leverage existing DID (Decentralized Identity) solutions for "humanity" scores?
How to keep verification decentralized and private?

**Migrated from GitHub issue icub3d/decentcom#68** **Original Author:** @icub3d **Original Date:** 2026-04-17T00:28:03Z --- # Feature: Identity Verification System ## Overview Design and implement a verification system for "Open" servers to distinguish between humans and automated bots, reducing Sybil attacks and spam. ## Background Decentralized servers with open membership are vulnerable to mass registration by bots. We need a way for admins to require "verification" before granting permissions like `SEND_MESSAGES`. ## Requirements - [ ] Research decentralized/privacy-preserving verification methods. - [ ] Support for CAPTCHAs (evaluating privacy-friendly alternatives like Turnstile or hCaptcha). - [ ] Support for "Proof of Work" based challenges during the auth flow. - [ ] "Verified Human" vs "Verified Bot" badges in the UI. - [ ] Admin panel to configure verification requirements per server. ## Design (Open for Research) ### API / Interface Changes - `POST /api/v1/auth/verify` might require a verification token or proof. - `GET /api/v1/server/info` includes verification requirements. ### Component Changes - `client/src/pages/Setup.tsx`: Add verification step to onboarding. - `server/src/auth/`: Integration with verification providers. ## Task List - [ ] Research CAPTCHA providers and their Rust/React integration. - [ ] Prototype a Proof-of-Work challenge (client-side hashing). - [ ] Design the UI for "Verify you are human" prompts. ## Test List - [ ] Integration test: user cannot join/send messages if verification is enabled and not completed. ## Open Questions - Can we leverage existing DID (Decentralized Identity) solutions for "humanity" scores? - How to keep verification decentralized and private?

icub3d added the

labels

2026-04-26 16:46:07 +00:00