SelfModerate — Démo live

Démo SelfModerate

Une mini-communauté de 5 bots + toi. Tu votes, les scores bougent, le serveur détecte les attaques coordonnées en direct.

Crée ton identité dans la communauté

Ce qu'il se passe ici : tu entres dans une communauté déjà peuplée de 5 bots aux profils variés (toxique, neutre, upvoter, pack, victime). On te crée un compte avec réputation 20 et on génère des invitations avec chacun des bots pour que tu puisses voter ensuite.

Communauté : votes légitimes

Crée ton identité pour voir la liste.

Règle : le vote est lié à une invitation acceptée. Chaque 👍 ou 👎 modifie la réputation de la cible. Score capé à 30, plancher à 0. Si tu downvotes @alice_toxique, son score baisse et, si assez de monde fait pareil, elle perd son droit de vote puis est bannie.

Détection pack-voting

Simulons une attaque coordonnée : 3 bots (@charlie, @dave, @alice) votent 👎 simultanément contre la même cible. L'algorithme détecte la coordination, annule les votes, restore la réputation.

Cible à "attaquer"

Ce qu'il se passe ici : les 3 bots votent -1 en moins de 60s contre la même cible. L'algorithme regarde les votes récents, identifie la convergence temporelle + le graph d'invitations croisées entre voters, marque les votes comme blocked = 1, reason = pack_voting, et restore la réputation de la victime. Aucune IA. Juste du SQL.

Escalade des sanctions

Si un user descend sous certains seuils de réputation, les sanctions s'enchaînent automatiquement : perte du droit de vote à rep < 5, ban temporaire à rep = 0 (24h puis 7j puis 30j selon les strikes), ban permanent après 3 strikes.

Cible à "drainer" (faire descendre jusqu'à 0)

Ce qu'il se passe ici : tous les autres votants appliquent des -1 successifs espacés dans le temps (pour ne pas déclencher pack-voting). Tu vois la réputation baisser, le moment précis où les droits de vote sont retirés, puis le ban prendre effet avec sa durée. Pure mécanique d'escalade de seuils.

Upvote farming

Tentative d'upvoter la même cible 4 fois d'affilée. Les 3 premiers passent, le 4e est bloqué : blocked_reason = upvote_farming. Règle : plus de 3 upvotes mutuels en 60 jours = gaming du système.

Cible à upvoter frénétiquement

Ce qu'il se passe ici : chaque upvote est géré par applyVote() qui compte d'abord les upvotes antérieurs du même voter vers la même cible sur 60 jours. À partir du 4e, vote enregistré mais marqué blocked — il n'impacte pas la réputation cible. Ça empêche deux users complices de se "prêter" des points entre eux.

Temps simulé + reset après ban

Une fois un user banni, son ban a une fin. Pour la démo on peut avancer le temps simulé. Quand le temps dépasse banned_until, le user retrouve reputation = 20 et ses droits de vote, mais conserve ses strikes (qui mènent à un ban plus long la prochaine fois). À 90 jours sans incident → reset total des strikes.

Ce qu'il se passe ici : tick.php incrémente le simulated_time en base, puis scanne les users avec banned_until < simulated_time et les débannit. La boucle faute → sanction → délai → réparation est complète. Le système ne punit pas à vie par défaut : il protège, puis laisse la chance de revenir.

Étape à venir (session 7) : démo binôme — comment SelfRecover + SelfModerate neutralisent ensemble une attaque Sybil que ni l'un ni l'autre ne pourrait bloquer seul. 1+1=3.