DIGGR — Ce qu'on a fait .

1. Ce qui marche déjà en ligne

• ✓ Landing complète sur diggr.bot avec design soigné (Nunito + Space Mono, dark theme)
• ✓ Auth X obligatoire d'abord via OAuth 2.0 PKCE (login via le portail X)
• ✓ Connexion wallet Solana (Phantom, Solflare) avec signature SIWS
• ✓ Le wallet est lié au compte X existant automatiquement (pas de doublon)
• ✓ Liens de référral uniques par user, capturés au clic, validés une fois le filleul qualifié
• ✓ Tasks "bundle" : pour chaque post on a 3 actions (Like / Retweet / Comment), un seul block visuel
• ✓ Submission d'URL pour RT et Comment : l'user colle l'URL de son tweet, on vérifie auto via oEmbed Twitter
• ✓ Likes en revue manuelle (impossible à vérifier auto en gratuit)
• ✓ Admin panel sur /admin avec 3 onglets : Posts, Submissions, Users
• ✓ Disqualification d'un user en 2 clics (faux compte → freeze des points + flag)
• ✓ Ajustement manuel des points (+ ou -) avec audit log automatique
• ✓ Max 1 pinned + 3 daily posts actifs en même temps (auto-archive du plus vieux quand un 4e est ajouté)
• ✓ Leaderboard public top 100 avec tier / streak / nombre de filleuls actifs
• ✓ Anti-abuse : 1 wallet = 1 compte, 1 X = 1 compte, contrainte unique au niveau DB

2. Ce qu'il te reste à faire 15 min

Étape 1 — Créer l'app sur X Developer Portal

1. 1Va sur developer.x.com avec le compte X officiel @diggr_app (ou celui qu'on utilise)
2. 2Souscris au tier Free (pas besoin de carte bancaire)
3. 3Crée un Project + une App à l'intérieur (type "Web App, Automated App or Bot")
4. 4Dans User authentication settings :
   • Active OAuth 2.0
   • Type of App : Confidential client
   • Callback URI : https://diggr.bot/api/auth/x/callback
   • Website URL : https://diggr.bot
5. 5Récupère le Client ID et le Client Secret (⚠️ le secret n'est affiché qu'une fois)

Étape 2 — Coller les clés dans Cloudflare

1. 1Va sur dash.cloudflare.com → Workers & Pages → projet diggr-app
2. 2Settings → Environment variables → Production
3. 3Édite la variable X_CLIENT_ID : remplace PLACEHOLDER_TO_BE_SET par le vrai Client ID
4. 4Édite la variable X_CLIENT_SECRET : remplace par le vrai Client Secret (laisse "encrypted")
5. 5Save
6. 6Déclenche un re-deploy : sur le dashboard du projet → onglet "Deployments" → bouton "Retry deployment" sur la dernière prod

Étape 3 — Te déclarer admin

Pour que tu puisses accéder au /admin, tu dois te marquer is_admin = true dans la DB. Comme on n'a pas encore d'UI pour ça (poule/œuf), il faut une requête SQL une seule fois dans Supabase Studio :

-- D'abord, connecte-toi sur diggr.bot via X + wallet (pour avoir une ligne dans users)
-- Ensuite, dans Supabase Studio → SQL Editor :

update public.users
set is_admin = true
where x_username = 'ton_handle_x';   -- ou where wallet = 'ton_wallet_solana'

-- Pareil pour ton pote :
update public.users
set is_admin = true
where x_username = 'son_handle_x';

Une fois fait, allez sur https://diggr.bot/admin et vous aurez accès au panneau complet.

Étape 4 — Remplacer le pinned post placeholder

Il y a un pinned post par défaut avec l'ID 0000000000000000000 (placeholder). Quand tu auras posté le vrai tweet pinned, va dans /admin → onglet Posts → "Add a new task post" :

• Kind : Pinned (only 1)
• Tweet URL : https://x.com/diggr_app/status/12345...
• Points : 60 (ou ce que tu veux)
• Description : "Like, retweet and comment with a thoughtful take"

L'ancien placeholder sera automatiquement désactivé (max 1 pinned actif).

3. Le flow utilisateur final

4. Le flow admin (panneau /admin)

5. Stack technique & archi

Schéma de la base de données

16 tables actuellement :

• users — identité (wallet, x, telegram, slug, points, tier, streak, disqualified)
• admin_posts — les posts X gérés par admin (1 pinned + jusqu'à 3 daily)
• post_submissions — preuves utilisateurs (like/RT/comment) avec statut
• referrals — liens parrain ↔ filleul
• points_log — audit immutable de tous les changements de points
• auth_nonces — anti-replay SIWS (TTL 5 min)
• oauth_states — PKCE state pour OAuth X (TTL 10 min)
• achievements / user_achievements — badges (15 seeds déjà créés)
• missions / mission_progress — missions multi-étapes
• boost_windows — fenêtres temporelles X1.5 / X2 sur les points
• seasons — saisons (Genesis Season déjà active)
• user_events — feed d'événements pour notifications
• tasks / completions — anciennes tasks "génériques" (Follow X / Follow TG)

Triggers Postgres importants

• trg_log_points_on_completion — crédit auto + log + anti-doublon
• trg_check_referral_reward — +50 pts au parrain quand filleul qualifié
• trg_check_referral_reward_sub — pareil mais déclenché sur submission verified
• trg_award_submission_points — points/3 par action verified
• trg_update_streak — streak des jours consécutifs
• trg_update_tier — recalc tier free/insider/premium/ultimate auto

Sécurité

• Row Level Security activée sur toutes les tables
• Cookie JWT httpOnly + Secure + SameSite=Lax (7 jours)
• Nonce SIWS unique consommé après usage (anti-replay)
• Signature ed25519 vérifiée server-side (via @noble/ed25519)
• PKCE pour OAuth X (anti-CSRF)
• Admin endpoints protégés par flag is_admin en DB (pas une whitelist en code)
• Service_role Supabase jamais exposée au client
• X Client Secret stocké en secret_text Cloudflare (chiffré au repos)

6. Vérification des tâches X — détails

Pour les retweets et comments, l'user colle l'URL de son tweet (ex: https://x.com/morgan/status/12345). On fait un appel à https://publish.twitter.com/oembed?url=... (gratuit, sans auth, pas de rate limit publié). L'oEmbed nous renvoie :

• L'author_name — on vérifie qu'il match le handle du user logué
• Le HTML rendu — on cherche dedans l'tweet_id ou la mention de l'original

Si les 2 matchent → statut "verified", points crédités immédiatement.
Si l'un manque → statut "manual", file d'attente admin.

Faille connue (à l'esprit)

• Un user peut RT, soumettre, puis supprimer le tweet. oEmbed renverra "verified" au moment T mais le tweet n'existera plus à T+1. → À faire plus tard : un cron de re-check des verified random pour disqualifier les tricheurs.
• Un user peut RT et comment depuis un compte X différent. → Bloqué : on vérifie que author_name de l'URL match user.x_username.

7. Comment marche le référral

Pour gagner +50 pts par filleul, il faut :

1. Le filleul clique sur ton lien https://diggr.bot/r/abc12xyz
2. Cookie ref=abc12xyz posé sur son navigateur (TTL 30 jours)
3. Le filleul connecte X → ligne referrals créée (referrer_id, referee_id, tier=1)
4. Le filleul connecte son wallet
5. Le filleul complète les 3 actions du pinned post (like + RT + comment)
6. La fonction Postgres fn_user_qualified() retourne true
7. Le trigger trg_check_referral_reward_sub crédite +50 pts au parrain
8. referrals.reward_credited = true (pour ne pas re-créditer)
9. users.active_referrals du parrain s'incrémente automatiquement

Anti-abuse

• Un wallet = un compte (contrainte UNIQUE)
• Un X user_id = un compte (contrainte UNIQUE)
• Un filleul = un seul parrain (contrainte UNIQUE sur referrals.referee_id)
• Un parrain ne peut pas être son propre filleul (CHECK constraint)
• Les comptes disqualified sont exclus du leaderboard et de tous les rewards

8. Bot Telegram — statut

La DB a une colonne telegram_user_id et le bot est sur ton EC2. Pour brancher la vérification du join, il suffit de :

1. Ajouter une commande /link dans le bot qui appelle POST /api/auth/telegram avec un HMAC signé
2. L'app appelle https://api.telegram.org/bot{TOKEN}/getChatMember?chat_id=...&user_id=... (gratuit, instant)
3. Si status ∈ {member, administrator, creator} → crédit +20 pts bonus

C'est ~2h de dev quand tu décideras de l'activer. Pour l'instant le focus c'est X comme tu l'as demandé.

9. Coût actuel et future bascule payante

Aujourd'hui — 100% gratuit

0 €/mois jusqu'à environ 5 000 utilisateurs actifs. Au-delà, voici les seuils :

Quand passer X API Basic ?

Le tier Basic à 200 USD/mois donne :

• Vérification auto de Follow, Like, RT, Comment via GET /2/users/:id/following etc.
• 10 000 reads/mois (≈ 300/jour)
• Disparition de la file admin "manual review"

Le code est déjà préparé pour ça : il suffira d'ajouter un endpoint serveur qui appelle l'API X au lieu de bumper le statut en "manual". La table post_submissions avec son colonne status supporte déjà le switch transparent.